The AI Productivity Gap

8/3/2026 at 9:21:27 AM

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.

by matthorse

8/3/2026 at 9:38:34 AM

> you've mostly increased the team's work queue rather than its throughput

Amdahl’s law remains unbeaten

by swiftcoder

8/3/2026 at 3:48:54 PM

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)

by Yopolo

8/3/2026 at 11:29:20 AM

> 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.

by mingusrude

8/3/2026 at 2:35:29 PM

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.

by acdha

8/3/2026 at 12:14:26 PM

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.

by zombot

8/3/2026 at 9:40:07 AM

Good summary. Theory of constraints in action.

by joe_fishfish

8/3/2026 at 9:22:12 AM

Perfect summary of what's going on today

by jorisw

8/3/2026 at 11:19:12 AM

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.

by warent

8/3/2026 at 2:06:02 PM

more and more of the thought stuff is being done by AI, let's not kid ourselves.

by bibimsz

8/3/2026 at 1:52:13 PM

[flagged]

by Alessio97

8/3/2026 at 9:04:47 AM

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.

by PostOnce

8/3/2026 at 9:48:14 AM

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.

by yoz-y

8/3/2026 at 3:24:59 PM

> 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?

by aaron_m04

8/3/2026 at 4:03:29 PM

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.

by yoz-y

8/3/2026 at 10:37:24 AM

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.

by witx

8/3/2026 at 9:23:23 AM

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.

by rightbyte

8/3/2026 at 4:40:17 PM

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.

by ericmcer

8/3/2026 at 7:44:26 PM

> 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*

by bluefirebrand

8/3/2026 at 9:45:27 AM

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.

by ACCount37

8/3/2026 at 1:14:46 PM

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.

by dzonga

8/3/2026 at 2:47:35 PM

[dead]

by renezander030

8/3/2026 at 8:54:28 AM

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...

by laszlojamf

8/3/2026 at 9:06:39 AM

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

by dgellow

8/3/2026 at 9:20:27 AM

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.

by himata4113

8/3/2026 at 11:35:45 AM

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

by dgellow

8/3/2026 at 9:38:13 AM

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.

by pydry

8/3/2026 at 10:06:43 AM

ehh, they're pretty good at automated performance research and bug fixes, especially when spanned across hundreds of them.

by himata4113

8/3/2026 at 1:13:43 PM

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.

by pydry

8/3/2026 at 1:21:30 PM

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.

by himata4113

8/3/2026 at 2:47:32 PM

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.

by pydry

8/3/2026 at 3:53:59 PM

I doubt it, a lot of what I use llms for is on the very edge of what these models are trained for.

by himata4113

8/3/2026 at 10:20:47 AM

How exactly will models get cheaper?

by rimliu

8/3/2026 at 10:47:35 AM

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.

by himata4113

8/3/2026 at 9:17:46 AM

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.

by mawadev

8/3/2026 at 9:48:39 AM

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

by dgellow

8/3/2026 at 10:57:48 AM

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.

by K0balt

8/3/2026 at 3:02:50 PM

How much does your whole setup cost? Just curious. An estimated range would be interesting to have

by dgellow

8/3/2026 at 9:29:15 PM

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.

by K0balt

8/3/2026 at 9:32:59 PM

About $300 per dev per month. Importantly, we are not buying tokens, but the coding plans.

by K0balt

8/3/2026 at 10:52:30 AM

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.

by fer

8/3/2026 at 9:17:32 AM

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

by dwedge

8/3/2026 at 9:55:26 AM

You should spend time as much as 50% on harness engineering for you and team to stop that and make the AI steer better.

by hahahaa

8/3/2026 at 11:02:50 AM

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.

by K0balt

8/3/2026 at 9:52:25 AM

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.

by hahahaa

8/3/2026 at 9:41:43 AM

Which is why, when I can get away with it, I only use AI for improved code completion, or generating the initial boilerplate.

by pjmlp

8/3/2026 at 9:21:50 AM

I find myself in the same situation, baby sitting AI agent, monitoring them. It's like l've become a coordinator.

by pop3zxcv

8/3/2026 at 11:03:34 AM

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.

by K0balt

8/3/2026 at 10:24:39 AM

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?

by Diti

8/3/2026 at 5:34:54 PM

> 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.

by wannabe44

8/3/2026 at 10:44:57 AM

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.

by brabel

8/3/2026 at 11:38:36 AM

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.

by 1718627440

8/3/2026 at 10:32:48 AM

You're looking at the forest, OP is looking at the trees.

by ramon156

8/3/2026 at 12:32:55 PM

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.

by orwin

8/3/2026 at 12:39:08 PM

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.

by ryandvm

8/3/2026 at 1:16:20 PM

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.

by vouaobrasil

8/3/2026 at 9:14:42 AM

> 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.

by dwedge

8/3/2026 at 9:59:23 PM

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.

by biggestriverman

8/3/2026 at 9:51:26 AM

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.

by crnkofe

8/3/2026 at 10:41:13 AM

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...

by swiftcoder

8/3/2026 at 3:50:35 PM

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.

by asdff

8/3/2026 at 9:10:58 AM

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.

by vb-8448

8/3/2026 at 9:16:13 AM

"... unneeded refactoring, rewrites and "what-if" scenarios ..."

Like so many senior developers I have encountered. That stuff is good for CV.

by dude250711

8/3/2026 at 9:37:05 AM

It's on a completely different level now.

by vb-8448

8/3/2026 at 8:54:51 AM

"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...

by mawadev

8/3/2026 at 9:15:51 AM

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.

by dwedge

8/3/2026 at 1:42:35 PM

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.

by hetsaraiya

8/3/2026 at 9:17:37 AM

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.

by qsort

8/3/2026 at 10:10:35 AM

It's like you just made up those numbers and then developed your thesis around that.

by raver1975

8/3/2026 at 10:32:24 AM

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.

by arrrg

8/3/2026 at 10:14:04 AM

That’s exactly what was done.

by steelkilt

8/3/2026 at 9:33:24 AM

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.

by ectoloph

8/3/2026 at 10:26:19 AM

Exactly this.

by docheinestages

8/3/2026 at 9:42:58 AM

> 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.

by sandeepkd

8/3/2026 at 10:46:39 AM

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.

by cadamsdotcom

8/3/2026 at 9:20:18 AM

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.

by ghenna

8/3/2026 at 9:47:11 AM

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.

by adithyassekhar

8/3/2026 at 9:52:14 AM

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.

by furyofantares

8/3/2026 at 10:11:40 AM

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.

by alienbaby

8/3/2026 at 7:00:42 PM

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.

by bigstrat2003

8/3/2026 at 4:26:52 PM

I'd say for reference "senior developer" the main problem is spending full 1.5 hours on meetings each day

by nurumaik

8/3/2026 at 10:12:37 AM

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.

by Arshad-Talpur

8/3/2026 at 10:52:37 AM

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.

by zmmmmm

8/3/2026 at 11:27:24 AM

"Integrations & AI Agents to ship financial products in days, not months."

https://www.rutter.com/

AI salesperson claims that AI works in principle.

by shAIster

8/3/2026 at 10:08:45 AM

> 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.

by tempfile

8/3/2026 at 4:21:11 PM

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.

by Supermancho

8/3/2026 at 11:07:44 AM

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.

by K0balt

8/3/2026 at 3:15:46 PM

Care to give an example?

by tempfile

8/3/2026 at 9:31:51 PM

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)

Also critical is crossing compaction barriers (standard re-onboarding protocols, writing transition documents prior to compaction, etc)

It’s a lot like herding cats.

by K0balt

8/3/2026 at 6:11:56 PM

Thinking logically about that system seems to be the most important thing.

by Hiro100

8/3/2026 at 2:04:59 PM

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.

by bibimsz

8/3/2026 at 7:34:42 PM

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.

by ryathal

8/3/2026 at 7:41:39 PM

product and engineering will gradually collapse into one role

by bibimsz

8/3/2026 at 9:41:06 AM

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.

by fearnot

8/3/2026 at 9:49:19 AM

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!)

by hahahaa

8/3/2026 at 2:59:03 PM

"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.

by iwontberude

8/3/2026 at 10:05:42 AM

> 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.

by 6stringmerc

8/3/2026 at 10:10:24 AM

[dead]

by ArchMMM

8/3/2026 at 10:04:37 AM

[flagged]

by claud_ia

8/3/2026 at 10:08:25 AM

[flagged]

by mangudai

8/3/2026 at 10:44:58 AM

[dead]

by h_mirin

8/3/2026 at 9:09:37 AM

[dead]

by ath3nd