This article examines how AI agents change the standard for developer productivity. Author lauren previously considered lines of code and PR counts poor performance measures. Now, she argues, volume, provided quality and impact are maintained, has become a meaningful signal. The point is not simply more PRs, but the ability to build a machine that produces software by earning trust in and operating agents.
1. Why PR Counts Were Not the Main Metric
Engineers who worked before agents are understandably skeptical of measuring productivity by lines of code or PR counts, lauren says. She originally agreed.
Large teams usually valued impact over volume. One configuration line saving millions could be a major achievement despite producing just one PR. Many PRs did not inherently mean good engineering.
"Volume used not to matter because we focused on impact. You could have high impact with only a few PRs."
Counts were still discussed at the extremes of performance:
- Someone struggling might produce exceptionally little.
- At the other extreme, a "coding machine" could independently solve huge numbers of problems and ship successive PRs.
Volume thus had some meaning, but as a supporting measure combined with impact, mainly in extreme cases.
2. A New Productivity Standard Created by Agents
lauren thinks agents have brought productivity questions once associated with large tech companies to small and medium-sized companies, because powerful coding models are available to everyone.
Current models write faster than humans and sometimes outperform them. Shipping the same PR count as before should therefore prompt reflection on one's approach.
"Everyone now has the ability to become a coding machine."
"With alien intelligence already here, shouldn't you pause and ask why you're not shipping more than a human coding machine?"
This is not simply an instruction to ask AI for code and increase counts. The argument is that AI creates the potential for far more output, and engineers should consider how to turn that potential into real results.
3. Trust Is Central to Scaling Productivity
lauren returns to trust, a concept she has repeatedly emphasized. Without verification and working practices that make agent output trustworthy, even excellent models cannot greatly expand productivity.
"If you haven't done the work to trust agent output, scaling productivity is very difficult."
Effective agent use may require more tokens, or model usage. She recommends evaluating this as cost per unit of intelligence, rather than merely API expense.
Previously, producing more software required hiring many engineers at high labor cost. Tokens are expensive now but likely to get cheaper. She predicts costs that look high today may become affordable within six months to a year.
"One engineer with agents can do the work of dozens, perhaps hundreds, of engineers at a fraction of the cost."
4. From Producing Software to Building Production Systems
Many developers have not fully internalized that their profession has already changed or will soon change substantially.
Engineering was never only coding. But agents move engineers further from personally producing all software toward designing and operating the systems and machines that write it.
"Our job is no longer just producing software. It is building the machine that writes software."
She calls this a software factory, or, preferably, a Michelin kitchen. As a great kitchen systematically arranges ingredients, cooking processes, roles, and quality control, agent-enabled teams must carefully design workflows, standards, review, and improvement.
Large-scale agent operation remains an area of active investigation. She says she shares her experience to demonstrate what rigorous agent practices make possible, rather than to boast. 🍳
5. Questions About Hundreds of PRs a Day
Emil Kowalski asks seriously why shipping hundreds of PRs daily makes sense or is necessary.
"Can someone explain how shipping hundreds of PRs a day makes sense? Why would you need to ship that many in the first place?"
lauren explains that she does not inflate counts by splitting one task. They reflect multiple parallel projects, including:
- Continuous performance improvements
- Fixing user-reported bugs
- Ongoing refactoring and improvement of the Grok bot codebase
- Making the codebase easier for agents to work in
- Foundational work accelerating the whole team
"I work on multiple projects in parallel, so it adds up quickly."
Making a codebase agent-friendly is more than maintenance. Better structure helps AI understand and modify code, accelerating every teammate using agents. Many PRs can therefore represent continuous improvement of the whole development system, not merely personal coding volume.
She again emphasizes building the machine that builds software. This may sound strange or exaggerated to outsiders, but becomes natural through actual practice.
"It may be hard to understand or believe if you aren't doing it, but when you do it, it really makes sense."
6. The Understanding Gap Created by Different AI Experience
Another user, sophie, describes a source of confusion. People not using coding models daily struggle to understand the pace of improvement; daily users become so accustomed to it that they struggle to explain it plainly.
"Without using coding models daily, it's hard to understand how fast they're improving. But daily users may have enough 'AI psychosis' that explaining it accessibly becomes impossible."
lauren agrees. People who have experienced the practical transformation of agent-driven development may perceive it very differently from those who have not.
One participant reports already creating 600 PRs by following her approach, which she welcomes. Another finds the culture of boasting about counts strange: they build many demos and understand output's value, but do not see why displaying PR counts matters.
7. Volume as a Challenge to Improve Speed Without Sacrificing Quality
lauren replies that interpretation is a personal choice. For her, volume was a personal challenge prompted by confronting much lower productivity around eight months earlier, rather than a trophy.
"Eight months ago, when I was much less productive, I saw it as a challenge: how can I get faster without compromising quality? That's where learning began."
The article retains the premise that more PRs are not always better. Instead, it argues that engineers should move beyond old productivity standards and build systems capable of more work with quality, impact, and trust.
8. Closing
The message is simple: engineers must move beyond personally writing code to designing how AI reliably produces more high-quality software. Counts alone are not achievement. With sufficient quality control and impact, however, they can signal the changed reality of productivity.