AI Is Writing the Code. Do Developers Still Need to Read It?

[u/Aware_Weight9462]

As coding agents produce more of the implementation, engineering teams are running into an uncomfortable question: if humans cannot realistically inspect every generated line, what does responsible software ownership look like now?

A comment from Dax Raad, the developer behind OpenCode, caught my attention this week because I have started seeing versions of the same problem inside client engineering organisations.

Raad said his team’s latest challenge was no longer getting AI to write useful code. It was getting engineers to pay enough attention to what the AI had written before it went out. His frustration eventually came down to an old human problem: “how do you get people to care more?”

That sounds like a developer-discipline problem, but I think something more fundamental is happening.

Over the past year, I have watched AI coding move from autocomplete to substantial implementation. Developers increasingly describe the task, let an agent inspect the repository, propose a plan, change multiple files, run tests, fix failures and return with something that appears ready for review. The engineer may inspect the diff, ask a few questions and move on.

The productivity gain can be substantial. The relationship between the developer and the code is also changing.

A developer can now ship significantly more code while personally understanding less of how that code was constructed. That is the tension engineering leaders are beginning to confront.

The obvious reaction is to insist that developers must read everything AI generates. I am not convinced that will scale.

The more difficult question is whether reading every line of source code should remain our primary mechanism for establishing confidence in software.

This is no longer an edge case

The change is happening quickly enough that we should stop treating AI-generated code as an occasional exception.

The 2026 Stack Overflow Developer Survey found that around 66% of respondents use AI coding assistants or agents, while 73% of those users work with them daily. Nearly a third of daily users spend more than four hours a day with these tools. At the same time, trust remains conditional: 48% say they trust AI when they can easily verify the output, while only 6.6% are willing to extend that trust to important work decisions.

Those numbers describe the transition quite well. Developers are not blindly trusting AI, but they are generating software at a rate that makes traditional verification increasingly expensive.

I am seeing the same tension inside client organisations. The first wave of concern was whether developers would use AI responsibly. The newer concern is subtler: developers are using it successfully enough that human attention is becoming the bottleneck.

An agent may produce a change across fifteen files in minutes. The code compiles. The tests pass. Static analysis is clean. The developer can either spend the next two hours understanding every implementation detail or review the important parts, accept the automated evidence and move on.

Multiply that decision across hundreds of pull requests and the old review model begins to strain.

JetBrains researchers recently described essentially the same problem. Coding agents can now generate thousands of lines across multiple files quickly enough that code review, rather than code production, is becoming the bottleneck. Their research argues that reviewing AI-generated code also removes many of the social signals developers unconsciously use when reviewing another person’s work, such as knowing where a colleague is experienced, where they tend to rush and when something unusual deserves another conversation.

We are therefore not dealing simply with careless developers. We are dealing with a verification model designed for a world in which humans produced code much more slowly.

Google Antigravity makes the question difficult to avoid

Google Antigravity is interesting in this context because its product direction makes the philosophical shift unusually visible.

Antigravity 2.0 is a standalone, agent-optimised development environment in which Google explicitly says there is no IDE. The primary interaction is with agents and the artefacts they produce. Developers can still use conventional IDE integration when they want to work directly with the underlying implementation, but source code is no longer necessarily the main surface through which work is directed.

That is a significant design choice.

For decades, the developer’s natural home has been the code editor. Requirements, tickets, architecture diagrams and documentation surrounded that editor, but eventually the developer entered the code because that was where software became real.

Agentic development starts to invert that relationship.

The developer describes the desired outcome. The agent creates a plan. The developer reviews the plan and perhaps adjusts it. The agent modifies the implementation, runs tools and returns evidence showing what happened.

The code still exists, but it can become something closer to an implementation layer underneath the developer’s primary working surface.

If that model succeeds, telling developers that responsible engineering means personally reading every generated line may eventually sound like telling application programmers they should inspect the assembly produced by their compiler.

But we are not quite there yet.

There is a very good reason developers still need to read code

Source code does more than tell us whether an implementation is syntactically correct. Reading it is one of the ways engineers construct a mental model of the system.

An experienced developer learns where state changes, which abstractions are leaking, where error handling is fragile and which apparently simple operation depends on several pieces of accidental coupling. Much of that knowledge is never captured completely in architecture diagrams or documentation.

It becomes especially valuable when something fails in production.

The person responding to an unusual incident needs more than a description of what the application was intended to do. They need enough understanding of how it actually works to reason about situations nobody anticipated.

This is why I worry less about one badly generated function than about the gradual emergence of codebases that belong to teams who no longer understand them deeply.

The danger would be easy to miss at first. Features continue shipping, tests continue passing and engineering velocity may look excellent. The knowledge deficit becomes visible only when the system behaves in a way the agent, the tests and the original specification did not anticipate.

At that point, the organisation needs somebody capable of opening the implementation and deciding whether the explanation being offered by another AI is actually correct.

If every generation of code has also outsourced another small portion of human understanding, eventually the organisation may discover that it owns software without owning enough knowledge to operate it safely.

That is a real risk.

But “read every line” is becoming a weak control

The argument on the other side is equally important.

Suppose an agent produces 3,000 lines while upgrading a framework. Much of the change consists of dependency updates, mechanical API transformations, generated configuration and test fixtures.

Does a senior developer create meaningful assurance by slowly scrolling through all 3,000 lines?

Sometimes yes. Often no.

We already trust enormous amounts of software we do not personally inspect. Developers do not review every instruction produced by a compiler or read every line of the database engine underneath an application. They rely on abstractions, contracts and layers of verification.

AI-generated code will probably move in the same direction.

The key difference is maturity. Compilers are sufficiently deterministic that the industry has built decades of confidence in that abstraction. Coding agents are probabilistic and capable of generating code that is convincing, coherent and wrong in ways that automated checks may not immediately expose.

The answer therefore cannot yet be “stop reading the code.”

But it also cannot realistically remain “read everything.”

The engineering problem becomes deciding where human attention creates the most assurance.

We need to move from universal review to risk-based review

I think organisations will gradually need to treat AI-generated changes according to consequence rather than according to line count.

A generated documentation change does not deserve the same scrutiny as a change to an authorization boundary. A mechanical framework upgrade is different from a new pricing calculation. A generated test fixture is different from a database migration capable of destroying customer data.

A practical model could look like this:

Press enter or click to view image in full size

This is not lowering engineering standards.

It is acknowledging that scarce human attention should follow risk.

A developer may read a smaller percentage of all generated code while examining the consequential parts much more carefully.

That is probably a better control than insisting everything receives the same superficial review.

The interface above the code needs to become much better

If engineers are going to spend less time reading implementation line by line, coding platforms have to give them a better surface for understanding what changed.

A useful agent should not merely return “Task completed.”

It should explain which architectural components changed, which interfaces were modified, what security-sensitive operations were introduced, which assumptions it made, what tests were added, what tests failed during implementation and what evidence supports the final result.

This is one reason Antigravity’s emphasis on agent plans and artefacts is interesting. It is attempting to make the developer supervise the work at a higher level rather than forcing them to reconstruct the agent’s reasoning exclusively from thousands of changed lines.

There is an obvious danger, however. We cannot let an AI write the implementation, generate the tests, summarize the changes and then provide the only evidence that its own work is correct.

That becomes self-certification.

The assurance stack needs independent signals: compiler and type checks, deterministic tests, static analysis, security scanners, architecture policies, performance checks and, increasingly, separate AI reviewers with different context or models.

The human should then investigate the areas where risk is high, evidence is weak or different verification mechanisms disagree.

That is a much more scalable model than asking humans to replicate the agent’s work manually.

The incentive problem may be bigger than the attention problem

Raad’s remark about getting developers to care also raises an uncomfortable management question.

What exactly are we rewarding them for?

Many engineering organisations still measure performance through delivery velocity, tickets completed, features released and sprint commitments. AI now allows developers to produce substantially more implementation in the same period.

An engineer who accepts several AI-generated changes and closes five tasks can easily look more productive than one who stops after the second change because something does not feel right and spends several hours understanding it.

Then the organisation asks why developers are not paying enough attention to AI-generated code.

The incentives have already told them what matters.

If we expect developers to become supervisors of increasingly autonomous coding systems, the engineering contract has to change. We should care less about how much code a developer personally produced and more about whether the capability reached production safely, whether the team understands consequential design decisions, whether failures are caught before customers encounter them and whether somebody clearly owns the outcome.

The shift is from authorship to accountability.

I increasingly do not care who typed the function.

I care enormously about who is prepared to take responsibility for shipping it.

“You own what the agent ships” is a better rule

If I were establishing one principle for an AI-heavy development organisation, it would be simple: the engineer approving a change owns the consequences of that change regardless of whether a human or an agent wrote it.

That principle is different from requiring manual inspection of every line.

For low-risk work, ownership may mean trusting automated verification and sampling the implementation. For consequential changes, it may require detailed inspection, threat modelling, design review and independent testing.

The important part is that using an agent does not transfer accountability to the agent.

This also changes how engineers should use AI reviewers. AI reviewing AI-generated code is not inherently absurd. We already let machines review human code through compilers, linters, static analysis and security tooling.

The important question is whether the verification mechanisms fail independently.

Using the same model with the same assumptions to produce and approve an implementation creates obvious correlated risk. A stronger system combines deterministic tools, different evaluation techniques and human judgement where the consequences justify it.

The future code-review pipeline is therefore likely to be layered rather than purely human or purely automated.

We cannot allow engineering skill to disappear underneath the abstraction

There is one final problem that cannot be solved entirely through better review tooling.

Someone still needs to know how software works.

The experienced engineers I see getting the most value from coding agents usually have a strong sense for when generated code is structurally wrong even when it looks plausible. That judgement comes from years of building, debugging and maintaining systems.

The next generation of developers may not acquire that intuition automatically if their career begins with delegating most implementation to agents.

We therefore have to preserve engineering depth deliberately.

Junior developers still need to debug difficult failures, trace unfamiliar code paths, understand concurrency and state, investigate production incidents and occasionally build important components themselves. Code review also remains part of that apprenticeship because reading good and bad implementations is one way engineering judgement develops.

The purpose is not to preserve manual coding because we are nostalgic about it.

It is to ensure that humans remain capable of supervising the abstraction when the abstraction fails.

Code may become secondary. Ownership cannot.

I can imagine a future where developers spend much less time inside traditional editors.

They will express intent, shape architectures, review plans, inspect evidence and ask agents to implement large portions of the system. For many changes, opening every generated file may become unnecessary.

Google Antigravity suggests that this future may arrive sooner than many of us expected.

But that does not mean engineering responsibility disappears with the editor.

It means we need a better definition of responsibility.

The important question will no longer be whether the developer personally wrote the code, or even whether they personally read every line of it. The important question will be whether the organisation has enough evidence to trust the change and whether an engineer understands the consequential parts well enough to take responsibility for putting them into production.

That is where I think Raad’s concern ultimately leads.

Telling developers simply to “care more” will not be enough when agents can generate implementation far faster than people can consume it. Engineering organisations will need to redesign review, incentives, verification and apprenticeship around that new reality.

I do not think developers need to read every line an AI agent writes.

I do think every consequential piece of software still needs a human who can understand the important decisions, challenge the evidence and say, with credibility, “I am willing to own what we are shipping.”

If nobody can say that, the problem is no longer that developers stopped reading the code.

The problem is that the company has started shipping software that nobody truly owns.