Exhaustive code review may have become the new administrative work of software developers.
The traditional reasoning sounds impeccable.
Artificial intelligence generates the code. A human reads every line. The reviewer checks the syntax, conventions, function calls, data structures, and comments. Only then can the code be accepted.
This method reassures technical leaders. It preserves familiar practices. Above all, it creates the impression that humans remain in control.
Then a very practical problem appears: volume.
Antirez asks a deliberately provocative question: how could a developer seriously review 5,000 generated lines every day?
Time spent inspecting those lines must be taken away from design, architecture, security, performance, customer needs, user experience, or the search for failure conditions. (Antirez)
AI does not remove the work.
It reveals which activities were assigned the wrong value.
Code accelerates while the organization slows down
AI development tools can already speed up the production of certain functions.
In a controlled GitHub experiment involving 95 professional developers, the group using Copilot completed a programming task 55% faster on average than the group without Copilot.
The experiment covered a specific exercise and cannot automatically be generalized to every software project, but it clearly illustrates the potential acceleration of production. (GitHub)
A production chain does not become more effective simply because one of its machines becomes faster.
When code is generated five times faster but reviews, security validation, testing, and deployment still operate at their previous pace, an individual productivity gain becomes a collective traffic jam.
DORA’s findings illustrate this tension.
In the data studied, a 25% increase in AI adoption was associated with a 1.5% reduction in delivery throughput and a 7.2% reduction in delivery stability.
DORA points in particular to larger batches of changes that take longer to review and are more likely to destabilize systems. (DORA)
Here lies the paradox: developers may feel faster while the organization delivers less effectively.
AI amplifies an old weakness.
Many companies still measure software activity through lines of code, completed tickets, features developed, or pull requests submitted.
When production becomes abundant, these indicators reward the volume that eventually saturates the rest of the system.
Exhaustive review creates an illusion of control
Reading every line sounds rigorous.
Rigour, however, does not require giving the same attention to every detail.
An error in a display function, an error in an authorization system, and an inconsistency in a financial calculation algorithm do not carry the same risk.
Applying identical effort to all three confuses equal treatment with effective control.
Google’s published review practices recommend starting with a broad view of the change.
Does it make sense?
Is it properly described?
Is it consistent with the direction of the system?
The reviewer should then examine the most important sections and major design issues before moving through the rest of the change.
A serious architectural weakness may make the detailed analysis of many lines pointless because they will have to be rewritten. (Google Engineering Practices)
Google also states that the primary purpose of review is to improve the overall health of the codebase over time, rather than to pursue abstract perfection in every change.
Technical facts and data should take priority over personal preferences. (Google Engineering Practices)
Line-by-line review can easily drift into debates about style, naming, or personal taste while more important questions remain unanswered.
Does the software address the right problem?
Is the data model coherent?
Will the system continue to operate under ten times the load?
Are permissions checked at every critical point?
Can a partial failure contaminate the entire service?
Does the change duplicate a function that already exists?
Exhaustive review then becomes a control ceremony.
It produces many visible comments without necessarily focusing attention on decisive risks.
Control the ideas before controlling the syntax
Antirez proposes controlling the ideas contained in the software instead of treating code as the developer’s only intellectual output.
This proposal does not make code irrelevant.
It introduces a different hierarchy of control.
A software system is first a representation of a problem and a proposed solution.
Code materializes that representation in an executable language.
An elegant implementation of a flawed model remains flawed software.
The first level of control should therefore address design.
Why was this architecture selected?
Which alternatives were considered?
Where are responsibilities located?
Which compromises were accepted between simplicity, performance, cost, security, and scalability?
Which external dependencies become critical?
Which decisions will be difficult to reverse?
An AI system can produce thousands of locally coherent lines while gradually building a globally inconsistent system.
The experienced developer contributes something the model may not possess: product history, previous incidents, operational constraints, real customer behavior, compromises that have already been rejected, and risks that are specific to the organization.
That contextual knowledge becomes a central part of the work.
Define the system’s invariants
The second level consists of formalizing invariants.
An invariant is a property that must remain true regardless of the changes made to the software.
A bank account must not spontaneously create money.
A user must not access another user’s data without authorization.
A paid order must not become unpaid because a message was processed twice.
An operation replayed after a failure must not create a duplicate.
A partial update must not leave data in a contradictory state.
These properties describe system quality more effectively than a uniform inspection of syntax.
The team should therefore ask AI to produce code and also to propose tests designed to attack these invariants.
It should explore edge cases, unlikely sequences, concurrency problems, permission errors, capacity limits, and intermediate states.
The human role is to determine what must remain true.
The machine can then help multiply the attempts to demonstrate how that property might become false.
Replace exhaustive reading with multilayer validation
A more mature governance model for AI-generated code can rely on several complementary layers.
The first is functional validation.
Does the software perform the requested task?
The second is edge-case validation.
What happens with missing data, a maximum value, a slow response, a network interruption, or two simultaneous operations?
The third is comparative validation.
Can the implementation be compared with a reference version, an established library, or an independent calculation?
The fourth is performance validation.
How do memory use, response time, infrastructure cost, and stability evolve as volume increases?
The fifth is security validation.
Dependencies, inputs, permissions, secrets, data flows, and configurations must be examined with specialist tools and audits proportionate to their risk.
The NIST Secure Software Development Framework recommends explicitly integrating security practices into the development lifecycle because many development models do not cover them in sufficient detail by default. (NIST)
Automation therefore does not justify blind confidence.
It allows human control to move toward the design of validation mechanisms.
Readable code may still be dangerous
One of the most interesting risks of AI-generated code is its clean appearance.
Well-presented code with consistent naming and detailed comments can inspire confidence.
That visual fluency may conceal a reasoning flaw, a missing permission check, a race condition, or a misunderstanding of an API.
An empirical study of 733 snippets attributed to several coding assistants identified security weaknesses in 29.5% of the Python snippets and 24.2% of the JavaScript snippets studied.
The authors describe the methodology and the limits of their sample, which do not support treating these results as universal rates for all generated code.
The research nevertheless shows that apparent functional correctness and security are separate subjects. (arXiv)
GitHub has also highlighted behaviors to examine in agent-generated pull requests: weakened continuous-integration controls, removed or bypassed tests, duplication of existing functions, and code that passes tests while remaining logically wrong in certain situations.
GitHub reported that Copilot code review had processed more than 60 million reviews and that more than one in five code reviews on its platform involved an agent.
These figures come from GitHub and describe its ecosystem, but they provide an indication of the scale involved. (GitHub)
The useful reaction is not to admire the cleanliness of the code.
It is to investigate where that cleanliness might conceal a model error.
Document software as a collection of ideas
Antirez proposes another important development: dedicating more time to conceptual documentation describing data structures, architectural choices, implementation techniques, and compromises.
This documentation does not replace code.
It gives readers the mental model required to interrogate it.
A well-maintained design file should explain:
- the purpose of the component;
- its role in the wider system;
- the main architectural decisions;
- the invariants that must be respected;
- known risks;
- selected compromises;
- failure scenarios;
- elements requiring human validation;
- areas where modification is particularly dangerous.
A person joining the project can understand the intentions before becoming lost in implementation details.
AI can also use this documentation as context for producing more coherent modifications.
Code describes how the system operates today.
Conceptual documentation explains why it operates that way and which properties must survive its future transformations.
The developer becomes a systems engineer
This development shifts professional value.
Fast typing loses some of its relative importance.
Problem understanding, modeling, critical thinking, domain knowledge, architecture, constraint formulation, and the construction of validation loops become more valuable.
The developer does not disappear.
The activity moves to a higher level of abstraction.
The developer becomes the person able to:
- transform an ambiguous need into a structured problem;
- select appropriate technical compromises;
- distinguish a local optimization from a global improvement;
- define invariants;
- design tests that place the system under pressure;
- interpret results;
- detect architectural drift;
- coordinate the work of several agents;
- decide where human auditing remains essential.
The 2025 Stack Overflow survey nevertheless shows limited trust.
Forty-six percent of surveyed developers said they distrusted the accuracy of AI tools, compared with 33% who trusted them.
Experienced developers were among the most cautious respondents. (Stack Overflow)
That caution can be productive when it does not become a mechanical review of everything the machine produces.
Beginners still need to understand code
Moving control toward ideas creates a specific problem for junior developers.
How can someone evaluate architecture without having encountered poor architectures?
How can someone recognize a subtle error without understanding program execution?
How can someone define an invariant without experience of failure?
How can someone control an AI system without a mental model of the language, data structures, operating system, or network?
Learning to program therefore remains essential.
Personally writing a small interpreter, hash table, server, miniature database, or scheduler develops an understanding that passive approval of generated code does not automatically produce.
Training must nevertheless evolve.
Asking a beginner to passively read thousands of generated lines may be less useful than asking them to predict system behavior, formulate invariants, create adversarial tests, identify a poor abstraction, and explain why a proposed solution fails.
Future developers will need to learn how to write code and how to judge the systems that produce it.
New metrics for software development
When code becomes abundant, counting lines produced loses even more relevance.
Organizations could track indicators closer to actual value:
- the time required to transform a hypothesis into a validated result;
- the proportion of changes that cause an incident;
- defects discovered after deployment;
- the time required to understand and modify a component;
- the amount of duplicated logic;
- the quality of tests covering critical risks;
- recovery time after a failure;
- changes in architectural debt;
- operating cost per transaction or user;
- the system’s ability to evolve without a major rewrite.
These indicators shift attention from visible activity to achieved outcomes.
A team that writes fewer lines but builds a simpler, more reliable, and more adaptable system probably creates more value than a team that continuously feeds an enormous review queue.
Process innovation, not merely a new tool
This transformation directly illustrates the process innovation described in my book.
AI increases the speed of certain tasks, but its most interesting effect appears when the organization redesigns how those tasks are performed.
Adding a code generator to an unchanged process mainly produces more code inside the same pipelines.
Redefining design, responsibilities, validation, documentation, and metrics transforms the software production system itself.
I address this application of artificial intelligence in my book, Chapter 14.
The performance gain will therefore not come exclusively from a model that codes faster.
It will come from governance capable of controlling ideas, testing results, and auditing risks.
In this new organization, code becomes material produced in abundance.
Scarcity moves toward judgment, context, responsibility, and the ability to design the right system.
Does your organization still evaluate developers according to the amount of code they produce, or according to the reliable systems they know how to bring into existence?
I regularly dismantle obsolete metrics for intellectual work in my keynotes, workshops, and advisory work, usually before they become museum pieces.
References
- (Antirez) = https://antirez.com/news/169
- (DORA) = https://dora.dev/ai/gen-ai-report/report/
- (GitHub — productivity) = https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
- (GitHub — agent reviews) = https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
- (Google Engineering Practices — navigation) = https://google.github.io/eng-practices/review/reviewer/navigate.html
- (Google Engineering Practices — standard) = https://google.github.io/eng-practices/review/reviewer/standard.html
- (NIST) = https://csrc.nist.gov/pubs/sp/800/218/final
- (arXiv) = https://arxiv.org/abs/2310.02059
- (Stack Overflow) = https://survey.stackoverflow.co/2025/ai
