Hacker News Reader

Comment by hgowietoi | Hacker News Reader

We shouldn't give up on line-by-line review for serious applications.

My company's leadership is oscillating every few weeks on AI goals. Their most recent story is "we're expecting developer velocity to approximately double over the new 2-3 years as people get better at using AI". But of course that's completely non sequitur. People on my team spend about 10% of their time writing code and 90% doing design and analysis. So if AI doubles our code writing velocity, then it will make us 5% faster overall.

View on HN

> So if AI doubles our code writing velocity, then it will make us 5% faster overall.

This tracks with the actual revenue impact of AI adoption:

https://www.bcg.com/publications/2026/the-formula-for-agenti...

Their very cheerful "high" revenue increase from AI adoption (that few companies in the index manage to achieve) sits at 4.5%. Most of those in the "value generating" minority are seeing sub-1% returns.

Which, of course, is non-zero, real, and all that, and matters when we're talking about a 4-5% increase of a big company's revenue, assuming the expenses are not catching up with that.

Which they absolutely are. The AI is subsidized by venture capital, and the subsidies are drying up (hence OpenAI upcoming funding round). None of the AI companies are profitable (much less self-sustaining), and AI prices are inevitably increasing.

I wish they taught Amdahl's law in business school. Or at the very least the simple concept of "bottleneck".

"The Goal" is a key business book for a reason, but leadership seems to not get the lesson. Or care?

I’m sure they learn it by other names.

The point is that while good to remember, and specifically Fred Brook’s “No Silver Bullet” article about it, there are second order effects.

If coding becomes 100x cheaper, what’s going to happen next? At least to some degree, design and planning was there since coding is expensive. (Not just coding, debugging also got squashed by AI and was an expensive part of the job)

This is why the original comment seems pretty spot on, organizations will learn how to skip more phases, and startups are probably a place where this will be happening faster. (Not clearly though, a lot of big tech are happy tokenmaxxing to try and not stay behind those startups when they come)

Brooks' point was more about accidental vs. essential complexity. You seem to be implying that design was only ever an artifact of "expensive" typing, but design exists to prevent systems from collapsing under different failure states.

If the cost of emitting syntax collapses without adequately resolving the essential complexity then you have not eliminated the design phase and you're just externalizing your failure modes onto downstream teams and systems.

I like the "9 women can't birth 1 baby in one month"

Fred Brooks wrote a whole ass book based on that premise, and people still haven't learned the lesson half a century later.

Just to back you up most surveys say only 10% to 20% of programmers time is coding.

Microsoft study of 484 developers, published in 2025 says 11%.

Another Microsoft study where programmers had telemetry installed showed 21%

https://gwern.net/doc/psychology/writing/2017-meyer.pdf

It's interesting. I remember around COVID, there were a bunch of startups building 3d printers for concrete housing. Then I looked up the actual cost of construction for a typical house, and only 14% of it was the most visible part (the balloon framing and physical house). Most of the cost is in foundations, plumbing, wiring, and things like insulation, flooring, cabinets, etc.

I guess at Microsoft coding is similar to building a house in that sense. Either that or all big orgs devolve into large amounts of time spent on politics.

I don't think balloon framing is used anymore? It's a bad fire risk.

90% of my time these days is trying to understand what the wall of claudeslop jira ticket is actually asking for. It's like archeology digging for the original customer issue to work out what is actually wanted underneath paragraphs of root cause load bearing seams.

Coding was never the bottleneck...

And how many billions or trillions have we wasted on people who didn't understand that (or did, and are just busy generating hype).

Ultimately, this (llm) technology (as it is being developed/used), is not useful to us...

Yup we already knew this.

Google had many engineers working on a) failed projects b) people being paid to sit around.

There seems to be this strange belief on here that making something more accessible to everyone will always result in better outcomes. I don’t see this being true of software.

I’m very pro-tech. But nobody can point me to a product built by someone outside of the large tech firms, made by by llm’s that is a great value add to one’s life. Many of those were already created - they’re on the apple App Store for example.

I’m absolutely confident coding speed is irrelevant. A person who has a real vision + strategy and hand written code will beat the team with no vision, strategy and code blasted out by llm’s.

Sure llm’s could augment the former - but you’re missing the point!!

> A person who has a real vision + strategy and hand written code will beat the team with no vision, strategy and code blasted out by llm’s.

But you have to beat the team with vision + strategy who is also blasting out code with LLMs.

Certainly, the time it takes to figure out that an idea is bad had been shortened :)

If the time taken is shortened but you don't learn anything from it, then you're still behind.

Actually you're not just behind, you've burned up money.. you've destroyed value - there's an opportunity cost of that money. Whilst the other competitor who is prudent eventually wins will be far more attractive in the eyes of investors - moreover once you are confident you can scale up inputs (engineers) and hone in the quality whilst the other competitor runs ragged with a half-baked product.

We've seen this story play out already numerous times: Apple. They made a mis-step with Apple Intelligence but aside from that, they've been right not to lurch to deep into things they shouldnt. Its not zero-sum.

There's a difference between vibe coded slop, vibe coded kinda slop built by an engineer, AI assisted engineers, and AI planning. I enjoy writing code by hand but it's quickly becoming apparent that LLMs are now a tool that one should be using in some capacity.

Nobody writes code in notepad anymore, even though you could and might even like all the black text.

I'm fairly pessimistic about LLMs, but I do find they're a good research tool. If I can accelerate finding answers amid the slurry of Confluence, Slack, assorted other intranet places and the web, I can get back to thinking about the design and programming.

I have a user CLAUDE.md that tells it not to presume to modify any files, and a bunch of internal MCPs for our logging and monitoring tools, documents, git repositories and such, and I've been dabbling with writing skill files so it can access some other internal things.

So I can basically say "this thing isn't working because x, and it's probably related to y not having z" and it'll go off and find info buried in the corporate abyss.

Then other people yeet wildly awful LLM generated PRs over the fence and I lose my sanity from basically having fight a constant battle against a slow rot of software quality that will bite us later.

Which is basically what this study is showing.

Is your company striving to automate design and analysis, then?

> We shouldn't give up on line-by-line review for serious applications.

But how many changes are actually serious?

I can have an agent mass-produce security bug fixes, zip through our low-priority backlog, etc.

IMO - we need to get out of our own way.

Building is cheap now. Agents are also really good at following checklists and running tests.

So instead of having individual engineers reviewing code, we need to

* Leave human review for the most impactful changes

* Get better at defining the quality bar

* Continually codify human concerns into rules or systems that can be checked against

A lot of this was touched on a few months ago with Spec-driven development becoming a hot topic when agentic coding started.

We should continue that with spec-driven review, testing, etc.

> the most impactful changes

Quite a lot of our bugs in production have been in seemingly less impactful changes. How do you know what's impactful a priori?

> I can have an agent mass-produce security bug fixes

I can't figure out what you're trying to say here. Are you saying that this is acceptable? Because I very much don't think it is. You'll have twice the bugs after you're done, and they'll be inhuman ones that you have little chance of catching.

> But how many changes are actually serious?

I mean, "security bug fixes" are not on your list of serious changes? What is?

...and they are not using LLMs to help speed up design and analysis?

I'm no booster but this is most of what I currently spend tokens on so it's maybe not as absurd as it sounds. Maybe those gains are possible and without having to sacrifice serious code reviews too.

Reply on news.ycombinator.com