Van Brabant argues that organizations confuse coding speed with delivery speed. Since developers spend only 30-40% of their time writing code, and the rest on reviews, meetings, requirements, and coordination, AI assistants accelerate the minority of the process while leaving the actual bottlenecks untouched. Bolting AI onto a slow process just produces a fast coder waiting inside a slow system.
The editorial frames AI coding tools as the silver bullet for accidental complexity that Brooks predicted could never solve the whole problem. Now that we actually have tools that eliminate boilerplate and mechanical coding, delivery still isn't faster — which serves as modern empirical proof that Brooks was right about essential complexity residing in understanding what to build and coordinating the people building it.
Van Brabant's post implicitly challenges the '10x developer productivity' pitch from AI tooling vendors like Copilot, Cursor, and Claude Code. While he acknowledges these tools are genuinely useful, his argument undercuts the enterprise sales narrative by distinguishing individual task speed from organizational throughput — a distinction that vendor marketing systematically blurs.
On May 15, developer Frederick Van Brabant published a blog post titled "I don't think AI will make your processes go faster" — and within two days it climbed to 287 points on Hacker News. The thesis is deceptively simple: AI coding assistants make *individual tasks* faster, but the overall software delivery process doesn't speed up, because writing code was never the bottleneck.
The post arrives at a moment when every enterprise buyer is being pitched "10x developer productivity" by AI tooling vendors, and when Copilot, Cursor, and Claude Code have become genuinely useful daily tools. Van Brabant isn't arguing these tools are bad. He's arguing that bolting them onto a slow process produces a fast coder waiting inside a slow system.
The core claim is that organizations confuse *coding speed* with *delivery speed* — and they are not the same thing.
### The Bottleneck Was Never Typing
Study after study has shown that professional developers spend roughly 30-40% of their time actually writing or modifying code. The rest is reading code, understanding requirements, waiting for reviews, sitting in alignment meetings, debugging integration issues, waiting for CI pipelines, and navigating organizational decision-making. AI assistants dramatically accelerate the 30-40%. They do approximately nothing for the other 60-70%.
This isn't a new observation — it's a restatement of what Fred Brooks identified in 1986's "No Silver Bullet." The essential complexity of software lives in understanding *what to build* and *coordinating the people building it*, not in the mechanical act of translating intent into syntax. What Van Brabant adds to Brooks is a modern data point: we now have the silver bullet for the accidental complexity (AI writes the boilerplate), and delivery still isn't faster, which proves Brooks was right about where the real complexity lives.
### The Jevons Paradox of AI-Assisted Development
There's an even more uncomfortable possibility lurking beneath the surface: AI-assisted coding might make processes *slower*. When generating code becomes nearly free, teams generate more of it. More code means more to review, more to test, more to maintain, more to debug. If your review process was already a bottleneck with 300 lines of code per PR, it becomes a catastrophe when AI lets developers produce 1,200 lines before lunch.
This is Jevons paradox applied to software engineering. When coal-burning efficiency improved in 19th-century England, coal consumption went *up*, not down, because cheaper energy enabled more use cases. Similarly, cheaper code production doesn't reduce the total work — it expands the surface area of code that needs human judgment applied to it.
Several Hacker News commenters have reported exactly this pattern: their teams adopted Copilot or similar tools, PR volume spiked, but cycle time (commit to production) either flatlined or increased. The individual developer felt faster. The dashboard said otherwise.
### What Vendors Won't Tell You
The productivity claims from AI tooling vendors are almost always measured in *task completion time* or *lines of code*, never in *cycle time* or *lead time for changes* — the DORA metrics that actually correlate with organizational performance. This is not an accident. Measuring the thing AI is good at (generating code) makes the product look transformative. Measuring the thing that matters (getting working software to users) reveals a much more modest impact.
To be fair, some AI tools are starting to address the broader process. AI-assisted code review (Greptile, CodeRabbit) targets the review bottleneck directly. AI test generation aims to shorten the testing phase. AI-powered incident response (PagerDuty's recent integrations) attacks the feedback loop. These are more interesting than code generation precisely because they target actual bottlenecks. But they're also harder to build, harder to sell, and further from market maturity.
### Audit Your Actual Bottlenecks Before Buying Tools
Before spending another dollar on AI developer productivity tooling, run a value stream map on your last 10 features. Measure the time from "developer starts coding" to "code is in production." Then measure the time the developer actually spent writing code. If coding represents less than a third of the total — and it almost certainly does — the ROI of faster coding tools is capped at roughly one-third of the theoretical maximum improvement, no matter how good the AI gets.
The higher-leverage investments are boring and organizational: faster code review turnaround (target: under 4 hours), automated CI that completes in under 10 minutes, clear ownership so decisions don't require three meetings, and deployment pipelines that let you ship without a change advisory board.
### Use AI to Compress the *Right* Tasks
The smartest teams using AI aren't just generating code faster — they're using AI to compress the coordination overhead. That means:
- AI-drafted PRs with context: Use AI to write PR descriptions that pre-answer reviewer questions, reducing back-and-forth cycles. - AI-generated test plans from requirements: Cut the gap between "we agreed on what to build" and "we have test coverage for it." - AI-summarized incident timelines: Shrink the time from alert to root cause by having AI correlate logs, recent deploys, and past incidents.
The practitioners getting real delivery speed gains from AI are the ones using it to eliminate *wait states and handoff friction*, not to write more code per hour.
### Don't Confuse Feeling Fast with Being Fast
This is the subtlest trap. AI tools provide an incredible *feeling* of velocity. Autocomplete flowing, tests appearing, boilerplate vanishing — it genuinely feels like 10x. But individual flow state and system throughput are different measurements. A developer who writes a feature in 2 hours instead of 8 but then waits 3 days for review has improved their personal utilization by 75% and improved delivery time by roughly 7%. The team's throughput barely moved.
Track cycle time, not coding time. If your metrics dashboard doesn't distinguish between the two, you're flying blind — and you'll keep buying tools that optimize the wrong thing.
Van Brabant's post is a useful corrective at a moment of peak AI productivity hype. The tools are genuinely good — better than most skeptics predicted two years ago. But the lesson of every previous productivity revolution in software (structured programming, OOP, agile, DevOps, cloud) is the same: the technology shifts the bottleneck, it doesn't eliminate it. AI has shifted the bottleneck from "writing code" to "everything else." The teams that win the next cycle will be the ones who noticed.
I think when LLMs first came out people thought they could just say something like, "Make a Facebook clone". But now we're realizing we need to be more exact with our requirements and define things better. That has always been the bottle neck in software.When I was working we used to
I understand this post comes from the PoV of a developer, but the key point is:>Maybe this setup is faster compared to the old way of working. But I also think it’s an unfair comparison. Working like this requires a much deeper involvement of domain and product experts. This involvement would mea
On the one hand, this is a clean post that explains exactly what a lot of us have been thinking and seeing on the job at large organizations doing tech work. Dear Author, I agree with you 110% and want everybody else to come to understand what you have written.On the other hand, it feels like we
This article assumes that AI only has an impact on the development phase which is certainly not true. It can speed up every part of the step. Including ideation, legal, documentation, development, and deployment.Ideation: Throw ideas back & forth, cross reference with knowledge bases, generate d
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> This exact thing is what software developers have been begging for since the beginning of the profession: Receiving a detailed outline of the problem and what the end result should look like.> This is often the part that slows down software development. Trying to figure out what a vague, tit