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.
well, that is a problem with automation in general i think; if you go too far instead of a simple process a complicated processes get encoded in the automation and if it hits an edge case or breaks for whatever reason the babysitting kills productivity (this is just my experience anyways)
also, as far as quality goes, once something is automated that potential breakage puts a cap on how much improvement/quality you can achieve later... i'd guess llms are a bit more malleable there, but idk, i still see this issue even with skills and such...
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.
I think this is a good practice anyway. Putting as much code as possible into silos with guarded permissions.
Historically plugins have been kind of crappy because they were constantly breaking with updates. However if they only live as a spec, and are regenerated when needed they can easily survive API changes.
Bonus feature is that if all “installed” plugins are generated together, the llm can also find ways to avoid them being buggy due to weird interactions.
All this while keeping the main program from crashing.
Security wise the spec can also be inspected using a trusted LLM. It is trivial to hide exfiltration or malicious code in plugin/extension code (e.g.: honey). But it is much harder to hide it in a spec.
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.
Even if I was paid for using LLMs I would still find the experience nightmarish. I really don’t want to be dependent on such a system and spend my time managing fleets
I always found that if you are good enough at whittling down boilerplate that coding becomes something akin to pure architecture.
I find that mediocre programmers and LLMs are bad at both. They're helpful if you want to shit out some repetitive boilerplate or perform a complex search of some kind but otherwise you're better off without.
bug fixes not so much. when I encounter a bug the first thing I do is ask an LLM and not only do they usually fail to get the correct solution, they often slap virtual duct tape on it which makes other bugs more likely.
feels like a harness issue, bug fixes work out fine with omp.sh as long as it can be tested properly. Untestable things tend to lead to hallucinated results though.
Compare the performance of a 980 and a 5050 and I am sure that will answer your question.
Also models baked into the silicon are able to achieve efficiency that is simply impossible to achieve with programmable circuits, there is a general slowdown in the raw capabilities that transformers can achieve and agentic tool use is simply an amplifier that will reach a wall eventually. It wouldn't surprise me if we saw within 5 to 10 years accelerator cards that you're able to purchase and plug into via usb-c that are able to achieve thousands of tok/s as well as api costs going down to what we already see with subscriptions today.
There has been quite a lot of off-ramping going on where people feel satisfied with the performance they're getting out of the models and simply staying there instead of using SOTA.
> accelerator cards that you're able to purchase and plug into via usb-c that are able to achieve thousands of tok/s
how do you update that baked-in model for things that have happened in the last say 2 months?
if i'm a programmer for example, even being a couple months old is a huge annoyance because programming languages and frameworks are changing all the time...
When was the last time you heard about someone talking about "Knowledge Cutoff" dates? OpenAI used to make a huge deal about it every release, now its not even mentioned.
We give agents tools, the ability to read a man page, the ability to use web search. Knowledge cut-off is far less important than it used to be.
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.
For what it’s worth, I’ve made really good, state of the art software in my areas of interest using LLMs. So I do believe you can produce really good software using them. But it’s domains where I have decade of experience.
But even with that result I don’t think it’s something we should bet the whole industry on, and something I personally don’t feel comfortable relying upon
Idk, ymmv. I’ve had very good outcomes writing embedded firmware for complex systems, drivers, etc. it’s really, really good at not bodging the kinds of things that always catch meaty developers unawares.
OTOH, we run extensive harness optimization, where everything is specified in advance, then a plan is made, then a naive review of the plan vs the specification vs the blast radius, then implementation, tests, then a naive review of test coverage, a naive review of the code vis a vis our code guidelines, a review for smells, a review for silo violation and architecture compliance, a reconciliation of the documentation, then planning the next subfeature, etc. probably 10 percent code generation, 40 percent documentation and planning and adversarial review, 50 percent automated adversarial code review.
We use a Claude for planning and generation, sol for adversarial review. Our metrics say we are about 2x. Productive, at a cost of about $300 per dev per month.
We are also shipping less bugs and better, more clearly written documentation (we use technical writing English style guides implemented by Claude)
I think a big part is the constant adversarial review by a different model with no prior context except the coding standards. Also important is context management, we do an onboarding and wrap-up for each session where we have a batch of continuity documents- Learnings, musings, and roadtrips where we let the most successful high-context sessions research and then write about something that they “ became curious about” during the session. That actually brings in a lot of insight to the team and occasionally is brilliant.
Also critical is crossing compaction barriers (standard re-onboarding protocols, writing transition documents prior to compaction, etc)
Also critical is being able to smell when a session is going off the rails. What we do there is sideline the session, wait for master to advance a bit, then have it do a “4c’s” review of the committed work, blast radius analysis, and remediation. If there’s still useful context left we put it into a project unrelated to its failure context. That salvages the valuable session context without staying in the failure trench.
We built all the tooling as Claude-code tools (mostly in python) and the rest is just documentation for preloading the context and as reference material to pull in by policy before certain tasks. Really, there is nothing complicated or heavy, it’s all process.
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
I find this is the difference between people that 2-4x their productivity and improve their shipping quality vs those that don’t find AI very useful. It’s all about the process, the adversarial tension, and the documentation driving the process. The good code squeezes out of that pressure like juice being pressed from fruit.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
We run extensive harness optimization, where everything is specified in advance, then a plan is made, then a naive review of the plan vs the specification vs the blast radius, then implementation, tests, then a naive review of test coverage, a naive review of the code vis a vis our code guidelines, a review for smells, a review for silo violation and architecture compliance, a reconciliation of the documentation, then planning the next subfeature, etc. probably 10 percent code generation, 40 percent documentation and planning and adversarial review, 50 percent automated adversarial code review.
We use a Claude for planning and generation, sol for adversarial review. Our metrics say we are about 2x. Productive, at a cost of about $300 per dev per month.
We are also shipping less bugs and better, more clearly written documentation (we use technical writing English style guides implemented by Claude)
I think a big part is the constant adversarial review by a different model with no prior context except the coding standards. Also important is context management, we do an onboarding and wrap-up for each session where we have a batch of continuity documents- Learnings, musings, and roadtrips where we let the most successful high-context sessions research and then write about something that they “ became curious about” during the session. That actually brings in a lot of insight to the team and occasionally is brilliant.
Also critical is crossing compaction barriers (standard re-onboarding protocols, writing transition documents prior to compaction, etc)
Also critical is being able to smell when a session is going off the rails. What we do there is sideline the session, wait for master to advance a bit, then have it do a “4c’s” review of the committed work, blast radius analysis, and remediation. If there’s still useful context left we put it into a project unrelated to its failure context. That salvages the valuable session context without staying in the failure trench.
"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...
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.
"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.
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.
> 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.
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.
well, that is a problem with automation in general i think; if you go too far instead of a simple process a complicated processes get encoded in the automation and if it hits an edge case or breaks for whatever reason the babysitting kills productivity (this is just my experience anyways)
also, as far as quality goes, once something is automated that potential breakage puts a cap on how much improvement/quality you can achieve later... i'd guess llms are a bit more malleable there, but idk, i still see this issue even with skills and such...
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
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?
I think this is a good practice anyway. Putting as much code as possible into silos with guarded permissions.
Historically plugins have been kind of crappy because they were constantly breaking with updates. However if they only live as a spec, and are regenerated when needed they can easily survive API changes.
Bonus feature is that if all “installed” plugins are generated together, the llm can also find ways to avoid them being buggy due to weird interactions.
All this while keeping the main program from crashing.
Security wise the spec can also be inspected using a trusted LLM. It is trivial to hide exfiltration or malicious code in plugin/extension code (e.g.: honey). But it is much harder to hide it in a spec.
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.
> My experience as well, it is too fond of abstractions and will constantly spin up functions like: isUserAdmin(){return user.isAdmin}
Sounds like Uncle Bob disciples
What a nightmare, AI only knows how to write crappy Clean 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.
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.
Even if I was paid for using LLMs I would still find the experience nightmarish. I really don’t want to be dependent on such a system and spend my time managing fleets
I always found that if you are good enough at whittling down boilerplate that coding becomes something akin to pure architecture.
I find that mediocre programmers and LLMs are bad at both. They're helpful if you want to shit out some repetitive boilerplate or perform a complex search of some kind but otherwise you're better off without.
ehh, they're pretty good at automated performance research and bug fixes, especially when spanned across hundreds of them.
bug fixes not so much. when I encounter a bug the first thing I do is ask an LLM and not only do they usually fail to get the correct solution, they often slap virtual duct tape on it which makes other bugs more likely.
feels like a harness issue, bug fixes work out fine with omp.sh as long as it can be tested properly. Untestable things tend to lead to hallucinated results though.
might be a symptom of writing complex code. I'm sure on basic CRUD they can figure out most bugs since most of them have happened 1000 times before.
I doubt it, a lot of what I use llms for is on the very edge of what these models are trained for.
How exactly will models get cheaper?
Compare the performance of a 980 and a 5050 and I am sure that will answer your question.
Also models baked into the silicon are able to achieve efficiency that is simply impossible to achieve with programmable circuits, there is a general slowdown in the raw capabilities that transformers can achieve and agentic tool use is simply an amplifier that will reach a wall eventually. It wouldn't surprise me if we saw within 5 to 10 years accelerator cards that you're able to purchase and plug into via usb-c that are able to achieve thousands of tok/s as well as api costs going down to what we already see with subscriptions today.
There has been quite a lot of off-ramping going on where people feel satisfied with the performance they're getting out of the models and simply staying there instead of using SOTA.
if i'm a programmer for example, even being a couple months old is a huge annoyance because programming languages and frameworks are changing all the time...
When was the last time you heard about someone talking about "Knowledge Cutoff" dates? OpenAI used to make a huge deal about it every release, now its not even mentioned.
We give agents tools, the ability to read a man page, the ability to use web search. Knowledge cut-off is far less important than it used to be.
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.
For what it’s worth, I’ve made really good, state of the art software in my areas of interest using LLMs. So I do believe you can produce really good software using them. But it’s domains where I have decade of experience.
But even with that result I don’t think it’s something we should bet the whole industry on, and something I personally don’t feel comfortable relying upon
Idk, ymmv. I’ve had very good outcomes writing embedded firmware for complex systems, drivers, etc. it’s really, really good at not bodging the kinds of things that always catch meaty developers unawares.
OTOH, we run extensive harness optimization, where everything is specified in advance, then a plan is made, then a naive review of the plan vs the specification vs the blast radius, then implementation, tests, then a naive review of test coverage, a naive review of the code vis a vis our code guidelines, a review for smells, a review for silo violation and architecture compliance, a reconciliation of the documentation, then planning the next subfeature, etc. probably 10 percent code generation, 40 percent documentation and planning and adversarial review, 50 percent automated adversarial code review.
We use a Claude for planning and generation, sol for adversarial review. Our metrics say we are about 2x. Productive, at a cost of about $300 per dev per month.
We are also shipping less bugs and better, more clearly written documentation (we use technical writing English style guides implemented by Claude)
I think a big part is the constant adversarial review by a different model with no prior context except the coding standards. Also important is context management, we do an onboarding and wrap-up for each session where we have a batch of continuity documents- Learnings, musings, and roadtrips where we let the most successful high-context sessions research and then write about something that they “ became curious about” during the session. That actually brings in a lot of insight to the team and occasionally is brilliant.
Also critical is crossing compaction barriers (standard re-onboarding protocols, writing transition documents prior to compaction, etc)
Also critical is being able to smell when a session is going off the rails. What we do there is sideline the session, wait for master to advance a bit, then have it do a “4c’s” review of the committed work, blast radius analysis, and remediation. If there’s still useful context left we put it into a project unrelated to its failure context. That salvages the valuable session context without staying in the failure trench.
It’s a lot like herding cats.
How much does your whole setup cost? Just curious. An estimated range would be interesting to have
We built all the tooling as Claude-code tools (mostly in python) and the rest is just documentation for preloading the context and as reference material to pull in by policy before certain tasks. Really, there is nothing complicated or heavy, it’s all process.
About $300 per dev per month. Importantly, we are not buying tokens, but the coding plans.
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.
I find this is the difference between people that 2-4x their productivity and improve their shipping quality vs those that don’t find AI very useful. It’s all about the process, the adversarial tension, and the documentation driving the process. The good code squeezes out of that pressure like juice being pressed from fruit.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
"Integrations & AI Agents to ship financial products in days, not months."
https://www.rutter.com/
AI salesperson claims that AI works in principle.
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.
I don't know if I buy the "Pre AI (hours)" and "Post AI (hours)"
I'd say for reference "senior developer" the main problem is spending full 1.5 hours on meetings each day
> 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?
We run extensive harness optimization, where everything is specified in advance, then a plan is made, then a naive review of the plan vs the specification vs the blast radius, then implementation, tests, then a naive review of test coverage, a naive review of the code vis a vis our code guidelines, a review for smells, a review for silo violation and architecture compliance, a reconciliation of the documentation, then planning the next subfeature, etc. probably 10 percent code generation, 40 percent documentation and planning and adversarial review, 50 percent automated adversarial code review.
We use a Claude for planning and generation, sol for adversarial review. Our metrics say we are about 2x. Productive, at a cost of about $300 per dev per month. We are also shipping less bugs and better, more clearly written documentation (we use technical writing English style guides implemented by Claude)
I think a big part is the constant adversarial review by a different model with no prior context except the coding standards. Also important is context management, we do an onboarding and wrap-up for each session where we have a batch of continuity documents- Learnings, musings, and roadtrips where we let the most successful high-context sessions research and then write about something that they “ became curious about” during the session. That actually brings in a lot of insight to the team and occasionally is brilliant.
Also critical is crossing compaction barriers (standard re-onboarding protocols, writing transition documents prior to compaction, etc)
Also critical is being able to smell when a session is going off the rails. What we do there is sideline the session, wait for master to advance a bit, then have it do a “4c’s” review of the committed work, blast radius analysis, and remediation. If there’s still useful context left we put it into a project unrelated to its failure context. That salvages the valuable session context without staying in the failure trench.
It’s a lot like herding cats.
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...
why do i have to watch a mermaid repeatedly move up and down and kiss your likeness ad infinitum while i read this post
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.
AI non believer rolls out old tropes, concludes AI not really much of a thing, probably mass hallucinated.
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.
"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.
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.
product and engineering will gradually collapse into one role
> 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.