>"Before asking for more Headcount and resources, teams must demonstrate why they cannot get what they want done using AI. What would this area look like if autonomous AI agents were already part of the team? This question can lead to really fun discussions and projects."
And there it is. None of us will be fired or laid off "because AI". The next person simply won't be hired. And then one day, that next person will be you or I.
Really this is a direct, perfect analogy to the industrial revolution. One small person operating a steam shovel could all of the sudden do the work (faster, with higher quality) that for all of human history required hundreds of strong men to do, and it changed the entire world practically overnight.
Businesses simply do not need the mass droves of SWEs who exist to type out CRUD code anymore. We will go the same way of the manufacturing workers of the 20th century, where the small percentage of those who could deeply specialize and adapt and master the processes were ok, but the vast majority never recovered, and ended up in minimum wage misery.
>Soon, you will be able to find anything only thru local on-site interview or strong references.
Anyone paying attention has started planning accordingly for this over the last couple years. The remote work revolution has resolutely failed, and it's clear in retrospect it never had a chance.
This is very much not true: there are extremely-well-compensated roles still available in remote companies.
It does require knowing how to collaborate remotely and being an already-skilled developer, but just because the bar is higher (and many people seem uninterested in meeting it) doesn't mean it has "failed".
>Swift is not a replacemente for C and C++, but rather for Objective-C.
Swift is not a replacement for anything; Apple will even say as much. It just fills the hole for a scripting language that they had for decades. Plenty of new Obj-C is still (and will continue to be) written for a long time.
>"This is a bit of a meta-comment, but reading through the responses to a post like this is really interesting because it demonstrates how our collective response to this stuff is (a) wildly divergent and (b) entirely anecdote-driven."
People having vastly different opinions on AI simply comes down to token usage. If you are using millions of tokens on a regular basis, you completely understand the revolutionary point we are at. If you are just chatting back and forth a bit with something here and there, you'll never see it.
So this is interesting because it's anecdotal (I presume you're a high-token user who believes it's revolutionary), but it's actually a measurable, falsifiable hypothesis in principle.
I'd love to see a survey from a major LLM API provider that correlated LLM spend (and/or tokens) with optimism for future transformativity. Correlation with a view of "current utility" would be a tautology, obviously.
I actually have the opposite intuition from you: I suspect the people using the most tokens are using it for very well-defined tasks that it's good at _now_ (entity extraction, classification, etc) and have an uncorrelated position on future potential. Full disclosure, I'm in that camp.
Token usage meaning via agentic processes. Essentially every gripe about LLMs over the last few years (hallucinations, lack of real time data, etc.) was a result of single shot prompting directly to models. No one is seriously doing that for anything at this point anymore. Yes, you spend ten times more on a task, and it takes much longer. But your results are meaningful and useful at the end, and you can actually begin to engineer systems on top of that now.
It's a tool and like all tools, it's sensitive to how you use it, and it's better for some purposes than others.
Someone who lacks experience, skill, training, or even the ability to evaluate results may try to use a tool and blame the tool when it doesn't give good results.
That said, the hype around LLMs certainly overstates their capabilities.
I think there's been a huge misconception of what MCP was meant to be in the first place. It is not a transport protocol, and it is not (primarily) designed as a remote RPC server. It is really meant to be a local first means of attaching tooling to an LLM process. The use case of "centralized server that multiple agents connect to" is really only incidental, and I think they honestly made a mistake by including SSE as a transport, as it has confused people to thinking these things need to be hosted somewhere like an API endpoint.
>The scary thing is: I have seen professional human developers write worse code.
This is kind of the rub of it all. If the code works, passes all relevant tests, is reasonably maintainable, and can be fitted into the system correctly with a well defined interface, does it really matter? I mean at that point its kind of like looking at the output of a bytecode compiler and being like "wow what a mess". And it's not like they can't write code up to your stylistic standards, it's just literally a matter of prompting for that.
> If the code works, passes all relevant tests, is reasonably maintainable, and can be fitted into the system correctly with a well defined interface, does it really matter?
You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years.
We did this song and dance pretty recently with dynamic typing. Developers thought it was so much more productive to use dynamically typed languages, because it is in the initial phases. Then years went by, those small, quick-to-make dynamic codebases ended up becoming unmaintainable monstrosities, and those developers who hyped up dynamic typing invented Python/PHP type hinting and Flow for JavaScript, later moving to TypeScript entirely. Nowadays nobody seriously recommends building long-lived systems in untyped languages, but they are still very useful for one-off scripting and more interactive/exploratory work where correctness is less important, i.e. Jupyter notebooks.
I wouldn't be surprised to see the same pattern happen with low-supervision AI code; it's great for popping out the first MVP, but because it generates poor code, the gung-ho junior devs who think they're getting 10x productivity gains will wisen up and realize the value of spending an hour thinking about proper levels of abstraction instead of YOLO'ing the first thing the AI spits out when they want to build a system that's going to be worked on by multiple developers for multiple years.
I think the productivity gains of dynamic typed languages were real, and based on two things: dynamic typing (can) provide certain safety properties trivially, and dynamic typing neatly kills off the utterly inadequate type systems found in mainstream languages when they were launched (the 90s, mostly).
You'll notice the type systems being bolted onto dynamic languages or found in serious attempts at new languages are radically different than the type systems being rejected by the likes of javascript, python, ruby and perl.
> those small, quick-to-make dynamic codebases ended up becoming unmaintainable monstrosities
In my experience, type checking / type hinting already starts to pay off when more than one person is working on an even small-ish code base. Just because it helps you keep in mind what comes/goes to the other guy's code.
And in my experience "me 3 months later" counts as a whole second developer that needs accommodating. The only time I appreciate not having to think about types is on code that I know I will never, ever come back to—stuff like a one off bash script.
Yep, I've seen type hinting even be helpful without a type checker in python. Just as a way for devs to tell each other what they intend on passing. Even when a small percent of the hints are incorrect, having those hints there can still pay off.
> You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years.
Humans also worry about their jobs, especially in PIP-happy companies; they are very well known for writing intentionally over-complicated code that only they understand so that they are irreplaceable
The challenge is that sufficiently bad code could be intentional or it could be from a lack of skill.
For example, I've seen a C# application where every function takes in and outputs an array of objects, supposedly built that way so the internal code can be modified without ever having to worry about the contract breaking. It was just as bad as you are imagining, probably worse. Was that incompetence or building things to be so complicated that others would struggle to work on it?
If your TC is 500k-1M and you don’t feel like job hopping anymore, you’d certainly not want to get hit by a random layoff due to insufficient organizational masculinity or whatever. Maintaining a complex blob of mission critical code is one way of increasing your survival chances, though of course nothing is guaranteed.
hmm I have seen conda env with far too many packages and maybe a lot of current version bumping, and the dev says "who cares" and it naturally gets a bit more.. Intentionally complicated is more like an accusation of wrongdoing.
>The ML world being nearly entirely in Python, much of it untyped (and that the Python type system is pretty weak) is really scary
I think this has a ton to do with the mixed results from "vibe coding" we've seen as the codebase grows in scope and complexity. Agents seem to break down without a good type system. Same goes for JS.
I've just recently started on an Objective-C project using Cline, and it's like nirvana. I can code out an entire interface and have it implemented for me as I'm going. I see no reason it couldn't scale infinitely to massive LOC with good coding practices. The real killer feature is header files. Being able to have your entire projects headers in context at all time, along with a proper compiler for debugging, changes the game for how agents can reason on the whole codebase.
I'm certainly extremely happy for having an extensive type system in my daily driver languages especially when working with AI coding assistance — it's yet another very crucial guard rail that ensures that keeps the AI on track and makes a lot of fuckups downright impossible.
what are you going to do when something suddenly doesn't work and cursor endlessly spins without progress no matter how many "please don't make mistakes" you add? delete the whole thing and try to one-shot it again?
>No one says you have to code like those influencers. You are a software engineer, use AI like one, iteratively.
This is my issue with all the AI naysayers at this point. It seems to all boil down to "haha, stupid noob can't code so he uses AI" in their minds. It's like they are incapable of understanding that there could simultaneously be a bunch of junior devs pushing greenfield YouTube demos of vibe coding, while at the same time expert software engineers are legitimately seeing their productivity increase 10x on serious codebases through judicious use.
Go ahead and keep swinging that hammer, John Henry.
> expert software engineers are legitimately seeing their productivity increase 10x
It's funny you would say this, because we are really commenting on an article where a self-proclaimed "expert" has done that and the "10x" output is terrible.
I have just checked my article — the word "expert" isn't in it, so not quite sure where you got this from.
I'm working in the field professionally since June 1998, and among other things, I was the tech lead on MyHammer.de, Germany's largest craftsman platform, and have built several other mid-scale online platforms over the decades.
How well I have done this, now that's for others to decide.
Quite objectively though, I do have some amount of experience — even a bad developer probably cannot help but pick up some learnings over so many years in relevant real-world projects.
However, and I think I stated this quite clearly, I am expressively not an expert in Python.
And yet, I could realize an actually working solution that solves an actual problem I had in a very real sense (and is nicely humming away for several weeks now).
And this is precisely where yes, I did experience a 10x productivity increase; it would have certainly taken me at least a week or two to realize the same solution myself.
Apologies for implying you are claiming to be an expert software engineer: I took the "senior" in the title and "25 years of experience" in the post to mean similar things as "expert".
I don't doubt this is doing something useful for you. It might even be mostly correct.
But it is not a positive advertisement for what AI can do: just like the code is objectively crap, you can't easily trust the output without a comprehensive review. And without doubting your expertise, I don't think you reviewed it, or you would have caught the same smells I did.
What this article tells me is that when the task is sufficiently non-critical that you can ignore being perfectly correct, you can steer AI coding assistants into producing some garbage code that very well might work or appear to work (when you are making stats, those are tricky even with utmost manual care).
Which is amazing, in my opinion!
But not what the premise seems to be (how a senior will make it do something very nice with decent quality code).
Out of curiosity why did you not build this tool in a language you generally use?
Because I wanted exactly this experience: can I get to the desired result — functionality-wise, if not code-wise! — even if I choose the stack that makes sense in terms of technology, not the one that I happen to be proficient in?
And if I cannot bring language-proficiency to the table — which of my capabilities as a seasoned software&systems guy can I put to use?
In the brown-field projects where my team and I have the AI implement whole features, the resulting code quality — under our sharp and experienced eyes — tends to end up just fine.
I think I need to make the differences between both examples more clear…
Ok, I guess you shouldn't complain that you really got exactly what you wanted.
However, your writing style implied that the result was somehow better because you were otherwise an experienced engineer.
Even your clarification in the post sits right below your statement how your experience made this very smooth, with no explanation that you were going to be happy with bad code as long as it works.
I guess we are slowly but steadily approaching splitting-hairs-territory, so not sure if this is still worth it…
However. I‘m not quite sure where I complained. Certainly not in the post.
And yes, I’m very convinced that the result turned out a lot better than it would have turned out if an unexperienced „vibe coder“ had tried to achieve the same end result.
Actually pretty sure without my extensive and structured requirements and the guard rails, the AI coding session would have ended in a hot mess in the best case, and a non-functioning result in the worst case.
I‘m 100% convinced that these two statements are true and relevant to the topic:
And that b) using said document as the basis for the agent-powered AI coding session had a significant impact on the process as well as the end result of the session.
Like AI could write code perfectly as soon as I thought of it, and that would not improve my productivity 10x. Coding was never the slow part. Everything that goes around coding (like determining that the extra load here is not going to overload things, getting PMs to actually make their mind up what the feature is going to do, etc.), means that there's simply not that much time to be saved on coding activities.
Same argument can be said for not using any tooling really. "Tech is the easy part". No difference typing code on notepad and having zero process/engineering infrastructure I guess. Because stakeholder management is the main engineering skill apparently.
Btw, AI doesn't just code, there are AIs for debugging, monitoring etc too.
1. Tooling obviously does improve performance, but not so huge a margin. Yes, if AI could automate more elements of tooling, that would very much help. If I could tell an AI "bisect this bug, across all projects in our system, starting with this known-bad point", that would be very helpful -- sometimes. And I'm sure we'll get there soon enough. But there is fractal complexity here: what if isolating the bug requires stepping into LLDB, or dumping some object code, or running with certain stressors on certain hardware? So it's not clear that "LLM can produce code from specs, given tight oversight" will map (soon) to "LLM can independently assemble tools together and agentically do what I need done".
2. Even if all tooling were automated, there's still going to be stuff left over. Can the LLM draft architectural specs, reach out to other teams (or their LLMs), sit in meetings and piece together the big picture, sus out what the execs really want us to be working on, etc.? I do spend a significant (double-digit) percentage of my time working on that, so if you eliminate everything else -- then you could get 10x improvement, but going beyond that would start to run up against Amdahl's Law.
If you were to really measure speed improvement of notepad vs a tricked out IDE, it's probably not much. The problem would be the annoyance caused to an engineer who has to manually type out everything.
No, coding speed is really not the bottleneck to software engineer productivity.
> coding speed
> the annoyance caused to an engineer
No one said productivity is this one thing and not that one thing, only you say that because it's convenient for your argument. Productivity is a combination of many things, and again it's not just typing out code that's the only area AI can help.
The context here is AI assisted engineering and you raised the point that non-engineering productivity is more important for engineers, which I think is absurd.
You can have 10x engineering productivity boost and still complete work in the same amount of time, because of communication and human factors. Maybe it's a problem, may be it's not. It's still a productivity gain that will make you work better nonetheless.
I did not raise it, but what was raised was "coding speed": as in, the speed to type code into an editor.
That's not "engineering", but "coding".
Engineering already assumes a lot more than just coding: most importantly, thinking through a problem, learning about it and considering a design that would solve it.
Nobody raised communication or the human factors.
Current LLMs can indisputably help with the learning part, with the same caveats (they will sometimes make shit up). Here we are looking at how much they help with the coding part.
My grievances are simple: an expert programming utilizing AI will be a truly dangerous force.
But that's not what we get in this early stage of grifting. We get 10% marketing buzz on how cool this is with stuff that cannot be recreated in the tool alone, and 89% of lazy or inexperienced developers who just turn in slop with little or no iteration. The latter don't even understand the code they generated.
That 1% will be amazing, it's too bad the barrel is full of rotten apples hiding that potential. The experts also tend to keep to themselves, in my experience. the 89% includes a lot of dunning-kruger as well which makes those outspoken experts questionable (maybe a part of why real experts aren't commenting on their experience).
The point is because it generally produces crap code you have to one shot or else iteration becomes hard. Similar to how a junior would try to refactor their mess and just make a bigger mess
I find it hard to believe that when the AI generates crap code, there is absolutely nothing you can do (change the prompt, modify context, add examples) to make it do what you want. It has not been my experience either. I only use AI to make small modules and refactor instead of one-shoting.
Also I find "AI makes crap code so we should give it a bigger task" illogical.
it seems that there are really, really large differences between models; how well they do, what they respond to.. even among the "best" .. the field does seem to be moving faster
Good insight, and indeed quite exactly my state of mind while creating this particular solution.
Iin this case, I did put in the guard rails to ensure that I reach my goal in hopefully a straight line and a quickly as possible, but to be honest, I did not give much thought to long-term maintainability or ease of extending it with more and more features, because I needed a very specific solution for a use case that doesn't change much.
I'm definitely working differently in my brown-field projects where I'm intimately familiar with the tech stack and architecture — I do very thorough code reviews afterwards.
I think this code is at least twice the size than it needs to be compared to nicer, manually produced Python code: a lot of it is really superfluous.
People have different definitions of "reasonably maintainable", but if code has extra stuff that provides no value, it always perplexes the reader (what is the point of this? what am I missing?), and increases cognitive load significantly.
But if AI coding tools were advertised as "get 10x the output of your least capable teammate", would they really go anywhere?
I love doing code reviews as an opportunity to teach people. Doing this one would suck.
Right, and the reason why professional developers are writing worse code out there is most likely because they simply don't have the time/aren't paid to care more about it. The LLM is then mildly improving the output in this brand of common real world scenario
Other devs will say things like "AI is just a stupid glorified autocomplete, it will never be able to handle my Very Special Unique Codebase. I even spent 20 minutes one time trying out Cursor, and it just failed"
Nope, you're just not that good obviously. I am literally 10x more productive at this point. Sprint goals have become single afternoons. If you are not tuned in to what's going on here
and embracing it, you are going to be completely obsolete in the next 6 months unless you are some extremely niche high level expert. It wont be a dramatic moment where anyone gets "fired for AI". Orgs will just simply not replace people through attrition when they see productivity staying the same (or even increasing) as headcount goes down.
At all the jobs I had, the valuable stuff was shipped features. The baseline was for them to work well and to be released on time. The struggle was never writing the code, it was to clarify specifications. By comparison, learning libraries and languages was fun.
I don't really need AI to write code for me, because that's the easy part. The aspect that it needs to be good at is helping me ship features that works. And to this date, there's never been a compelling showcase for that one.
That's the problem. The new norm will be 10x of pre-AI productivity, nobody will be able justify hand-writing code. And until the quality bar of LLM's/their successors get much better (see e.g. comments above looking at the details in the examples given), you'll get accumulation of errors that are higher than what decent programmers get. With higher LOC and more uninspected complexity, you'll get significantly lower quality overall. The coming wave of AI-coded bugs will be fun for all.
GOTO FAIL;
After spending a week coding exclusively with AI assistants, I got functional results but was alarmed by the code quality. I discovered that I didn't actually save much time, and the generated code was so complex and unfamiliar that I was scared to modify it. I still use Copilot and Claude and would say I'm able to work through problems 2-3x faster than I would be without AI but I wouldn't say I get a 10x improvement.
My projects are much more complex than standard CRUD applications. If you're building simple back-office CRUD apps, you might see a 10x productivity improvement with AI, but that hasn't been my experience with more complex work.
Giving your anecdotal experience is only useful if you include anecdotal context: seniority, years of experience, technology, project size, sprint goal complexity…
Can you talk through specifically what sprint goals you’ve completed in an afternoon? Hopefully multiple examples.
Grounding these conversations in an actual reality affords more context for people to evaluate your claims. Otherwise it’s just “trust me bro”.
And I say this as a Senior SWE who’s successfully worked with ChatGPT to code up some prototype stuff, but haven’t been able to dedicate 100+ hours to work through all the minutia of learning how to drive daily with it.
If you do want to get more into it, I'd suggest something that plugs into your IDE instead of Copy/Paste with ChatGPT. Try Aider or Roo code. I've only used Aider, and run it in the VS terminal. It's much nicer to be able to leave comments to the AI and have it make the changes to discrete parts of the app.
I'm not the OP, but on your other point about completing sprint goals fast - I'm building a video library app for myself, and wanted to add tagging of videos. I was out dropping the kids at classes and waiting for them. Had 20 minutes and said to Aider/Claude - "Give me an implementation for tagging videos." It came back with the changes it would make across multiple files: Creating a new model, a service, configuring the DI container, updating the DB context, updating the UI to add tags to videos and created a basic search form to click on tags and filter the videos. I hit build before the kids had finished and it all worked. Later, I found a small bug - but it saved me a fair bit of time. I've never been a fast coder - I stare at the screen and think way too much (function and variable names are my doom ... and the hardest problem in programming, and AI fixes this for me).
Some developers may be able to do all this in 20 minutes, but I know that I never could have. I've programmed for 25 years across many languages and frameworks, and know my limitations. A terrible memory is one of them. I would normally spend a good chunk of time on StackOverflow and the documentation sites for whatever frameworks/libraries I'm using. The AI has reduced that reliance and keeps me in the zone for longer.
I think experiences vary. AI can work well with greenfield projects, small features, and helping solve annoying problems. I've tried using it on a large Python Django codebase and it works really well if I ask for help with a particular function AND I give it an example to model after for code consistency.
But I have also spent hours asking Claude and ChatGPT with help trying to solve several annoying Django problems and I have reached the point multiple times where they circle back and give me answers that did not previously work in the same context window. Eventually when I figure out the issue, I have fun and ask it "well does it not work as expected because the existing code chained multiple filter calls in django?" and all of a sudden the AI knows what is wrong! To be fair, there was only one sentence in the django documentation that mentions not chaining filter calls on many to many relationships.
>I just don't understand the mentality. Sure, I can see how it can be fun to make an aimbot, and I can see how playing with it for a little while might be fun--or more accurately funny. But I just don't understand why you would routinely sit down with an aimbot. Why not just watch someone else play at that point?
Vindication. The average cheat buyer is someone who gets beat down in the game, and feels personally slighted. This is also why avoiding detection is more important than just worrying about bans. The whole point of modern cheating is to be subtle enough to pass yourself off as a top player, with all the social/financial perks that entails, not to run around in god mode griefing people.
And there it is. None of us will be fired or laid off "because AI". The next person simply won't be hired. And then one day, that next person will be you or I.
Really this is a direct, perfect analogy to the industrial revolution. One small person operating a steam shovel could all of the sudden do the work (faster, with higher quality) that for all of human history required hundreds of strong men to do, and it changed the entire world practically overnight.
Businesses simply do not need the mass droves of SWEs who exist to type out CRUD code anymore. We will go the same way of the manufacturing workers of the 20th century, where the small percentage of those who could deeply specialize and adapt and master the processes were ok, but the vast majority never recovered, and ended up in minimum wage misery.
reply