Loading today’s stories
Product1 publisher3 min readPublished
A Red Hat engineering post argues the cost of writing code has collapsed while the cost of reviewing, validating, integrating and maintaining it has not, and its fix is a threshold each developer has to spot mid-task.
The Product Desk · Product desk
Compiled by The Product DeskSomething wrong?How this is made
Multiply the post's two examples and the shape of the problem shows up. Red Hat's author says 300 lines take about five seconds to generate [4], which works out at 60 lines a second, so the 2,000-line diff described a few paragraphs earlier is roughly 33 seconds of machine output [1]. Both figures are illustrations rather than measurements [11], and the ratio is the part that survives that caveat: the reviewer deciding whether the new retry logic is safe [3] spends an afternoon on something that cost half a minute to make.
Here is what teams tell themselves about that trade: the assistant took the tedious typing, and the engineers moved up to design. Here is what happens in the queue. The diff arrives without the prompt that produced it, the reviewer reconstructs intent from the code, and the change still has to be checked against APIs, dependencies, CI pipelines, security tooling, release processes and downstream consumers [10] that the agent never had in view. Red Hat makes a related point about the model itself, which pattern-matches well inside a single file or function and struggles to hold boundaries, long-term architecture and system-wide consistency [12].
The remedy the post offers is individual. Take the keyboard back when steering the prompt costs more energy than writing the logic yourself [7]. That asks a developer to notice a threshold halfway through a task, at the exact point where sunk effort argues loudest for one more prompt. The organisational version is duller and more durable: encode the constraints in repository-level instructions, because a large context window does not guarantee an important constraint stays active in the reasoning [8].
What the post does not carry is a delivery number. It is written up as lessons from the field, with no lead time and no change failure rate reported [11]. So the claim that system reliability and feature quality stay flat or decline while lines of code and PRs merged climb [5] is Red Hat's read from practice rather than a measurement anyone can check. Worth saying out loud if you are taking it into a leadership review.
The 2x2 to draw before Monday puts cost to generate on one axis and cost to verify on the other. Cheap to generate and cheap to verify, meaning scaffolding, fixtures and docstrings, is where an agent can run with a light touch. Expensive to generate and cheap to verify is a straight win. Cheap to generate and expensive to verify is the box that hurts: auth, schema migrations, retry and backoff, anything crossing a boundary another team owns, where fast production is precisely what floods the person who has to sign off. Expensive on both axes is where the post's advice applies and you write it yourself [7].
The forcing function is one question asked when the PR opens: name the person who will verify this, and the hours it will take them. If nobody can answer, the work has not been finished, only handed on.
Ranked by verification strength, evidence, and original report placement.
The post describes a 'prompting overhead threshold' and advises that when prompt steering costs more energy than writing the logic yourself, stop prompting and write the code, treating AI as an assistant rather than a replacement.
The post presents its evidence as 'lessons learned from experience' and lessons from the field, using illustrative examples rather than reported delivery measurements; it gives no lead time or change failure rate figures.
At the post's own stated rate of 300 lines in 5 seconds, the 2,000-line diff it describes represents about 33 seconds of generation.
A Red Hat blog post argues that AI has dramatically reduced the cost of producing code, but the work that defines software engineering (understanding, reviewing, validating, integrating and maintaining that code) has not become proportionally easier, and calls this the AI productivity paradox; it says the bottleneck has shifted from writing software to reasoning about it.
The post says an AI coding agent can implement features in minutes that might have taken an engineer an hour, and can generate tests, refactor code, write documentation, navigate large repositories and execute development tasks autonomously.
The post describes staring at a 2,000-line diff, trying to understand why the agent refactored unrelated files, whether the new retry logic is safe, and which change introduced a regression.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Field notes, self-labelled
Everything rests on one Red Hat post that says outright its material is lessons learned from experience. It offers exactly two numbers, 300 lines in five seconds and a 2,000-line diff, both illustrative, and no lead time, change failure rate or review-hours data a reader could check the thesis against. The observations are plausible to anyone who has reviewed agent output; plausible is not measured.
Practice described, scale absent
The author writes as a daily user of coding agents and names the artefacts he relies on, which tells us the workflow exists somewhere inside Red Hat engineering. But the post never says how many engineers use it, which repositories it touches, or how often the keyboard actually goes back to the human. One engineer's routine will not support an adoption reading.
Broader than its examples
The framing runs against AI productivity marketing rather than with it, so the overstatement is not promotional. It is generalising: the claim that merged-PR counts climb while reliability declines is presented as a pattern with nothing measurable behind it, and the assertion that verification takes the same reasoning as before is an equivalence nobody timed. The advice survives the gap better than the diagnosis does.
House blog, product-neutral advice
This is published on Red Hat's own site by someone it employs, with no outside editor between draft and post. The counsel cuts against the sales pitch it could have made: sometimes stop prompting and write the code, and the tooling it recommends, an AGENTS.md-style rules file and a Homebrew Bash, is in nobody's catalogue. What is left is the ordinary reputational interest a platform vendor has in sounding like the sober voice on engineering practice.
Clear source, untested reach
There is no ambiguity about what is being claimed or who claims it, and the arithmetic inside the piece holds. How far it generalises is the open question: there is one publisher, one author and no counter-account, so a reader cannot tell whether this describes Red Hat's repositories or everyone's.
build
The compiler checks three of the seven things your coding agent had to get right1 publisher
build
Superpowers makes spec-driven work a precondition, then ships it to twelve harnesses1 publisher
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 publisher
leadership
Block says 95% of its engineers use AI daily. The interesting part is who runs five agents.1 publisher
Publishers with included, body-backed reporting in this cluster.
1 article · September 6, 2026