AI Lets Us Produce Code Faster. But Who Will Review It?

Last year, a platform engineer on a mid-sized Hungarian team reviewed two or three pull requests a day. This year, ten. Some of the changes run to around a thousand lines, and here and there they include out-of-ticket, "I was in there anyway" modifications. CI sometimes barely copes, the review queue is permanently full, and the codebase is slowly starting to look as if it had been written by more people than actually work on it. The team has not doubled in size. The coding agent, however, has arrived.

It is easy to dismiss this as an individual complaint. It is not. According to GitHub's 2025 Octoverse report, an average of 43.2 million pull requests are merged on the platform every month, a 23% year-on-year increase, and close to one billion commits were made in 2025. Copilot's coding agent alone opened more than one million PRs in five months. The feeling of a "PR factory" is therefore not a mood but the local fallout of a global explosion in volume. The question this article asks is simply this: if writing code has become five to ten times faster, who will review, understand and take responsibility for what we generate five to ten times faster?

It is worth clarifying what a coding agent is, because in everyday speech it blurs into the old autocomplete. Today's agent no longer just completes a line: it makes a plan, modifies several files, writes tests, opens a pull request, launches subagents, and runs preconfigured checks, called hooks. This is qualitatively different from two years ago.

That does not make it an autonomous senior engineer. It is far more accurate to think of it as a fast, cheap and tireless junior system: it produces a great deal, often usable, but it does not understand the context the way someone who has been building the system for years does, and it cannot bear responsibility. It is useful when there is engineering control above it: specification, boundaries, review. Left to itself, it does exactly what an unsupervised junior does: a lot, quickly, and sometimes confidently in the wrong direction. The confidence is the risk here. The agent rarely signals when it is unsure, and it writes convincing code even when that code is syntactically flawless but does not fit the logic of the system. Typically only someone who truly understands the system notices.

The question of AI use has been settled. According to DORA's 2025 research, which surveyed nearly five thousand professionals, 90% of developers use AI, a jump of fourteen percentage points in a single year. In JetBrains' survey of twenty-four thousand, 85% use it regularly, and 62% rely on at least one coding assistant or agent. According to Stack Overflow, 84% use or plan to use AI tools, and 80% of new GitHub developers start in their first week. There is no more debate here: the question is no longer whether we use it, but under what organizational control.

Because alongside use, another number stubbornly holds on: trust, which is falling. At Stack Overflow, 46% of developers explicitly distrust the accuracy of AI output, up from 31% a year earlier, and only 3% trust it highly. In Sonar's 2026 study of more than a thousand people, 96% of developers do not fully trust that AI code is functionally correct. This duality of high use and low trust is the most telling pattern of 2025, and it is not technophobia. It is the sober reaction of a profession that thinks deterministically to a nondeterministic tool. Developers also largely find AI useful: according to Sonar, 82% agree that it speeds up coding, and according to JetBrains, 90% save at least an hour a week with it. These are real perceptions, and this is exactly where the misunderstanding begins.

The trouble comes from confusing the speed of writing code with the speed of delivering software. These are in fact four different things that everyday speech lumps together: how fast code is produced, how much faster the developer feels, how long it takes for a need to reach the user, and how maintainable what we have built is. AI almost always improves the first two. It does not guarantee the third and the fourth. At the heart of this breakdown is a cost asymmetry: generation has become cheap, understanding has not. Reading through, holding in your head and responsibly approving a thousand-line, machine-written PR takes the same amount of cognitive work as before, or more. Only today it is not necessarily done by whoever "wrote" the code, but by the reviewer.

Two studies show this gap most sharply, set against each other. In an early GitHub experiment built on an isolated task, Copilot users finished 55.8% faster, the emblematic number of the "it speeds us up" camp. In METR's 2025 randomized controlled trial, however, sixteen experienced open source developers worked on their own mature codebases and finished 19% slower with AI, while beforehand they had expected a 24% speedup and afterwards still felt 20%. The two results do not contradict each other; they measure different things. The lesson is neither that "AI speeds things up" nor that "AI slows things down," but that the effect depends on context. On an isolated, well-scoped task it typically speeds things up, while on a large, well-known codebase with strict quality expectations, the cost of cleanup can eat up the gains of generation. METR had a small sample and used early models, and the authors themselves call it a snapshot. But it is precisely the gap between perception and reality that matters: we misjudge even our own speedup.

In Hungary, this tension shows up most sharply on developer forums. It is important to be clear, though: these threads are not representative surveys. There is as yet hardly any representative Hungarian data on how widespread agentic coding is in the country, so I treat forum voices as a qualitative field diary, not as statistical evidence.

As signals, however, they are accurate, because the same figures and the same fault line keep coming back. There is the platform engineer buried under the PR volume. The senior reviewer who spends days reading code generated by others, code that looks fine at a glance but is poorly understood. The product manager who sees that the business rewards quantity. The infra engineer whom AI genuinely helps with scripting, while they clean up other people's hasty infrastructure changes. The AI-native developer who uses it well, because they know how to specify and verify. And the vibe coder who throws in a ticket and pushes up a big PR. The conflict is not developers versus management. It runs between speed and quality, business pressure and engineering discipline, apparent and real progress.

There is also an uncomfortable, almost sociological layer to this. The precise developer, who truly understands and validates the work, looks slower, because they really are slower than someone who just pushes. The weaker developer, with AI, produces output that looks better at a glance. It has become harder to tell at first sight who actually knows what they are doing. This is a matter not only of quality but also of trust and status within a team.

It is worth drawing a sharp distinction here, because much of the Hungarian debate can be resolved with it. On the forums, most people are not attacking AI, but the use of AI to skip the thinking.

One extreme is vibe coding: pasting a ticket, a Figma image or a loose idea into the model, large scope, little understanding, a big PR, out-of-ticket changes, a "tests are green, ship it" attitude and blurred responsibility. The other is AI-assisted engineering: up-front specification and engineering design, small scope, restricted agent permissions, maintained context files (CLAUDE.md, AGENTS.md, ai-docs), hooks that run linting, tests, type and security checks, AI review plus human review, and clear human responsibility. The same model, the same tool: two radically different engineering cultures.

A reassuring figure, incidentally: according to Stack Overflow, 72% of developers do not vibe-code in their own professional work. The phenomenon is louder than it is widespread.

If the data had to be condensed into a single sentence, it would be this: seniority is not disappearing but relocating. According to a 2026 longitudinal study, 82% of developers spend less time writing code, and the center of gravity of the work is shifting from creation toward validation. The authors call this supervisory engineering work. The sample is small and self-reported, but the direction matches the other sources.

A good senior is less and less the one who writes the most lines by hand. Rather, it is the one who specifies, draws boundaries, defends the architecture, reviews, validates, translates business logic, holds others to account on security and observability, and, perhaps most importantly, decides what must not be entrusted to AI. The prestige of hand coding may decline, but the value of engineering judgment rises. A good workflow is not complicated: specification, relevant context, a small step, AI implementation, AI review, human review, tests, merge. In this model, the agent is the fast but supervised junior, and the final decision and the responsibility stay with the human. And it is exactly this layer that will not be automated away any time soon: translating between the model and the system, encoding business intent, and deciding what it even means for something to be "done."

I say this as a cautious hypothesis, not a verdict, because representative Hungarian data are missing here too. For several structural reasons, this may hit harder in Hungary.

In many Hungarian teams, the platform, QA, security and architecture layers are thin to begin with, and seniors were overloaded even before AI. If we unleash an agentic coding workflow on top of this without proper limits, it does not free up the seniors; it turns their days into review hell. Smaller companies often lack formal engineering governance, while at multinationals and shared service centers ownership is fragmented, with many approval layers and offshore-nearshore interfaces. On top of that, in an uncertain labor market it is harder to send back a bad PR or say no to an unrealistic deadline. And here something becomes embarrassingly visible that was true all along: in many places, review was the hidden quality assurance, the point where an experienced person quietly fixed what the process had broken. The risk also depends on the segment. At an early-stage startup, fast iteration is a real advantage and the price of slop is low, because the code gets replaced quickly anyway. In a banking or data-heavy system, however, the same slop can live for years, and often only surfaces in production, as an incident.

As a contextual signal, the Hays report on the Hungarian labor market belongs here. It names the overload and burnout of senior professionals, and the resulting turnover, as a separate risk, alongside stagnating IT salaries. This is not representative evidence of agentic coding's impact in Hungary. But it shows well that it is precisely the layer that is already scarce, and most expensive to replace, that comes under pressure.

The solution is not an AI policy but an engineering policy. And the starting point is measurement: if we measure AI use in lines of code written, number of PRs or tickets closed, we are watching metrics that AI can trivially inflate without a single real problem being solved.

What should a team measure instead of LOC and PR count?

Cycle time: the time from idea to production deploy.

Change failure rate: what percentage of deploys cause an incident.

Escaped defects: the number of bugs that surface in production.

Review lead time and review load per reviewer.

The distribution of PR sizes and the share of "too large" PRs.

Rework / churn rate: what share of freshly written code is rewritten within a short time.

Incident count and MTTR (mean time to recovery).

Test coverage and how it has changed since AI was introduced.

The number and severity of security findings.

The share of out-of-scope (out-of-ticket) changes.

The logic is simple: part of the productivity gain has to be reinvested in quality and test coverage, and whoever generates code with AI is just as responsible for it as if they had written it by hand.

Agentic coding does not ask whether we still need developers. It asks whether there was ever a real engineering culture around the code.

Code generation has become dramatically cheaper. Understanding, validation, architecture, security and ownership have not. Where there is specification, review, testing, ownership and measurement discipline, AI is an accelerator that frees seniors from repetitive work. Where these are missing, AI does not solve the problem; it only makes it visible faster. The difference is not in the model, but in the organization that uses it. And this difference, even if it could be hidden until now, will be harder and harder to hide from here on.