This works, until it doesn’t. I’m continuously shocked by these stories, where so many people put the future of their job/company in the hands of these agents after only a few months of existing.
I still constantly run into bad output from LLMs, from code to basic questions. I don’t understand how anyone can hand things over to something that is laughably wrong on a pretty regular basis, often in subtle ways that won’t be noticed by someone who isn’t reading closely and thinking critically.
They’ve gotten better, but I still regularly give them the old Nick Burns treatment, push it out of the way, and do it myself.
There's nothing shocking about this. The vast majority of software/source code is pretty terrible anyways, code that is full of bugs, slow to use, has little to no automated tests and very hard to maintain.
To the extent that it gets fixed or works at all, it's not because of competent developers doing rigorous analysis of the software, it's because either someone testing it or using it gets annoyed, reports an issue, and then that specific issue gets patched out.
If using LLMs to perform a similar function shocks you, then you should have been shocked already by the proliferation of pretty bad software for the better part of the last couple of decades.
So many criticisms of LLMs assume that people have been writing software very diligently, applying a high standard of engineering, subjecting the code to a battery of rigorous tests, passing it through a strict review process... and that does happen for some software, especially software that is commonly used, but it's not true for the vast majority of software developed.
AI is no good, but neither are people, isn’t a great sales pitch.
I think for small tools that people want to make for themselves, that’s great. Where I see a problems are when other people and money get involved. If something goes wrong, who is accountable? Claude wrote it, Claude reviewed it, Claude submitted the PR… yet Claude can’t have any real accountability.
It's an absolutely phenomenal sales pitch to executives. A ton of automation is sold on the basis that it's probably not going to be as good as having a dedicated person do it, but that automation leads to much lower maintenance scales better, is more deterministic and reproducible.
It's a really fun philosophical exercise to ask what it means for them to be "wrong." My perspective is that they are fantastic at association and generalization (of language and symbols in particular), but whether they're identifying the associations you care about or generalizing to the level of abstraction you're aiming for is a complete crapshoot. If you aren't checking and correcting them, and discarding the misfires, you will end up with a very pretty Tower of Babel.
One area where I feel safe saying they are “wrong”, rather than just going with a different assumption that was left unsaid, would be when it makes up API endpoints. It sees the general pattern in an API, then makes up an endpoint that sounds good, follows the pattern, but isn’t actually implemented.
I’ve also seen a lot of issues with co-workers using an LLM to write their readme files. I look at the readme for what return values I should get, go to use them, and get an error. I check the code, and sure enough, none of the variables in the readme exist. The LLM just through they sounded good. Things like this I would say are pretty objectively wrong.
My personal experience: writing code has always been the easy part. AI does most of that now.
Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately.
I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-switchy than other teams.
As others in this thread have noted, the situation is still evolving. However, I worry less each day about being replaced by AI. There has always been more work than available bandwidth in my experience.
What seems clear to me is that expectations around velocity and throughput will increase (are increasing). AI use will be required to meet those expectations. Learning to use this new tool effectively will be essential for career progression (and preservation).
Agree. Also, there is a lot fog at the moment. AI generates more code, we need a lot of markdowns now to teach it how to write "good code"... and <insert here a lot of AI processes>. But at the end... a programmer has to take ownership of that code and responsibility, meaning: reading A LOT of code and/or coding more code.
What are you writing that Claude is actually writing all of it? Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash. Claude seems really great at fix this unit test, generate this boiler plate, take this uml and build this framework out. But when I am doing refactorings, or implementing things that are beyond monotonous, I end up writing it all by hand. My best luck is still do the design, query AI for possible choices, sketch out the framework of what I am writing, have AI critique my plan, and then have AI design individual methods, then fix what it writes.
I'm a Senior Freelance Programmer, I can see many of my past and present clients moving towards the exact path you described. I keep warning them during meetings that Claude model isn't sustainable for long, eventually the VCs will come for their revenues and Claude will be forced to close their access to all but the most enterprisey ones with deep pockets. The mere electricity cost for that kind of high level reasoning and abstraction can't be subsidized forever. However, there are other forces which pull them towards Claude and AI workflows. Most of the clients are in a "wait and watch" mode right now, using LLM assistance for code generation but not fully depending on them.
Before LLMs came, there used to be the technical debt to deal with in a project, now there is also the added cognitive debt which is way more subtle and impactful long-term. If your source of truth isn't source code but a prompt (or even a series of prompts with branches) and the executor of prompts is a non-deterministic agent, I think you've already lost the battle there.
You ignore that Claude are not alone, tech progresses and reduce costs, and there are always the Chinese alternatives which are becoming sufficiently better over time.
I have had some truly spectacular results that still kind of stagger me in the last few months using Claude in my hobby projects -- but even though Claude insists on trying to slip its name into the git history as credit it's not Claude -- it's me. Someone who has studied CS and software engineering for decades will craft different prompts from someone without that background. A suggested axiom: there is nothing I can build with Claude that I could not build myself with my current level of CS knowledge, assuming I had infinite focus and time. In my hands it can go as far I could anyway, and no further. (But it is faster!) My experience bears that out so far.
> Someone who has studied CS and software engineering for decades will craft different prompts from someone without that background.
This, to me, is the biggest differentiator. In terms of results, there's a huge yawning chasm between the person who says "Claude make me a $thing" versus the person who puts in the effort to lay down the overall architecture, gives some thoughts to libraries and dependencies, performance trade-offs etc, and only then begins prompting.
Knowing how to implement Djikstra or a linked list by heart is no longer important. Actual software engineering skills are more important than ever.
The gap is closing; a shitty wannabe programmer will eventually learn the structures one way or another. Agentic coding just got many new people involved, and these new people create noise.
The profession has already changed. For the past eight months, AI has been competent enough to code like the best human programmer, but strangely, the software isn't any better yet. Everyone has lost sight of what the profession truly is. It's not just about coding; it's about software engineering. Our role is no longer that of programmers, AI has taken over that role. Our role is that of engineers who manage programming agents. Every attempt to have AI develop a medium-to-large project fails because the goal is to solve everything with a magic four-line prompt. We're forgetting the structural aspect, the engineering side. We must treat the tool as just that: a tool. The direction and responsibility remain in our hands. It's not about reviewing the code line by line; it's about ensuring that the product faithfully represents a well-planned engineering intent. That's why the concept of AI-augmented Software Engineering is so important.
Basically, in a decade or so, we'll be completely out of the loop in software development; even this title won't exist anymore (like the 2000's webmaster). We'll still be around, but with different roles.
For what it’s worth, I find comments and articles with assertive predictions like this difficult to take at face value.
I don’t even disagree with the premise, but it shifts the burden of assessing likelihood back onto the reader, so it doesn’t really add much value to me.
- LLM adoption varies across the org. Some are heavy users and some less. Some suspicious some less.
Where are we heading? Depends on model/harness capabilities. Likely some sort of mix where some projects will still require expert humans and others will just be vibe coded. How much we lean in that direction - we'll see.
Not the same thing. Developers' clients are being approached by thousands of people instead of a handful. It creates the illusion that everyone can do the same thing for cheaper.
From what you said: Not looking at code is bad, not because Claude can slip a few bugs (it can), but because LLMs tend to default to writing more code and features than needed, which isn't a good thing. I see a lot of people making 10+ PRs per day, but most of them are just going back to fix earlier PRs.
Claude always likes to "go big," for example, by choosing tools that can support millions of concurrent users or by adding unnecessary layers of abstraction that create more maintenance pain. I guess that's good for LLM companies, since more tokens are spent fixing the mess it caused.
Every time I enter plan mode for a huge feature, I end up cutting about 30-60% of the task scope before the LLM can actually start the work. I review the final code, and I still find things to cut. As said before "The best code is no code, or code you don’t have to maintain" [0]
I mean, literally the answer is that nobody knows. Maybe the robots replace us all. Maybe they shift those who remain into being some combination of Product Manager and QA. Maybe there's still a role for a technical overseer even in the medium-long run.
But it sounds like you're really asking about the state of the world today. If so, I don't think that ideal state is like your friend's company (or at least, as it appeared to be to you). It might be possible that you can make that "dark factory" pattern work (StrongDM seems to be doing it), but it would require infrastructure and discipline that I doubt they're mustering. Think about how CD didn't involve taking a sloppy build process with no testing or observability and just going straight to prod -- it required building up a lot of infra and discipline first.
But on the other hand, I don't think the ideal present involves artisan hand-crafting code either. I haven't written a line of code by hand in enough months that it would genuinely feel weird if I were to try to program that way despite decades of having done just that. That era's done with, and moderate normie practices right now today are more about supervising and guiding agents than about chiseling code into clay tablets.
> I had an interview where I was asked the obligatory “what’s your Al workflow” and I said I use it for searching documentation and writing small functions or boilerplate that are tedious. Then I was asked whether I use Cursor. I said no, and immediately was told that “I’d be a better programmer if I used Cursor”. I have 13 years of software engineering experience, and was talked down by an Al startup with no minimal viable prototype. Then I was told I did not have the experience for the role. I love this timeline so much
This has always been a very different profession depending on where you work and what you're working on.
I haven't worked at a startup in over a decade, but the stories I hear now sound the same as back then. There's lots of wasted effort for mediocre to poor code destined to be rewritten or thrown away until there's enough investment to justify more work. At which point, "more work" just means more sprawling slop instead of fixing the technical debt rotting at the foundation.
AI just put a spotlight on the futility of trying to run before you can walk. Whether so many founders are going to stay in denial about it is yet to be seen. Statistics about any line of business says yes. This is how most businesses fail and most of them have to fail.
For the last 6 decades or so, a computer was a machine assumed to operate with high levels of precision and deterministic outputs. Such precision enabled spacecraft like Voyager 1 & 2 to travel billions of miles from Earth, staying on course, semi-operational and sending telemetry- 50 years after launch.
Now we have machines that, when asked to produce a paperclip, may instead produce a butter knife, or a banana, or maybe just a "try again later".
These modern "tools" are quite a different animal. They're more akin to roulette wheels that generate massive amounts of heat and CO2.
> ask claude to write, and ask claude to explain
This works, until it doesn’t. I’m continuously shocked by these stories, where so many people put the future of their job/company in the hands of these agents after only a few months of existing.
I still constantly run into bad output from LLMs, from code to basic questions. I don’t understand how anyone can hand things over to something that is laughably wrong on a pretty regular basis, often in subtle ways that won’t be noticed by someone who isn’t reading closely and thinking critically.
They’ve gotten better, but I still regularly give them the old Nick Burns treatment, push it out of the way, and do it myself.
There's nothing shocking about this. The vast majority of software/source code is pretty terrible anyways, code that is full of bugs, slow to use, has little to no automated tests and very hard to maintain.
To the extent that it gets fixed or works at all, it's not because of competent developers doing rigorous analysis of the software, it's because either someone testing it or using it gets annoyed, reports an issue, and then that specific issue gets patched out.
If using LLMs to perform a similar function shocks you, then you should have been shocked already by the proliferation of pretty bad software for the better part of the last couple of decades.
So many criticisms of LLMs assume that people have been writing software very diligently, applying a high standard of engineering, subjecting the code to a battery of rigorous tests, passing it through a strict review process... and that does happen for some software, especially software that is commonly used, but it's not true for the vast majority of software developed.
AI is no good, but neither are people, isn’t a great sales pitch.
I think for small tools that people want to make for themselves, that’s great. Where I see a problems are when other people and money get involved. If something goes wrong, who is accountable? Claude wrote it, Claude reviewed it, Claude submitted the PR… yet Claude can’t have any real accountability.
It's an absolutely phenomenal sales pitch to executives. A ton of automation is sold on the basis that it's probably not going to be as good as having a dedicated person do it, but that automation leads to much lower maintenance scales better, is more deterministic and reproducible.
It's a really fun philosophical exercise to ask what it means for them to be "wrong." My perspective is that they are fantastic at association and generalization (of language and symbols in particular), but whether they're identifying the associations you care about or generalizing to the level of abstraction you're aiming for is a complete crapshoot. If you aren't checking and correcting them, and discarding the misfires, you will end up with a very pretty Tower of Babel.
One area where I feel safe saying they are “wrong”, rather than just going with a different assumption that was left unsaid, would be when it makes up API endpoints. It sees the general pattern in an API, then makes up an endpoint that sounds good, follows the pattern, but isn’t actually implemented.
I’ve also seen a lot of issues with co-workers using an LLM to write their readme files. I look at the readme for what return values I should get, go to use them, and get an error. I check the code, and sure enough, none of the variables in the readme exist. The LLM just through they sounded good. Things like this I would say are pretty objectively wrong.
My personal experience: writing code has always been the easy part. AI does most of that now.
Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately.
I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-switchy than other teams.
As others in this thread have noted, the situation is still evolving. However, I worry less each day about being replaced by AI. There has always been more work than available bandwidth in my experience.
What seems clear to me is that expectations around velocity and throughput will increase (are increasing). AI use will be required to meet those expectations. Learning to use this new tool effectively will be essential for career progression (and preservation).
Agree. Also, there is a lot fog at the moment. AI generates more code, we need a lot of markdowns now to teach it how to write "good code"... and <insert here a lot of AI processes>. But at the end... a programmer has to take ownership of that code and responsibility, meaning: reading A LOT of code and/or coding more code.
Spot on, in my experience.
What are you writing that Claude is actually writing all of it? Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash. Claude seems really great at fix this unit test, generate this boiler plate, take this uml and build this framework out. But when I am doing refactorings, or implementing things that are beyond monotonous, I end up writing it all by hand. My best luck is still do the design, query AI for possible choices, sketch out the framework of what I am writing, have AI critique my plan, and then have AI design individual methods, then fix what it writes.
No mention of whether the product is actually good.
I'm a Senior Freelance Programmer, I can see many of my past and present clients moving towards the exact path you described. I keep warning them during meetings that Claude model isn't sustainable for long, eventually the VCs will come for their revenues and Claude will be forced to close their access to all but the most enterprisey ones with deep pockets. The mere electricity cost for that kind of high level reasoning and abstraction can't be subsidized forever. However, there are other forces which pull them towards Claude and AI workflows. Most of the clients are in a "wait and watch" mode right now, using LLM assistance for code generation but not fully depending on them.
Before LLMs came, there used to be the technical debt to deal with in a project, now there is also the added cognitive debt which is way more subtle and impactful long-term. If your source of truth isn't source code but a prompt (or even a series of prompts with branches) and the executor of prompts is a non-deterministic agent, I think you've already lost the battle there.
You ignore that Claude are not alone, tech progresses and reduce costs, and there are always the Chinese alternatives which are becoming sufficiently better over time.
I have had some truly spectacular results that still kind of stagger me in the last few months using Claude in my hobby projects -- but even though Claude insists on trying to slip its name into the git history as credit it's not Claude -- it's me. Someone who has studied CS and software engineering for decades will craft different prompts from someone without that background. A suggested axiom: there is nothing I can build with Claude that I could not build myself with my current level of CS knowledge, assuming I had infinite focus and time. In my hands it can go as far I could anyway, and no further. (But it is faster!) My experience bears that out so far.
> Someone who has studied CS and software engineering for decades will craft different prompts from someone without that background.
This, to me, is the biggest differentiator. In terms of results, there's a huge yawning chasm between the person who says "Claude make me a $thing" versus the person who puts in the effort to lay down the overall architecture, gives some thoughts to libraries and dependencies, performance trade-offs etc, and only then begins prompting.
Knowing how to implement Djikstra or a linked list by heart is no longer important. Actual software engineering skills are more important than ever.
> Knowing how to implement Djikstra or a linked list by heart is no longer important.
This was never important. The important part was always knowing when to use them.
The gap is closing; a shitty wannabe programmer will eventually learn the structures one way or another. Agentic coding just got many new people involved, and these new people create noise.
The profession has already changed. For the past eight months, AI has been competent enough to code like the best human programmer, but strangely, the software isn't any better yet. Everyone has lost sight of what the profession truly is. It's not just about coding; it's about software engineering. Our role is no longer that of programmers, AI has taken over that role. Our role is that of engineers who manage programming agents. Every attempt to have AI develop a medium-to-large project fails because the goal is to solve everything with a magic four-line prompt. We're forgetting the structural aspect, the engineering side. We must treat the tool as just that: a tool. The direction and responsibility remain in our hands. It's not about reviewing the code line by line; it's about ensuring that the product faithfully represents a well-planned engineering intent. That's why the concept of AI-augmented Software Engineering is so important.
I've posted a recent article about the future of software development https://saturnino.substack.com/p/out-of-the-loop?r=7eqhw&utm...
Basically, in a decade or so, we'll be completely out of the loop in software development; even this title won't exist anymore (like the 2000's webmaster). We'll still be around, but with different roles.
For what it’s worth, I find comments and articles with assertive predictions like this difficult to take at face value.
I don’t even disagree with the premise, but it shifts the burden of assessing likelihood back onto the reader, so it doesn’t really add much value to me.
For me in large tech:
- Humans still own the code
- All code reviewed by humans
- LLM adoption varies across the org. Some are heavy users and some less. Some suspicious some less.
Where are we heading? Depends on model/harness capabilities. Likely some sort of mix where some projects will still require expert humans and others will just be vibe coded. How much we lean in that direction - we'll see.
Remember you had to quit social media to keep your sanity in check? Ok, now AI. Same thing.
Not the same thing. Developers' clients are being approached by thousands of people instead of a handful. It creates the illusion that everyone can do the same thing for cheaper.
From what you said: Not looking at code is bad, not because Claude can slip a few bugs (it can), but because LLMs tend to default to writing more code and features than needed, which isn't a good thing. I see a lot of people making 10+ PRs per day, but most of them are just going back to fix earlier PRs.
Claude always likes to "go big," for example, by choosing tools that can support millions of concurrent users or by adding unnecessary layers of abstraction that create more maintenance pain. I guess that's good for LLM companies, since more tokens are spent fixing the mess it caused.
Every time I enter plan mode for a huge feature, I end up cutting about 30-60% of the task scope before the LLM can actually start the work. I review the final code, and I still find things to cut. As said before "The best code is no code, or code you don’t have to maintain" [0]
0: https://www.simplethread.com/20-things-ive-learned-in-my-20-...
I mean, literally the answer is that nobody knows. Maybe the robots replace us all. Maybe they shift those who remain into being some combination of Product Manager and QA. Maybe there's still a role for a technical overseer even in the medium-long run.
But it sounds like you're really asking about the state of the world today. If so, I don't think that ideal state is like your friend's company (or at least, as it appeared to be to you). It might be possible that you can make that "dark factory" pattern work (StrongDM seems to be doing it), but it would require infrastructure and discipline that I doubt they're mustering. Think about how CD didn't involve taking a sloppy build process with no testing or observability and just going straight to prod -- it required building up a lot of infra and discipline first.
But on the other hand, I don't think the ideal present involves artisan hand-crafting code either. I haven't written a line of code by hand in enough months that it would genuinely feel weird if I were to try to program that way despite decades of having done just that. That era's done with, and moderate normie practices right now today are more about supervising and guiding agents than about chiseling code into clay tablets.
There was a reddit thread earlier very similar some interesting comments there too:
https://www.reddit.com/r/technology/comments/1ueidyv/softwar...
> I had an interview where I was asked the obligatory “what’s your Al workflow” and I said I use it for searching documentation and writing small functions or boilerplate that are tedious. Then I was asked whether I use Cursor. I said no, and immediately was told that “I’d be a better programmer if I used Cursor”. I have 13 years of software engineering experience, and was talked down by an Al startup with no minimal viable prototype. Then I was told I did not have the experience for the role. I love this timeline so much
We're still running the race, but it's just not on foot anymore. You can still run it into the wall if you're not careful where you're going.
how is that company doing?
i think that is a more important question that you shouldn't ignore.
do they have growing revenue?
This has always been a very different profession depending on where you work and what you're working on.
I haven't worked at a startup in over a decade, but the stories I hear now sound the same as back then. There's lots of wasted effort for mediocre to poor code destined to be rewritten or thrown away until there's enough investment to justify more work. At which point, "more work" just means more sprawling slop instead of fixing the technical debt rotting at the foundation.
AI just put a spotlight on the futility of trying to run before you can walk. Whether so many founders are going to stay in denial about it is yet to be seen. Statistics about any line of business says yes. This is how most businesses fail and most of them have to fail.
For the last 6 decades or so, a computer was a machine assumed to operate with high levels of precision and deterministic outputs. Such precision enabled spacecraft like Voyager 1 & 2 to travel billions of miles from Earth, staying on course, semi-operational and sending telemetry- 50 years after launch.
Now we have machines that, when asked to produce a paperclip, may instead produce a butter knife, or a banana, or maybe just a "try again later".
These modern "tools" are quite a different animal. They're more akin to roulette wheels that generate massive amounts of heat and CO2.