Software development has always evolved. Sometimes slowly, sometimes quicker.
LLMs have brought a different unlock, and for everything we're seeing become easier, it allows people learn to use the tools to take on solving problems that couldn't be approached before.
Business never cared about code debt, LLM helps building features faster into production and from their POV, that's all that matters.
If your engineers are "wasting time" optimizing artisan code whilst the competition has released their next version, they'll be told to use AI.
The other reality is that by the time you figure out the right abstraction, business has already pivoted, or your feature will be rewritten , or dumped all together. Obviously there are niche industries where this is not the case but in majority of companies, the churn is exhausting.
My point is this: we can shout all we want about "maintenance" and "technical debt", but it's guaranteed to fall on deaf ears.
LLM has validate upper management's assumption that engineering is nothing but a cost center.
I think that our industry is fundamentally shifting.
What is the right, best software organization in the current era of AI coding? This question is critical and wholly unanswered in comprehensive research along the same axis as Accelerate (2018, Forsgren, Humble, Kim).
There are a lot of (excruciatingly) long-form posts about what folks are pioneering but not a whole lot of follow up about what failed. Where are the short posts on the negative space? How did halving your staff work out? Flattening your org? All those dark factories, what haven't they produced? How about all the other things tried, failed, and unceremoniously scrapped?
We need to explore and communicate the negative space more efficiently. Don't repeat the same mistakes, and don't make me read 2653 words when 300 do it better.
Code was very rarely the bottleneck in the first place.
If programmer productivity was something we actively optimized for, we wouldn't have crammed programmers like sardines in warm and noisy open floor offices with 2000 ppm CO2 levels and then further constantly interrupt them with emails and slack pings and meetings all day long, Jira rigmarole wouldn't make up a significant portion of what they did, programmers would have instead mostly been thinking and programming.
We've always had the ability to 2X if not 10X the output of each and every one of those poor souls. You don't end with this sort of programming purgatory because it's a productivity optimum, it very clearly isn't, but because it's a billable hours optimum and/or an org chart clout optimum and/or because of Jevons paradox got hands even in business management and the IT department was allocated too many dollars.
I don't think it changes much for good managers. It should always be able setting people and processes up so the team can land durable measurable impact. The managers that thought the job of software engineers was to write code were bad managers. PRs or LoC were never good metrics.
I think most of this is correct, in spite of potentially being built on a bad assumption.
The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that.
Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally rewritten. LLMs still aren't good at writing maintainable code. Can they write plausibly functional code? Yes. But it won't survive the long term. People using LLMs to write all their code are gambling on them eventually getting to a point where the LLMs can fix their own code. It's possible, but I wouldn't necessarily bet on it.
Where I have found immense value from LLMs is in code review. Repeated review by LLMs catches an amazing amount of potential issues. They really shine on security review, but are very effective with any kind of review.
The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck. Understanding was. And understanding the code is still the bottleneck. But understanding is truly gained during the writing loop. The understanding you gain from pure reading or code review is marginal compared to the understanding you gain while writing.
Most of the time previously spent writing was actually spent updating and deepening our understanding of the system under development. There's no replacement for that understanding in a world where LLMs are doing the writing.
But if you flip it: humans write, LLMs review, then you still get a major gain -- not in speed, but in quality. And you keep the understanding loop intact. I would propose that this might be the best way to deploy LLMs.
I think this is outdated. If you follow spec-driven development, get the model to do all the planning work upfront, review and iterate the plan, write clear markdown file documentation on the abstractions and patterns you want to follow, then you have every opportunity to tell the model how you want it to write the code. If you use Opus or Fable 5 it will then write the code better and faster than you will.
“Not in speed, but in quality” — unfortunately though, not a single CEO, executive, company, VC, investor or anyone with the power to make decisions cares about quality instead of speed.
In my domain since circa Opus 4.5 LLMs write code as good as most engineers given well defined small enough chunk of work. They refactor. They write tests. These days LLM also debug/troubleshoot better than most engineers.
Are they as good as handcrafted code by 0.1% of top software engineers. Generally no. But neither is 99.9% of real code.
LLMs also are good at code reviews. What they'll miss is often the big picture but they can still catch plenty of issues. I still want to see a human in the loop in my domain.
Totally agree that writing the code was never the bottleneck. We're not seeing massive productivity gains even if some code is written faster. It's not just about understanding but also various other activities that happen in large companies and teams.
Also agree LLMs can be used to gain quality but realistically most orgs are going to aim for "fixed or decreasing" quality at lower costs.
This is where I've landed too, I imagine based off all the responses that it depends on domain and also the rigor you care about in your implementation. For me, what I do, and the quality required, there's just not much time (if any) saved on handing off the implementation to an LLM.
But that doesn't mean they're useless either. I use them all the time for review as you mentioned or to knock out one-off scripts that don't go anywhere near source control. There's just no world where I don't need to understand every line of code that I'm responsible for getting into our project.
> writing was never the bottleneck. Understanding was.
Well put. This insight is worth repeating in every discussion on the subject, from software engineering to mathematics.
The problem is that understanding is not the product being sold. The business model is for everyone to become consumers of what the magical genie generates, where the "understanding" is kept on the side of the model providers. This ensures a future generation of consumers dependent on someone else to provide the understanding.
Otherwise, you can create your own answers based on actually understanding the code, theorem, proofs, etc. Smart consumers of LLMs will use them to increase their own knowledge and understanding, so that the service is augmenting their intelligence, not replacing it.
To be honest, it feels like you are contradicting yourself.
If LLMs are, as you stated, really good at catching potential issues, then they are, almost by definition, really good at producing code without potential issues, if guided correctly: all they need to do is inspect and iterate, until they do not find any more potential issue in the code they produced.
> They really shine on security review, but are very effective with any kind of review.
They are getting more and more hostile for making any security assesments. I wonder will they even write secure code in the future if they can’t point vulnerabilities from existing code.
> The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck.
Anyone who's seen tech debt where each item is well known and understood but just big in scope knows that this isn't true universally - depending on your team size and composition, any damn thing can be the bottleneck, often at different times too. I'll take everything that helps me resolve them with reasonable trade-offs, even if I need to come up with ways to mitigate the issues created by those trade-offs (like enforcing >90% test coverage as a starting point).
In my experience, management is mostly pissing away the gains made by AI by either:
1. Pursuing polish and quality beyond previous norms
2. Replacing $100/mo/seat SAAS with something coded by a junior costing $200/day to develop over months.
The cost of code approaches zero, but the cost of having accountability, and hosting remains the same, and so individuals need to only coordinate to the extent that those things remain finite resources. Management needs to stop insisting that their directs adopt each others vibe coded tooling.
AI reduces the cost of writing code, but it makes adding things that nobody uses even cheaper. The bottleneck then becomes deciding what deserves to exist—and having the discipline to remove the rest. So this will imply more time spent in code reviews that lead to more iterations in PR's.
AI is doing a good job on writting code these days! Nothing against it; I use it every day, but the context switching is costing us a lot!
I’m struggling to imagine a project that would require more than one talented engineer and a bucket of tokens anymore.
I think perhaps the assumption that engineering managers should have any employees may be outdated.
I can imagine average and mediocre engineers equipped with tokens could create chaos and debt on a scale never before imaginable, so it’s easy to see how orgs who still have these employees around are struggling with the transition.
The reality is you need to get rid of them all, and replace them with the most experienced highest paid person you can find. In the near future that person will become obsolete too.
> I think perhaps the assumption that engineering managers should have any employees may be outdated.
to me, the latest models and harnesses turn all devs into an engineering manager with one direct report. Some devs naturally take up the role and great things happen, for others it's like trying to get a fish to ride a bicycle. This is how it was pre-genai too so i don't think there's a right or wrong answer, some will take off with the technology and some will struggle.
Would that single person handle different topics such as: UI/UX, security, backups, distributed systems, data migrations, infrastructure, …?
Sure thing there are engineers out there that know some about all of the above (I personally do all of that on personal projects) but you still need specialists, otherwise it’s you alone with all the unknown unknowns that the llm may claim to solve, but you cannot verify
As I understand it, the purpose of management is to match financial resources with material+human resources to perform feasible tasks. There is nothing here I see that can't be done by an experienced token generator. If anything, automating management seems easier than automating engineering.
As for leadership, it can be done by the investors.
You can automate work but never owning the consequences. AI tasks emerge from human contexts, they perform work in the context and finally the outcomes collect in the context - gains, losses, risks, costs. So AI is great but it needs our skin for the start, middle and end of a task.
This is such a simplistic view I have difficulties deciding where to even start. Think of a manager as someone who engineers the fabric of the organization. Most of my time is spent debugging, communicating, finding the right abstractions, configuring processes - all very similar to the engineering work I previously did.
"Shield the team from the business." The assumption underneath this one is that attention is finite and context switching is expensive. That assumption is intact. What changed is the cost of starving the team of context. Engineers prompting AI tools without business context just produce fluent, plausible, wrong work, at scale."
Too many teams and organizations have business types, mostly PM's who seek to lord over their area of know how and see themselves as delegators and mini CEOs, actively avoid looping engineers in to validate themselves. Engineers need to take on PM roles, and the PM role needs to be 1:50+ eng or go.
Coding used to be an expensive task. Seeing how quickly repositories have grown with the rise of AI coding, it's clear how much people wanted to build things but were thirsting for the means to do so. Even languages like R, which were mostly used by graduate students and experts, have seen a massive increase in usage since vibe coding became popular.
Honestly, when people say AI code quality is bad, Linus himself has said it's now genuinely useful. AI is useful and writes better code than most people. Even in competitive coding, tourist lost to AI. And in the most logical field of all, mathematics, AI is churning out an enormous number of theorems.
Looking at all this, it's fair to say AI is at least at a PhD level of technical ability, and most people would admit they don't have PhD level skills. Of course, there are still many people who code better than AI. But at least when it comes to unfolding logical structures, AI has a higher chance of being more logical than humans. Within a given framework, AI constructs much more logical structures.
That's why I think the article's use of the word 'semantic' is right. It's humans who form the framework, and that's the semantic, while AI fills the empty spaces inside it. If you feed it a flawed framework, it fails.
And the fact that AI is more logical than humans is paradoxically a greater risk. Human developers can rely on tacit knowledge to make reasonable compromises even when the requirements, the framework, are sloppy. AI can't do that. If there's a logical gap in the framework humans design, AI will exploit that weakness and expand the state space into regions we can't cognitively grasp.
Programming is ultimately about how you occupy state space. The problem is that as the program grows, the cognitively inaccessible territory keeps expanding. So we distribute trust across reliable points, libraries, frameworks, and for my own code, once it exceeds tens of thousands of lines, I rely on tests and gates.
Honestly, the idea of understanding everything in a program is a purely academic claim. Once the program gets large, it's impossible. No one can know every external factor, test bug, or unexpected interaction.
The issue is that with LLMs, when the prompt input goes deeper into the semantic space, it also reaches into areas I don't understand, producing code at a depth that's untestable.
For example, I might be an expert in domain A but a beginner in domain B. If I inject expert level knowledge for domain A into the AI, the AI will try to match that level in domain B as well. That results in code I can't understand or modify, and eventually, I'm left with no choice but to replace all the code with AI generated code.
So I'm wondering what to do about this. Should I focus on gaining empirical experience in handling black boxes? Or should I stick with smaller, human written codebases?
But realistically, the current situation, where I can build bigger and touch more things, is more enjoyable to me. I think what I actually enjoyed wasn't programming itself, but the act of creating something.
50 comments
[ 170 ms ] story [ 478 ms ] threadLLMs have brought a different unlock, and for everything we're seeing become easier, it allows people learn to use the tools to take on solving problems that couldn't be approached before.
Not everything has to be written as though it’s a middle manager’s idea of what makes for a good TED talk.
If your engineers are "wasting time" optimizing artisan code whilst the competition has released their next version, they'll be told to use AI.
The other reality is that by the time you figure out the right abstraction, business has already pivoted, or your feature will be rewritten , or dumped all together. Obviously there are niche industries where this is not the case but in majority of companies, the churn is exhausting.
My point is this: we can shout all we want about "maintenance" and "technical debt", but it's guaranteed to fall on deaf ears.
LLM has validate upper management's assumption that engineering is nothing but a cost center.
I think that our industry is fundamentally shifting.
Does this guy have access to Gemini 4 already?
I'm guessing Gemma 4 was happy to be mistaken for Gemini and didn't catch this mistake.
There are a lot of (excruciatingly) long-form posts about what folks are pioneering but not a whole lot of follow up about what failed. Where are the short posts on the negative space? How did halving your staff work out? Flattening your org? All those dark factories, what haven't they produced? How about all the other things tried, failed, and unceremoniously scrapped?
We need to explore and communicate the negative space more efficiently. Don't repeat the same mistakes, and don't make me read 2653 words when 300 do it better.
If programmer productivity was something we actively optimized for, we wouldn't have crammed programmers like sardines in warm and noisy open floor offices with 2000 ppm CO2 levels and then further constantly interrupt them with emails and slack pings and meetings all day long, Jira rigmarole wouldn't make up a significant portion of what they did, programmers would have instead mostly been thinking and programming.
We've always had the ability to 2X if not 10X the output of each and every one of those poor souls. You don't end with this sort of programming purgatory because it's a productivity optimum, it very clearly isn't, but because it's a billable hours optimum and/or an org chart clout optimum and/or because of Jevons paradox got hands even in business management and the IT department was allocated too many dollars.
The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that.
Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally rewritten. LLMs still aren't good at writing maintainable code. Can they write plausibly functional code? Yes. But it won't survive the long term. People using LLMs to write all their code are gambling on them eventually getting to a point where the LLMs can fix their own code. It's possible, but I wouldn't necessarily bet on it.
Where I have found immense value from LLMs is in code review. Repeated review by LLMs catches an amazing amount of potential issues. They really shine on security review, but are very effective with any kind of review.
The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck. Understanding was. And understanding the code is still the bottleneck. But understanding is truly gained during the writing loop. The understanding you gain from pure reading or code review is marginal compared to the understanding you gain while writing.
Most of the time previously spent writing was actually spent updating and deepening our understanding of the system under development. There's no replacement for that understanding in a world where LLMs are doing the writing.
But if you flip it: humans write, LLMs review, then you still get a major gain -- not in speed, but in quality. And you keep the understanding loop intact. I would propose that this might be the best way to deploy LLMs.
Are they as good as handcrafted code by 0.1% of top software engineers. Generally no. But neither is 99.9% of real code.
LLMs also are good at code reviews. What they'll miss is often the big picture but they can still catch plenty of issues. I still want to see a human in the loop in my domain.
Totally agree that writing the code was never the bottleneck. We're not seeing massive productivity gains even if some code is written faster. It's not just about understanding but also various other activities that happen in large companies and teams.
Also agree LLMs can be used to gain quality but realistically most orgs are going to aim for "fixed or decreasing" quality at lower costs.
But that doesn't mean they're useless either. I use them all the time for review as you mentioned or to knock out one-off scripts that don't go anywhere near source control. There's just no world where I don't need to understand every line of code that I'm responsible for getting into our project.
Well put. This insight is worth repeating in every discussion on the subject, from software engineering to mathematics.
The problem is that understanding is not the product being sold. The business model is for everyone to become consumers of what the magical genie generates, where the "understanding" is kept on the side of the model providers. This ensures a future generation of consumers dependent on someone else to provide the understanding.
Otherwise, you can create your own answers based on actually understanding the code, theorem, proofs, etc. Smart consumers of LLMs will use them to increase their own knowledge and understanding, so that the service is augmenting their intelligence, not replacing it.
If LLMs are, as you stated, really good at catching potential issues, then they are, almost by definition, really good at producing code without potential issues, if guided correctly: all they need to do is inspect and iterate, until they do not find any more potential issue in the code they produced.
They are getting more and more hostile for making any security assesments. I wonder will they even write secure code in the future if they can’t point vulnerabilities from existing code.
Anyone who's seen tech debt where each item is well known and understood but just big in scope knows that this isn't true universally - depending on your team size and composition, any damn thing can be the bottleneck, often at different times too. I'll take everything that helps me resolve them with reasonable trade-offs, even if I need to come up with ways to mitigate the issues created by those trade-offs (like enforcing >90% test coverage as a starting point).
1. Pursuing polish and quality beyond previous norms
2. Replacing $100/mo/seat SAAS with something coded by a junior costing $200/day to develop over months.
The cost of code approaches zero, but the cost of having accountability, and hosting remains the same, and so individuals need to only coordinate to the extent that those things remain finite resources. Management needs to stop insisting that their directs adopt each others vibe coded tooling.
I work at a company where the biggest problems are not 'writing code', they are:
- Organising teams
- Designing the system
- Prioritisation of work
The fuckups that we make on a daily bases are not 'code errors' they are failures in THOSE three things. I'll go into detail if anyone cares.
AI is doing a good job on writting code these days! Nothing against it; I use it every day, but the context switching is costing us a lot!
I think perhaps the assumption that engineering managers should have any employees may be outdated.
I can imagine average and mediocre engineers equipped with tokens could create chaos and debt on a scale never before imaginable, so it’s easy to see how orgs who still have these employees around are struggling with the transition.
The reality is you need to get rid of them all, and replace them with the most experienced highest paid person you can find. In the near future that person will become obsolete too.
to me, the latest models and harnesses turn all devs into an engineering manager with one direct report. Some devs naturally take up the role and great things happen, for others it's like trying to get a fish to ride a bicycle. This is how it was pre-genai too so i don't think there's a right or wrong answer, some will take off with the technology and some will struggle.
Sure thing there are engineers out there that know some about all of the above (I personally do all of that on personal projects) but you still need specialists, otherwise it’s you alone with all the unknown unknowns that the llm may claim to solve, but you cannot verify
Who wants merely plausible code?
As I understand it, the purpose of management is to match financial resources with material+human resources to perform feasible tasks. There is nothing here I see that can't be done by an experienced token generator. If anything, automating management seems easier than automating engineering.
As for leadership, it can be done by the investors.
Too many teams and organizations have business types, mostly PM's who seek to lord over their area of know how and see themselves as delegators and mini CEOs, actively avoid looping engineers in to validate themselves. Engineers need to take on PM roles, and the PM role needs to be 1:50+ eng or go.
Honestly, when people say AI code quality is bad, Linus himself has said it's now genuinely useful. AI is useful and writes better code than most people. Even in competitive coding, tourist lost to AI. And in the most logical field of all, mathematics, AI is churning out an enormous number of theorems.
Looking at all this, it's fair to say AI is at least at a PhD level of technical ability, and most people would admit they don't have PhD level skills. Of course, there are still many people who code better than AI. But at least when it comes to unfolding logical structures, AI has a higher chance of being more logical than humans. Within a given framework, AI constructs much more logical structures.
That's why I think the article's use of the word 'semantic' is right. It's humans who form the framework, and that's the semantic, while AI fills the empty spaces inside it. If you feed it a flawed framework, it fails.
And the fact that AI is more logical than humans is paradoxically a greater risk. Human developers can rely on tacit knowledge to make reasonable compromises even when the requirements, the framework, are sloppy. AI can't do that. If there's a logical gap in the framework humans design, AI will exploit that weakness and expand the state space into regions we can't cognitively grasp.
Programming is ultimately about how you occupy state space. The problem is that as the program grows, the cognitively inaccessible territory keeps expanding. So we distribute trust across reliable points, libraries, frameworks, and for my own code, once it exceeds tens of thousands of lines, I rely on tests and gates.
Honestly, the idea of understanding everything in a program is a purely academic claim. Once the program gets large, it's impossible. No one can know every external factor, test bug, or unexpected interaction.
The issue is that with LLMs, when the prompt input goes deeper into the semantic space, it also reaches into areas I don't understand, producing code at a depth that's untestable.
For example, I might be an expert in domain A but a beginner in domain B. If I inject expert level knowledge for domain A into the AI, the AI will try to match that level in domain B as well. That results in code I can't understand or modify, and eventually, I'm left with no choice but to replace all the code with AI generated code.
So I'm wondering what to do about this. Should I focus on gaining empirical experience in handling black boxes? Or should I stick with smaller, human written codebases?
But realistically, the current situation, where I can build bigger and touch more things, is more enjoyable to me. I think what I actually enjoyed wasn't programming itself, but the act of creating something.