Writing code is a small part of everyday's job of a software engineer. The article's table reflects this fairly well.
AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities. If code generation speeds up by 5x while those bottlenecks don't, you've mostly increased the team's work queue rather than its throughput.
With the current capabilities, models still need constant babysitting and course correction. An engineer who lacks the skills to guide them can end up creating more work for the rest of the team. AI makes it easy to generate code faster than you can understand it, and that cost is paid during code review, debugging, and maintenance by colleagues, whose confidence in that engineer's skills may be affected by his use of AI.
What looks like a productivity gain for one engineer can become a productivity loss for the team as a whole.
For anyone who hadn't heard this before, like me. <3
In computer architecture, Amdahl's law (or Amdahl's argument[1]) is a formula limiting the speedup of a task as resources are added to the system executing that task.
The law can be stated as[disputed – discuss]:
the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used.[2]
It is named after computer scientist Gene Amdahl, and was presented at the American Federation of Information Processing Societies (AFIPS) Spring Joint Computer Conference in 1967.
Amdahl's law is often used in parallel computing to predict the theoretical speedup when using multiple processors.
> AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities.
Integration, testing, deployment and production validation activities are also, depending on you setup, available for AI to work on. It depends on the type of stack that you have and how your hosting is set up but with an AI-friendly set up there's a lot of time to be saved here too.
This is largely true to only the extent that you you have a machine-verifiable measure of quality. If not, you’re putting more pressure on the humans who can actually reason and understand business goals. This cascades: tests are what make LLM code generation work but if you have an LLM write the tests you are then pushing further down the road the point where you learn that the first LLM was going in the wrong direction.
Besides that i still think its wayy to early to put AI in front of center of everything, the current progress at least makes it clear that is not going to stay as it is.
Noneetheless, if the blog article already determines a gain of 15% and you have to factor in the cost of tokens, the company should still reduce the team size by 10-20% or by 1-2 people per 5-10 person team.
Which is still a massive issues for everyone who writes code.
Btw. when i was writing code full time (not being an architect), i for sure wrote like 90% of my time code.
I'm doing an experiment though having a code review agent becoming better and better doing code reviews how i would do it. Which leads also to a skill which fixes issues before the code review agent even has to find them.
We can now automate cases which were unthinkable. We can even keep the code review quality if i leave (Its not perfect yet but its better than what we had before)
Programming has always felt like converting thought-stuff into something that the computer can understand. That's still the same, it's just a different language, and much faster.
My hot take is: if people are saying AI code is bad, yet they're using cutting-edge models like Opus 5, then those same people are writing bad code even without AI.
I'm finding that AI today can write excellent code, as long as you plan, review, and help it along with a little guidance.
Pre AI and Post AI code review hours are both 0.75 in this made up example. I find that implausible.
Even with the same amount of code, AI code is less trustworthy* and requires more attention... but we know it won't be the same amount, it will be more. This means it will take longer to review, or there will be unforeseen consequences of not spending that extra time.
*meaning no human eyes have looked at it and said "this doesn't make sense", or "this is cheating", or "this doesn't meet requirements", and won't be caught until code review if at all.
To me the biggest gotcha with AI code is that the bugs are not “normal”.
When reviewing human code I focus on specific parts because I know that there are parts where a person will just not make a bug (unless very junior).
AI on the other hand, will not do an off-by-one mistake, but it will happily just delete perfectly working code for no obvious reason. Or monkey patch a dependency because it missed a config flag. Or generally fail in a very novel and creative way.
The effort it takes to review AI code is much greater. And this is in a code base I am deeply familiar with.
Imo the future lies in a solid core programs with powerful plugin frameworks that expect all plugins to be code that was never read.
Yup. I can expect an llm to write proper code to update an hashmap or update a db, but ffs the amount of race conditions, use after free and general concurrency issues I found on colleagues PRs developed fully with these things is disgusting.
The hard part is that LLM code looks like there is some sort of flow. It is like a nice statistical smooth flow. It looks very convincing at a glance. No one would write code like that and not know what they are doing comments self assured and all.
My experience as well, it is too fond of abstractions and will constantly spin up functions like: isUserAdmin(){return user.isAdmin}
which look nice on a surface level but obfuscates real understanding of the code and the actual data structures being used. Your end result
is pretty and reads nice, but is bloated and difficult to reason with code.
LLMs are incredibly good at replicating common, coarse statistical features - which is what backs "looks very convincing at a glance".
If it's a general signal that's easy for you to recognize at a glance, it's a signal that's natural and easy for an LLM to replicate.
They're much worse at making the underlying structure work. Not incapable at all, especially not the modern LLMs. Frontier models kick ass. But it's true that an LLM denies you a lot of the classic "tell at a glance" by its very nature.
What I have noticed in my own work that a lot of the time that used to be for coding is now just waiting. I have three agents working on three different features in parallel, and I'll go back and forth with all of them, correcting things and steering etc, but then I find myself with three busy agents and nothing to myself except stare at the screen while they code away. There is a mental budget for me where I can't have more than those three running at the same time and still keep track so what I end up doing is just scrolling HN...
I stopped using coding agents after more than one and a half year of active use, it really started to become way too boring, and I’m t a point where I just hate having to babysit them and for the 200th time make it understand what the actual goal is… and to be honest, going back to writing code by hand without assistance is really hard at first you continuously have that little voice telling you how simple that would be with an agent. Then after a little bit you’re back to being productive, but I still get that voice in my mind. I’m wondering if that’s how addiction feels (way lighter of course).
That whole experience of going deep for a while into LLM coding, then trying to leave it behind made me pretty pessimistic about the future of our profession. We are creating a whole industry of people delegating their ability to work to a software stack currently controlled by basically 2 companies (that both have very sketchy financials). Doesn’t feel healthy
Models are very much predictable these days (except anthropic models). The real issue stems from letting them work on their own for far too long. Also we are not controlled by 2 companies anymore as kimi k3, deepseek flash (and soon pro) as the ultra-cheap variants, glm 5.2 especially is a direct replacement for opus 4.8.
Models will only get better and cheaper I wouldn't feel too pessimistic and wouldn't feel too bad on relying on them to accelerate work and free up mental space from menial tasks.
As a personal side-note I never let my agents do architectual design I only use them for implementing. I always found the actual coding part of programming extremely boring and coming up with designs, experimenting and testing the fun part.
I'd be really interested to see all the software that is written by agents. Whenever I touch agents or ai I can't get much use out of them. My understanding is the value when I think aloud with them/treat them as a better google search, but thats about it. Except one off web stuff, that is a pretty neat use case.
But lets be real, anything moderately complex that is out of the domain of publicly available sample code is hit or miss compared to the time invested running the loop. I'd much rather invest the time in myself.
What a lot of people don't talk about is the inherent security nightmare of trusting ai agents and the sheer data exfiltration happening behind the scenes.
It reminds me of multitabling at online poker. More tables translates into more revenue even if the ROI per table is lower as you don't dedicate as much attention, until it collapses from not being unable to do the right decisions on time and keep tabs on each player. The main difference is, with agents you might be creating (technical) debt.
This has been my observation too. Because I'm chatting it feels like I'm not working, so any output can be "productive" in that context but I'm hyper aware of all the negative time here. Correcting, pushing it back to the prompt, reminding it that it doesn't have full context so do what I told you not what you think, and then verifying it and correcting it (always) seems to take longer than just doing the work myself
You need loops so they run longer and use less of your context and brain power. Then (and this is where WFH is a super power) do stuff like walk, daydream, come up with killer ideas like a Madman episode laying on the office couch.
It’s like herding cats, if you’re doing it right. There should be enough adversarial tension in your process that the majority stays on track, but the parts where you are managing and have strong observability are the points where AI needs supervision to not go wildly off the rails, and where you can cull or redirect pathological sessions.
The two last hire we got a year ago still don't have any ownership of anything. Even the project they coded 'themselve' where we involved them in the design and let them cook almost on their own, we are the one chasing bugs and defucking everything six months later because, probably unlike them, we actually read the PR (I'm mean, they probably did read it too, but today I'm extremely pissed, I'm at the point of calling a meeting to figure it out, it cannot continue like this). I've never took more than 4 months to at least understand most of the code, I feel like a year later their level of understanding is still the same. They are basically ai overseers at this point, but while I do more code review than ever before, I feel like they learn around the same as LLM, basically nothing.
This is the new normal now that computer science based SWEs are being replaced with "LLM whisperers". Being 10 times more productive with AI necessarily means you're going to have 1/10th of the understanding of the code you're producing. It physically couldn't be any other way.
The scary thing is that the system moves in a direction such that it seems that it doesn't really matter. People on an individual level care but due to the strange economic conditions, LLM use is still rampant because experienced people can get some benefit from it in the short-term even if that means the long-term degradation of our collective expertise and thus a net negative. It's blindingly obvious but just like climate change, people can't help on an individual level to take the immediate reward.
How to get rid of every highly-skilled-but-unmedicated neuroatypical developer (could be people like Xe Iaso or Soatok):
> hiring someone who is a good coder, but has trouble reasoning about systems, has no patience for working through hard problems with others, and can’t break down vague requirements into tangible action items.
Why not hire the excellent developers for the highly-technical skills they bring, and match them with architects/product managers who are the ones who have the big picture? Am I crazy to think like this?
No. There is this persistent belief in the industry that programmers should be good at everything, not just programming itself: communication, product management, design, sysops, UX, coaching, management, testing and so on. The most visible product of this belief was the once hyper hyped role of “full stack” developer.
The really is that you could have experts in each area doing what they’re good, which means letting programmers actually program most of the time, and let business analysts figure out requirements, product owners decide features, designers decide UX and design, QA perform in-depth testing… sure , every programmer will have to manage some of this themselves to not get blocked the whole time waiting for someone to decide something, but that is NOT the same as just having programmers handle everything!
I think that if you only ever hire programmers who are also kind of people person, you definitely have to accept missing out on the antisocial but genius ones who are very likely the only ones capable of tackling the really hard problems! Unpopular view, I know, but it takes a certain type of person to achieve excellence in some areas. Just look at the most successful artists, writers, actors and especially CEOs. Programmers are clearly in that category. I’ve seen “normies” trying to write a little code. They don’t last an hour before they decide it’s bullshit that you need a semicolon precisely placed for the code to not explode, or that they can’t compile on this system until you’ve installed some tool chain that requires a bunch of commands no one knows by heart but you just need to make sure to follow exactly, otherwise hell may break lose.
If you try to take every decision making out of programming, a programmer becomes a typist. Programming contains a lot of decisions about architecture and style, even if the major decision is already done by the respective "expert". Thus, if you try to let programmers focus on programming you need to synchronize decision making done in parallel, because they will still do some of the decisions. That is a hard problem.
Since these numbers are made up, I may as well throw my personal anecdote in the ring. I find reading and reviewing far harder with coworkers who are using AI. Tickets contain about 5x as much meaningless junk as they used to, and testing notes - while far more thorough - are often now multiple pages in length. Reviews also contain much more code, people try to do more drive-by fixes because the models can generate those fixes so quickly, and people understand the code they're submitting far less clearly because the model is able to generate fixes they simply couldn't previously.
I feel less productive than I was a year ago, and I don't see my team shipping more features than they were previously. But everyone reports that they're far more productive. I don't get it.
The numbers are completely made up. Jr developer 2.5 vs 1.0 while "regular" is 1.0 and 1.0? The more senior the bigger the work. It's the same across both, worst case.
0.75 to 0.75? Rework from review is also much faster. Now you don't have to tell a peer to rework a bit here and there for obvious reasons and spend time on a new loop. The review process isn't atomic.
Our production pipeline is faster across our very large organization, after implementing AI processes.
> Tickets contain about 5x as much meaningless junk as they used to
This is a process problem. Developers should be able to answer questions about their PRs, or you reject it. It's not a daunting blanket issue.
Your process engineering is lacking. Just throwing AI at existing workflows seldom produces good results. Processes have to be reengineered to benefit from the strengths and cover for the weaknesses of AI systems, with observability at the right inflection points being fundamental to success.
"No that's not right, it should be a red bricked house. Not a brown one."
> AI redraws a red bricked house.
"No. It should have a 2 car garage, sit on top of a hill. Also it should have a front porch, and have a tree right in front."
> AI then draws a red bricked house on top a hill with a 2 car garage with a front porch and a tree right in front.
...
The issue is that people think AI should automagically create some vague idea in of theirs, without having to do the work of spelling out all the exact details. So AI (like people) must make some assumptions about what wasn't specified. Like since you didn't specify a "red bricked house" in your initial prompt, but merely a "house"... it had to come up with something as to the color, and did as you otherwise asked, but it didn't know you actually wanted a "red bricked house", since you never specified that detail. Hence why it failed to do what you wanted, and you had to "review and correct it".
Again this isn't solely an intelligence problem, but an inherent problem in language/communication, of unsaid assumptions/specifications. Of being unaware of what you don't know, unaware of your own assumptions, sometimes even being unaware of what you even want. It's why AI can't fully get rid of jobs in software.
But sometimes people just don't care. They just want a picture of a house made. Anything remotely resembling a house will do, not necessarily a solid one, or one that can withstand a magnitude 8 earthquake. You know... like something people can put up in minutes so they don't have to do hard work... such as a shabby old tent. And AI is very good at generalizing, so it can in fact achieve this. So everyone reports they are far more productive now, putting up tent after tent. Meanwhile, the people responsible for the slop have a nightmare to review...
Based on personal observation, a lot of productivity has been thrown out of the window with unneeded refactoring, rewrites and "what-if" scenarios that the AI agent will spot.
I've had similar conversations with a client recently while discussing estimates for a large project. Senior leadership has a mental model where AI makes everything X% faster, but that's very wrong. Some things get sped up by an insane amount and basically go to zero, some others not so much. Entirely new tasks emerge, such as directing agents to provide them the context they need, setting loops, etc.
I think juniors and fake seniors are a lot more productive because they were never really able to measure their productivity so spamming LoC and trusting AI output makes sense to them.
It doesn't really matter how much more productive a developer is if all other roles at the company don't follow suit. Before a developer picks up something to work on a series of roles had to set their eyes on work to be done. Project/product leads, tech leads, business people stamping and deciding on priorities. Then there's all the work that happens after a developer finishes work which tends to be manual as well. Review, QA, education, ops changes, marketing material, education articles, webcasts, showcasing features to end users and lets not forget end users actually making good use of the amazing new features shipped and likely many more largely sequential processes depending on company size and product/project type.
There's no real way to get to a 10x developer nowadays. Even if a company somehow achieved the magic productivity increase in all employees you still need a 10x consumer to gulp it all down.
The exception here is probably in very small companies. I'm curious to see if LLMs can usher in a new golden age of the one-programmer-one-designer-one-sales indie teams that typified so much of the 80s and 90s...
If they can one shot that, so can you, and you can custom tailor that tool to your needs not wait for them to add features they think might fit their collective customer base’s needs.
Empirical evidence through observation or self-reporting, sampling in some meaningful way, would obviously be preferable but is also often just not practical.
Guessing at numbers to check whether your thesis even works with some plausible assumptions is a meaningful first step and to my mind a good way to reason through something like this and make it discussable.
A possible outcome of such an exercise is also that for your thesis to work out you need to make wildly implausible assumptions, so that helps you to discard that thesis.
From my perspective this is a very useful way to approach a hypothesis where empirical evidence is scarce or at least hard to get. No reason to dismiss it immediately – especially since the fact that those are guesses was never hidden.
Writing code is cheap. Coming up with a plan to stay updated on specs and verification are not so cheap, and you need more attention there than ever, because an LLM will take your half-assed spec and claim victory as it prints linted code that compiles and passes a few token unit tests while being under (500 or 1000) LoC.
That's PoC-level, happy-path-only engineering and LLMs are very dangerous at inserting subtle hardcoded values and cheats along the way, which makes it really hard to spot them later on. You need a system to whack them before they infect your codebase terminally, be it hyper vigilance, more SCA, more TDD, SDD... Otherwise you'll wake up one day with a production incident at 3 am and wonder how that code was even allowed in the release bundle.
Could you speak to the source of the pre-ai / post-ai differences? I'm specifically curious about how you decided the values that were changed (1.5h pre -> 0.5 h post)? Is that an illustrative conceptual thing, or is there data backing that? Not trying to litigate your article, good read. Just curious about the grounding for the specific values that changed pre/post.
Its too early to measure. Agentic coding harness'es arent mature yet. People try different approaches (with sub-agents, or without etc). Productivity will likely increase in near future even if new LLMs will hit the ceiling.
I’d suggest a slightly different workflow depending on experience level.
Beginners should follow the practice described in the article: have the LLM propose code, then type it manually. This forces you to examine each step, question unfamiliar decisions, and build a stronger mental model of the codebase.
Experienced developers who already understand the underlying concepts may find autocomplete more practical when writing from scratch. It preserves control over structure, comments, and coding style while preventing tools such as Opus or Fable 5 (Both of these models loves adding tons of comment in your codebase) from generating bloated code, excessive comments, or patterns that do not match the existing codebase.
> There’s no doubt that AI has already improved the productivity of engineering teams
Thought it might be an interesting read, however have up just after reading the first line.
For the context, code had always been a copy-paste exercise, big part of it was understanding and differentiating between the different choices. Along with it people were growing as engineering practitioner's too. Human learning still needs to happen if they are expected to fix the code when LLM gives up.
LLMs are quite useful tool in themselves, however the hype has unfortunately polarized the population.
Based on personal experience on a specific project, that 1.5 hours with AI let me accomplish work planned for a man-week in the pre-AI era. So it’s much more than 3x.
Familiarity with what's already existing affects how much AI helps as a research tool.
A new developer to the team can research quickly using AI, while by contrast, experienced folks won't gain much vs. just using their current knowledge.
It shows up as a new team member coming up to speed impressively fast. But since it doesn't help the rest of the team it also doesn't contribute much to overall team productivity.
I don’t think human review is worth it for LLM generated code. We design abstractions and all around how humans think. LLMs writes code that is better understood by machines. If you are all in on LLMs, by all means, read the code figure out what it means. But trying to enforce a human flow to its logic is flawed and will be overwritten the next time.
LLMs definitely write worse code for LLM consumption than humans can. In my experience your claim can't be further from the truth. I can get much further with an LLM starting from a great codebase than I can starting from a vibed codebase.
And I can do even better than that if I design the codebase specifically with LLM coding in mind, making choices that make it hard or impossible for the LLM to make certain categories of error it tends to make, and make it easier for the LLM to observe the results.
Human review is even more important for LLM-generated code, because LLMs are so much worse at writing code than humans are. You cannot under any circumstances just let them rip or your results will suck.
But LLM's will trash your established architecture and patterns if you let it run free over an established codebase for any length of time. In our experience anyways, even with careful guidance and rules to follow. It nearly always does something a bit odd.
And it's test cases can sometimes leave a lot to be desired.
The role of developer is becoming more of a system thinker than a syntax writer, previously load balance was about what to do in a given timeline, now its more of what not to do , doing more is actually increasing technical debt.
The outwardly measurable productivity increase will come but over a time scale of years, and most of that will be in barely measurable increments. Nobody wants to hear that but it's just how the world works.
Then consider on top that the perceived time needed for implementation has dropped so additional work that would have never been taken up in the past gets added.
With AI doing all the work there is more time for meetings. Product folks aren't going to tell AI to make the code, they are going to still have a meeting to yell at someone that their AI generated requirements weren't followed the way they wanted. You'll also need meetings to discuss how more AI can prevent the AI from taking down production so much.
If a senior developper spends the same amount of time debugging, code reviewing, setting up CI/CD, documenting and doing admin work, he has not been using AI right.
> Sometimes I actually find AI makes non-coding work go slower…For now, let’s assume AI only helps.
Haha fuck you dude no I’m not going to assume it only helps when your preceding paragraph gives a concrete example of HOW IT MAKES WORK LESS EFFICIENT.
In turn, I’m not “assuming” this guy is delusional and “grasping at straws” I’m deducing it from his poorly constructed, self-defeating, fictional argument in favor of his assertion.
"In reality, it’s juniors who stand to gain the most from AI – especially if they are good at using AI as a learning tool, not just an overeager sidekick who’s willing to do the menial work."
We have had interns come in and do 5x more work than their predecessors using GenAI. Senior devs spend most of their time planning and reviewing now and Junior devs can implement. Both with the help of GenAI.
Writing code is a small part of everyday's job of a software engineer. The article's table reflects this fairly well.
AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities. If code generation speeds up by 5x while those bottlenecks don't, you've mostly increased the team's work queue rather than its throughput.
With the current capabilities, models still need constant babysitting and course correction. An engineer who lacks the skills to guide them can end up creating more work for the rest of the team. AI makes it easy to generate code faster than you can understand it, and that cost is paid during code review, debugging, and maintenance by colleagues, whose confidence in that engineer's skills may be affected by his use of AI.
What looks like a productivity gain for one engineer can become a productivity loss for the team as a whole.
> you've mostly increased the team's work queue rather than its throughput
Amdahl’s law remains unbeaten
https://en.wikipedia.org/wiki/Amdahl's_law
For anyone who hadn't heard this before, like me. <3
In computer architecture, Amdahl's law (or Amdahl's argument[1]) is a formula limiting the speedup of a task as resources are added to the system executing that task.
The law can be stated as[disputed – discuss]:
It is named after computer scientist Gene Amdahl, and was presented at the American Federation of Information Processing Societies (AFIPS) Spring Joint Computer Conference in 1967.Amdahl's law is often used in parallel computing to predict the theoretical speedup when using multiple processors.
Of course you can beat it (in this context). You can cheat (by shifting the work around).
Started to write up a comment, got a bit wordy, turned into a blog post: https://senkorasic.com/articles/ai-amdahls-law
> AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities.
Integration, testing, deployment and production validation activities are also, depending on you setup, available for AI to work on. It depends on the type of stack that you have and how your hosting is set up but with an AI-friendly set up there's a lot of time to be saved here too.
This is largely true to only the extent that you you have a machine-verifiable measure of quality. If not, you’re putting more pressure on the humans who can actually reason and understand business goals. This cascades: tests are what make LLM code generation work but if you have an LLM write the tests you are then pushing further down the road the point where you learn that the first LLM was going in the wrong direction.
GP: > With the current capabilities, models still need constant babysitting and course correction.
You'd be opening yourself up to even more babysitting. Would that really save time, or improve quality? I'm not convinced, to put it mildly.
Besides that i still think its wayy to early to put AI in front of center of everything, the current progress at least makes it clear that is not going to stay as it is.
Noneetheless, if the blog article already determines a gain of 15% and you have to factor in the cost of tokens, the company should still reduce the team size by 10-20% or by 1-2 people per 5-10 person team.
Which is still a massive issues for everyone who writes code.
Btw. when i was writing code full time (not being an architect), i for sure wrote like 90% of my time code.
I'm doing an experiment though having a code review agent becoming better and better doing code reviews how i would do it. Which leads also to a skill which fixes issues before the code review agent even has to find them.
We can now automate cases which were unthinkable. We can even keep the code review quality if i leave (Its not perfect yet but its better than what we had before)
Good summary. Theory of constraints in action.
Very well said.
Programming has always felt like converting thought-stuff into something that the computer can understand. That's still the same, it's just a different language, and much faster.
My hot take is: if people are saying AI code is bad, yet they're using cutting-edge models like Opus 5, then those same people are writing bad code even without AI.
I'm finding that AI today can write excellent code, as long as you plan, review, and help it along with a little guidance.
more and more of the thought stuff is being done by AI, let's not kid ourselves.
Perfect summary of what's going on today
[flagged]
Pre AI and Post AI code review hours are both 0.75 in this made up example. I find that implausible.
Even with the same amount of code, AI code is less trustworthy* and requires more attention... but we know it won't be the same amount, it will be more. This means it will take longer to review, or there will be unforeseen consequences of not spending that extra time.
*meaning no human eyes have looked at it and said "this doesn't make sense", or "this is cheating", or "this doesn't meet requirements", and won't be caught until code review if at all.
To me the biggest gotcha with AI code is that the bugs are not “normal”.
When reviewing human code I focus on specific parts because I know that there are parts where a person will just not make a bug (unless very junior).
AI on the other hand, will not do an off-by-one mistake, but it will happily just delete perfectly working code for no obvious reason. Or monkey patch a dependency because it missed a config flag. Or generally fail in a very novel and creative way.
The effort it takes to review AI code is much greater. And this is in a code base I am deeply familiar with.
Imo the future lies in a solid core programs with powerful plugin frameworks that expect all plugins to be code that was never read.
> Imo the future lies in a solid core programs with powerful plugin frameworks that expect all plugins to be code that was never read.
What makes you think that?
Yup. I can expect an llm to write proper code to update an hashmap or update a db, but ffs the amount of race conditions, use after free and general concurrency issues I found on colleagues PRs developed fully with these things is disgusting.
The hard part is that LLM code looks like there is some sort of flow. It is like a nice statistical smooth flow. It looks very convincing at a glance. No one would write code like that and not know what they are doing comments self assured and all.
My experience as well, it is too fond of abstractions and will constantly spin up functions like: isUserAdmin(){return user.isAdmin}
which look nice on a surface level but obfuscates real understanding of the code and the actual data structures being used. Your end result is pretty and reads nice, but is bloated and difficult to reason with code.
LLMs are incredibly good at replicating common, coarse statistical features - which is what backs "looks very convincing at a glance".
If it's a general signal that's easy for you to recognize at a glance, it's a signal that's natural and easy for an LLM to replicate.
They're much worse at making the underlying structure work. Not incapable at all, especially not the modern LLMs. Frontier models kick ass. But it's true that an LLM denies you a lot of the classic "tell at a glance" by its very nature.
at big tech the numbers seem about right. at smaller firms - you've less admin, less meetings - so the coding part is higher.
mind you most of the stuff posted here is in regards to big tech - even though it's 'hacker' news.
[dead]
What I have noticed in my own work that a lot of the time that used to be for coding is now just waiting. I have three agents working on three different features in parallel, and I'll go back and forth with all of them, correcting things and steering etc, but then I find myself with three busy agents and nothing to myself except stare at the screen while they code away. There is a mental budget for me where I can't have more than those three running at the same time and still keep track so what I end up doing is just scrolling HN...
I stopped using coding agents after more than one and a half year of active use, it really started to become way too boring, and I’m t a point where I just hate having to babysit them and for the 200th time make it understand what the actual goal is… and to be honest, going back to writing code by hand without assistance is really hard at first you continuously have that little voice telling you how simple that would be with an agent. Then after a little bit you’re back to being productive, but I still get that voice in my mind. I’m wondering if that’s how addiction feels (way lighter of course).
That whole experience of going deep for a while into LLM coding, then trying to leave it behind made me pretty pessimistic about the future of our profession. We are creating a whole industry of people delegating their ability to work to a software stack currently controlled by basically 2 companies (that both have very sketchy financials). Doesn’t feel healthy
Neither of these points feel true anymore.
Models are very much predictable these days (except anthropic models). The real issue stems from letting them work on their own for far too long. Also we are not controlled by 2 companies anymore as kimi k3, deepseek flash (and soon pro) as the ultra-cheap variants, glm 5.2 especially is a direct replacement for opus 4.8.
Models will only get better and cheaper I wouldn't feel too pessimistic and wouldn't feel too bad on relying on them to accelerate work and free up mental space from menial tasks.
As a personal side-note I never let my agents do architectual design I only use them for implementing. I always found the actual coding part of programming extremely boring and coming up with designs, experimenting and testing the fun part.
I'd be really interested to see all the software that is written by agents. Whenever I touch agents or ai I can't get much use out of them. My understanding is the value when I think aloud with them/treat them as a better google search, but thats about it. Except one off web stuff, that is a pretty neat use case.
But lets be real, anything moderately complex that is out of the domain of publicly available sample code is hit or miss compared to the time invested running the loop. I'd much rather invest the time in myself.
What a lot of people don't talk about is the inherent security nightmare of trusting ai agents and the sheer data exfiltration happening behind the scenes.
It reminds me of multitabling at online poker. More tables translates into more revenue even if the ROI per table is lower as you don't dedicate as much attention, until it collapses from not being unable to do the right decisions on time and keep tabs on each player. The main difference is, with agents you might be creating (technical) debt.
This has been my observation too. Because I'm chatting it feels like I'm not working, so any output can be "productive" in that context but I'm hyper aware of all the negative time here. Correcting, pushing it back to the prompt, reminding it that it doesn't have full context so do what I told you not what you think, and then verifying it and correcting it (always) seems to take longer than just doing the work myself
You should spend time as much as 50% on harness engineering for you and team to stop that and make the AI steer better.
You need loops so they run longer and use less of your context and brain power. Then (and this is where WFH is a super power) do stuff like walk, daydream, come up with killer ideas like a Madman episode laying on the office couch.
My step count is crazy these last few months, I'm loving it!
Which is why, when I can get away with it, I only use AI for improved code completion, or generating the initial boilerplate.
I find myself in the same situation, baby sitting AI agent, monitoring them. It's like l've become a coordinator.
It’s like herding cats, if you’re doing it right. There should be enough adversarial tension in your process that the majority stays on track, but the parts where you are managing and have strong observability are the points where AI needs supervision to not go wildly off the rails, and where you can cull or redirect pathological sessions.
The two last hire we got a year ago still don't have any ownership of anything. Even the project they coded 'themselve' where we involved them in the design and let them cook almost on their own, we are the one chasing bugs and defucking everything six months later because, probably unlike them, we actually read the PR (I'm mean, they probably did read it too, but today I'm extremely pissed, I'm at the point of calling a meeting to figure it out, it cannot continue like this). I've never took more than 4 months to at least understand most of the code, I feel like a year later their level of understanding is still the same. They are basically ai overseers at this point, but while I do more code review than ever before, I feel like they learn around the same as LLM, basically nothing.
This is the new normal now that computer science based SWEs are being replaced with "LLM whisperers". Being 10 times more productive with AI necessarily means you're going to have 1/10th of the understanding of the code you're producing. It physically couldn't be any other way.
The scary thing is that the system moves in a direction such that it seems that it doesn't really matter. People on an individual level care but due to the strange economic conditions, LLM use is still rampant because experienced people can get some benefit from it in the short-term even if that means the long-term degradation of our collective expertise and thus a net negative. It's blindingly obvious but just like climate change, people can't help on an individual level to take the immediate reward.
How to get rid of every highly-skilled-but-unmedicated neuroatypical developer (could be people like Xe Iaso or Soatok):
> hiring someone who is a good coder, but has trouble reasoning about systems, has no patience for working through hard problems with others, and can’t break down vague requirements into tangible action items.
Why not hire the excellent developers for the highly-technical skills they bring, and match them with architects/product managers who are the ones who have the big picture? Am I crazy to think like this?
No. There is this persistent belief in the industry that programmers should be good at everything, not just programming itself: communication, product management, design, sysops, UX, coaching, management, testing and so on. The most visible product of this belief was the once hyper hyped role of “full stack” developer.
The really is that you could have experts in each area doing what they’re good, which means letting programmers actually program most of the time, and let business analysts figure out requirements, product owners decide features, designers decide UX and design, QA perform in-depth testing… sure , every programmer will have to manage some of this themselves to not get blocked the whole time waiting for someone to decide something, but that is NOT the same as just having programmers handle everything!
I think that if you only ever hire programmers who are also kind of people person, you definitely have to accept missing out on the antisocial but genius ones who are very likely the only ones capable of tackling the really hard problems! Unpopular view, I know, but it takes a certain type of person to achieve excellence in some areas. Just look at the most successful artists, writers, actors and especially CEOs. Programmers are clearly in that category. I’ve seen “normies” trying to write a little code. They don’t last an hour before they decide it’s bullshit that you need a semicolon precisely placed for the code to not explode, or that they can’t compile on this system until you’ve installed some tool chain that requires a bunch of commands no one knows by heart but you just need to make sure to follow exactly, otherwise hell may break lose.
If you try to take every decision making out of programming, a programmer becomes a typist. Programming contains a lot of decisions about architecture and style, even if the major decision is already done by the respective "expert". Thus, if you try to let programmers focus on programming you need to synchronize decision making done in parallel, because they will still do some of the decisions. That is a hard problem.
> no patience for working through hard problems with others, and can’t break down vague requirements into tangible action items.
These are very convenient and vague enough excuses to single out whoever honestly says your architecture is stupid.
You're looking at the forest, OP is looking at the trees.
> There’s no doubt that AI has already improved the productivity of engineering teams, and will only get better in the coming years.
They lost me by begging the question in the very first sentence.
> Reading and Debugging 1.5 1.0 > Code Reviews 0.75 0.75
Since these numbers are made up, I may as well throw my personal anecdote in the ring. I find reading and reviewing far harder with coworkers who are using AI. Tickets contain about 5x as much meaningless junk as they used to, and testing notes - while far more thorough - are often now multiple pages in length. Reviews also contain much more code, people try to do more drive-by fixes because the models can generate those fixes so quickly, and people understand the code they're submitting far less clearly because the model is able to generate fixes they simply couldn't previously.
I feel less productive than I was a year ago, and I don't see my team shipping more features than they were previously. But everyone reports that they're far more productive. I don't get it.
The numbers are completely made up. Jr developer 2.5 vs 1.0 while "regular" is 1.0 and 1.0? The more senior the bigger the work. It's the same across both, worst case.
0.75 to 0.75? Rework from review is also much faster. Now you don't have to tell a peer to rework a bit here and there for obvious reasons and spend time on a new loop. The review process isn't atomic.
Our production pipeline is faster across our very large organization, after implementing AI processes.
> Tickets contain about 5x as much meaningless junk as they used to
This is a process problem. Developers should be able to answer questions about their PRs, or you reject it. It's not a daunting blanket issue.
Your process engineering is lacking. Just throwing AI at existing workflows seldom produces good results. Processes have to be reengineered to benefit from the strengths and cover for the weaknesses of AI systems, with observability at the right inflection points being fundamental to success.
Care to give an example?
You don't get it? It's like this:
"Make me a picture of a house".
> AI proceeds to draw a house.
"No that's not right, it should be a red bricked house. Not a brown one."
> AI redraws a red bricked house.
"No. It should have a 2 car garage, sit on top of a hill. Also it should have a front porch, and have a tree right in front."
> AI then draws a red bricked house on top a hill with a 2 car garage with a front porch and a tree right in front.
...
The issue is that people think AI should automagically create some vague idea in of theirs, without having to do the work of spelling out all the exact details. So AI (like people) must make some assumptions about what wasn't specified. Like since you didn't specify a "red bricked house" in your initial prompt, but merely a "house"... it had to come up with something as to the color, and did as you otherwise asked, but it didn't know you actually wanted a "red bricked house", since you never specified that detail. Hence why it failed to do what you wanted, and you had to "review and correct it".
Again this isn't solely an intelligence problem, but an inherent problem in language/communication, of unsaid assumptions/specifications. Of being unaware of what you don't know, unaware of your own assumptions, sometimes even being unaware of what you even want. It's why AI can't fully get rid of jobs in software.
But sometimes people just don't care. They just want a picture of a house made. Anything remotely resembling a house will do, not necessarily a solid one, or one that can withstand a magnitude 8 earthquake. You know... like something people can put up in minutes so they don't have to do hard work... such as a shabby old tent. And AI is very good at generalizing, so it can in fact achieve this. So everyone reports they are far more productive now, putting up tent after tent. Meanwhile, the people responsible for the slop have a nightmare to review...
Based on personal observation, a lot of productivity has been thrown out of the window with unneeded refactoring, rewrites and "what-if" scenarios that the AI agent will spot.
"... unneeded refactoring, rewrites and "what-if" scenarios ..."
Like so many senior developers I have encountered. That stuff is good for CV.
It's on a completely different level now.
I've had similar conversations with a client recently while discussing estimates for a large project. Senior leadership has a mental model where AI makes everything X% faster, but that's very wrong. Some things get sped up by an insane amount and basically go to zero, some others not so much. Entirely new tasks emerge, such as directing agents to provide them the context they need, setting loops, etc.
It's a very O-ring problem.
"We can disagree about the specific numbers here, but if you think this is wildly off, you’ve probably never been a senior developer"
I'd even say the productivity gap is even smaller, if not negative in some areas...
I think juniors and fake seniors are a lot more productive because they were never really able to measure their productivity so spamming LoC and trusting AI output makes sense to them.
It doesn't really matter how much more productive a developer is if all other roles at the company don't follow suit. Before a developer picks up something to work on a series of roles had to set their eyes on work to be done. Project/product leads, tech leads, business people stamping and deciding on priorities. Then there's all the work that happens after a developer finishes work which tends to be manual as well. Review, QA, education, ops changes, marketing material, education articles, webcasts, showcasing features to end users and lets not forget end users actually making good use of the amazing new features shipped and likely many more largely sequential processes depending on company size and product/project type.
There's no real way to get to a 10x developer nowadays. Even if a company somehow achieved the magic productivity increase in all employees you still need a 10x consumer to gulp it all down.
The exception here is probably in very small companies. I'm curious to see if LLMs can usher in a new golden age of the one-programmer-one-designer-one-sales indie teams that typified so much of the 80s and 90s...
If they can one shot that, so can you, and you can custom tailor that tool to your needs not wait for them to add features they think might fit their collective customer base’s needs.
It's like you just made up those numbers and then developed your thesis around that.
That’s a wildly uncharitable read.
Empirical evidence through observation or self-reporting, sampling in some meaningful way, would obviously be preferable but is also often just not practical.
Guessing at numbers to check whether your thesis even works with some plausible assumptions is a meaningful first step and to my mind a good way to reason through something like this and make it discussable.
A possible outcome of such an exercise is also that for your thesis to work out you need to make wildly implausible assumptions, so that helps you to discard that thesis.
From my perspective this is a very useful way to approach a hypothesis where empirical evidence is scarce or at least hard to get. No reason to dismiss it immediately – especially since the fact that those are guesses was never hidden.
That’s exactly what was done.
Writing code is cheap. Coming up with a plan to stay updated on specs and verification are not so cheap, and you need more attention there than ever, because an LLM will take your half-assed spec and claim victory as it prints linted code that compiles and passes a few token unit tests while being under (500 or 1000) LoC.
That's PoC-level, happy-path-only engineering and LLMs are very dangerous at inserting subtle hardcoded values and cheats along the way, which makes it really hard to spot them later on. You need a system to whack them before they infect your codebase terminally, be it hyper vigilance, more SCA, more TDD, SDD... Otherwise you'll wake up one day with a production incident at 3 am and wonder how that code was even allowed in the release bundle.
[flagged]
Could you speak to the source of the pre-ai / post-ai differences? I'm specifically curious about how you decided the values that were changed (1.5h pre -> 0.5 h post)? Is that an illustrative conceptual thing, or is there data backing that? Not trying to litigate your article, good read. Just curious about the grounding for the specific values that changed pre/post.
Its too early to measure. Agentic coding harness'es arent mature yet. People try different approaches (with sub-agents, or without etc). Productivity will likely increase in near future even if new LLMs will hit the ceiling.
law of diminishing returns son
I’d suggest a slightly different workflow depending on experience level.
Beginners should follow the practice described in the article: have the LLM propose code, then type it manually. This forces you to examine each step, question unfamiliar decisions, and build a stronger mental model of the codebase.
Experienced developers who already understand the underlying concepts may find autocomplete more practical when writing from scratch. It preserves control over structure, comments, and coding style while preventing tools such as Opus or Fable 5 (Both of these models loves adding tons of comment in your codebase) from generating bloated code, excessive comments, or patterns that do not match the existing codebase.
AI is a force multiplier.
It multiplies both good and bad decisions. Both mine and it's 'own'.
I can get some things done 10x faster and it might even catch mistakes or help me solve something difficult.
But if I am being lazy or complacent then it bites me that much harder.
Exactly this.
> There’s no doubt that AI has already improved the productivity of engineering teams
Thought it might be an interesting read, however have up just after reading the first line.
For the context, code had always been a copy-paste exercise, big part of it was understanding and differentiating between the different choices. Along with it people were growing as engineering practitioner's too. Human learning still needs to happen if they are expected to fix the code when LLM gives up.
LLMs are quite useful tool in themselves, however the hype has unfortunately polarized the population.
Based on personal experience on a specific project, that 1.5 hours with AI let me accomplish work planned for a man-week in the pre-AI era. So it’s much more than 3x.
One extra consideration that is material.
Familiarity with what's already existing affects how much AI helps as a research tool.
A new developer to the team can research quickly using AI, while by contrast, experienced folks won't gain much vs. just using their current knowledge.
It shows up as a new team member coming up to speed impressively fast. But since it doesn't help the rest of the team it also doesn't contribute much to overall team productivity.
why do i have to watch a mermaid repeatedly move up and down and kiss your likeness ad infinitum while i read this post
I don’t think human review is worth it for LLM generated code. We design abstractions and all around how humans think. LLMs writes code that is better understood by machines. If you are all in on LLMs, by all means, read the code figure out what it means. But trying to enforce a human flow to its logic is flawed and will be overwritten the next time.
LLMs definitely write worse code for LLM consumption than humans can. In my experience your claim can't be further from the truth. I can get much further with an LLM starting from a great codebase than I can starting from a vibed codebase.
And I can do even better than that if I design the codebase specifically with LLM coding in mind, making choices that make it hard or impossible for the LLM to make certain categories of error it tends to make, and make it easier for the LLM to observe the results.
Human review is even more important for LLM-generated code, because LLMs are so much worse at writing code than humans are. You cannot under any circumstances just let them rip or your results will suck.
But LLM's will trash your established architecture and patterns if you let it run free over an established codebase for any length of time. In our experience anyways, even with careful guidance and rules to follow. It nearly always does something a bit odd.
And it's test cases can sometimes leave a lot to be desired.
The role of developer is becoming more of a system thinker than a syntax writer, previously load balance was about what to do in a given timeline, now its more of what not to do , doing more is actually increasing technical debt.
The outwardly measurable productivity increase will come but over a time scale of years, and most of that will be in barely measurable increments. Nobody wants to hear that but it's just how the world works.
"Integrations & AI Agents to ship financial products in days, not months."
https://www.rutter.com/
AI salesperson claims that AI works in principle.
Then consider on top that the perceived time needed for implementation has dropped so additional work that would have never been taken up in the past gets added.
Soon nobody will write code by hand , nobody will read it, and nobody will do code reviews. Architecture too will be done by AI.
the one whats unclear to me is, will there still be meetings.
With AI doing all the work there is more time for meetings. Product folks aren't going to tell AI to make the code, they are going to still have a meeting to yell at someone that their AI generated requirements weren't followed the way they wanted. You'll also need meetings to discuss how more AI can prevent the AI from taking down production so much.
AI non believer rolls out old tropes, concludes AI not really much of a thing, probably mass hallucinated.
I'd say for reference "senior developer" the main problem is spending full 1.5 hours on meetings each day
I don't know if I buy the "Pre AI (hours)" and "Post AI (hours)"
I'm going to copy/paste a comment of mine from another article the other week, since this discussion seems quite relevant to the topic at hand.
https://news.ycombinator.com/item?id=48743713
If a senior developper spends the same amount of time debugging, code reviewing, setting up CI/CD, documenting and doing admin work, he has not been using AI right.
This assumes you are arranging deckchairs and not leaving the cruise ship for say, a boeing 747.
One example, let's say there is a side bet that makes everyone 10x more productive with a success rate of 1%
It takes 2 hrs to make the bet wit agent orchestration.
10 people can get this done in their spare time freed up by AI in 5 weeks.
Bet cashes in and you are much faster at everything.
It won't feel faster. Because the brain probably scores emotionally in roadblocks cleared per hour.
Back when you got a single punch card loaded in a day it felt like a fucking win.
The other factor is you get paid the same and there is more disruption and competition and job insecurity.
But objectively value gets shipped faster using AI.
Just not much if you go the faster horses route with AI. You need the cars. (Or planes!)
Thinking logically about that system seems to be the most important thing.
> Sometimes I actually find AI makes non-coding work go slower…For now, let’s assume AI only helps.
Haha fuck you dude no I’m not going to assume it only helps when your preceding paragraph gives a concrete example of HOW IT MAKES WORK LESS EFFICIENT.
In turn, I’m not “assuming” this guy is delusional and “grasping at straws” I’m deducing it from his poorly constructed, self-defeating, fictional argument in favor of his assertion.
[dead]
[flagged]
[flagged]
"In reality, it’s juniors who stand to gain the most from AI – especially if they are good at using AI as a learning tool, not just an overeager sidekick who’s willing to do the menial work."
We have had interns come in and do 5x more work than their predecessors using GenAI. Senior devs spend most of their time planning and reviewing now and Junior devs can implement. Both with the help of GenAI.
[dead]
[dead]