AI Can Write the Code. Who Reviews the Software?

For a long time, writing the code was one of the slowest parts of building software. A developer had to understand the requirement, design the implementation, write the code, debug it, test it, and then repeat the process for the next feature. AI coding agents are changing that equation quickly. They can now generate screens, APIs, database logic, tests, integrations, refactors, documentation, and sometimes entire features from a relatively small amount of instruction.

That does not mean software development has become automatic. It means one of its bottlenecks is moving. When a team can produce code faster than it can properly understand, test, and approve that code, the difficult question is no longer only “Who writes the software?” It becomes “Who is responsible for deciding whether this software is actually ready to ship?”

This distinction matters for engineering teams, but it matters just as much for founders and businesses using AI coding tools to move faster. Code generation is becoming cheaper and easier. Trusting the resulting system with customers, payments, private information, business operations, and future development is still an engineering problem.

AI coding is becoming normal software development

The shift is no longer theoretical. JetBrains' 2026 Developer Ecosystem Survey found that 90% of professional developers were using AI coding agents at work at least weekly, with 68% using them daily. The interesting question is therefore becoming less about whether professional teams will use AI and more about how development processes need to change when AI can produce significant amounts of working code on demand.

That change creates enormous advantages. An engineer can explore several implementation approaches more quickly. Repetitive code can be generated instead of typed manually. Tests and documentation can be created alongside a feature. Older code can be explained and refactored faster. A small team can attempt work that previously required considerably more time.

But more generated code also means more code that needs to be evaluated. Google Cloud's Office of the CTO has described this emerging problem directly: as AI made software creation faster, the bottleneck shifted toward reviewing and integrating the resulting changes. That is an important change in how businesses should think about AI-assisted development. Speed of generation and speed of safe delivery are not the same metric.

A working feature is not the same as reviewed software

AI coding tools are very good at producing something visible. Ask for an onboarding screen and you may have one quickly. Ask for authentication and users may be able to sign in. Ask for a subscription workflow and the payment provider may connect successfully. From the outside, this can create the impression that the difficult part is finished.

Production review asks different questions. Can one user access another user's records? What happens when the payment provider sends the same webhook twice? What happens if a database migration fails halfway through? Where are secrets stored? Can an administrator accidentally receive permissions intended for another role? Does a generated dependency introduce a vulnerability? What happens when the external API is unavailable? Can the deployment be rolled back without losing customer data?

These questions are not arguments against AI-generated code. Human-written software can contain exactly the same problems. The difference is that AI can increase the amount and speed of change dramatically. When output increases, review capacity and engineering discipline have to increase with it.

This is also why an application that looks complete can still need a deeper code and architecture review before a business should depend on it. The visual product is only one layer of the system.

The reviewer is no longer checking only syntax

The simplest interpretation of code review is that one developer reads another developer's pull request and looks for mistakes. AI-assisted development requires a broader definition. A reviewer is not only checking whether individual functions are correct. The reviewer is deciding whether a change belongs in the product, follows the architecture, preserves security boundaries, handles failure correctly, and can be maintained after the AI agent that generated it has moved on to another task.

That means effective AI-generated code review operates at several levels. The code itself matters, but the behaviour of the complete system matters more.

1. Review the requirement before reviewing the implementation

An AI agent can implement the wrong requirement extremely efficiently. That is why review should begin before code generation. Someone still needs to define what the feature should do, what it should not do, which users can access it, what data it can touch, what success looks like, and what should happen when something fails.

This sounds like product management rather than coding, and that is exactly the point. AI can accelerate implementation, but it cannot remove the need to decide what the business actually wants the software to do. If the requirement is ambiguous, the generated implementation can simply turn that ambiguity into code faster.

2. Review architecture, not only whether the feature works

Generated code often solves the task directly in front of it. A production system has to survive hundreds of future tasks that have not been written yet. Reviewers therefore need to ask where new logic belongs, whether existing components should be reused, how data flows through the system, whether responsibilities are separated correctly, and whether the implementation makes future changes easier or harder.

An endpoint can return the right result and still be placed in the wrong part of the architecture. A database query can work and still bypass a service layer where important business rules are normally enforced. A new frontend feature can behave correctly while duplicating logic that should live on the backend. These problems rarely appear in a successful demo, but they become expensive when the product grows.

3. Review authentication, authorization, and data boundaries

Security-sensitive code deserves a different level of attention. Authentication answers who the user is. Authorization determines what that user is allowed to do. AI-generated software can implement the first successfully while leaving gaps in the second.

Reviewers should check role boundaries, ownership rules, API permissions, administrative actions, protected routes, sensitive fields, storage policies, secrets, and access to third-party systems. A customer should not be able to access another customer's information simply because an automatically generated endpoint forgot an ownership check.

NIST's secure software development guidance continues to emphasize the need for human monitoring and validation around AI-generated development output. AI can participate in secure development, but accountability for the security of the released product still belongs to the organization shipping it.

4. Review dependencies and everything the agent introduced indirectly

A coding agent does not only generate source code. It can add packages, modify configuration, create environment files, update build scripts, change infrastructure settings, introduce new API permissions, or rely on third-party services. Those changes can alter the security and maintenance profile of the application even when the visible feature seems simple.

Dependency review therefore becomes part of AI-generated code review. Teams should understand why a package was added, whether it is maintained, which version is being used, what permissions it requires, and whether the same result could have been achieved with an existing dependency. The fastest implementation is not always the smallest or safest implementation.

5. Review failure states, not just the happy path

AI coding tools can create convincing happy paths very quickly. A user enters valid information, presses the button, and receives the expected result. Real applications spend a significant part of their lives dealing with everything that does not happen according to the demo.

A reviewer should think about expired sessions, duplicate requests, missing records, failed network calls, payment retries, invalid input, rate limits, API timeouts, database conflicts, unavailable services, interrupted uploads, and partially completed workflows. Tests should cover the situations most likely to damage customer trust, revenue, or data integrity rather than only proving that the feature works when everything goes correctly.

AI can help review AI-generated code, but it cannot own the decision

There is an obvious response to the review bottleneck: if AI can generate the code, why not ask another AI agent to review it? That can absolutely be useful. AI-assisted review can summarize large changes, identify suspicious patterns, suggest test cases, check style rules, look for missing error handling, compare an implementation against requirements, and help security teams analyze code faster.

Google's Mandiant has described using agentic systems for vulnerability discovery with structured analysis and human expertise built into the process. This is a useful model for AI-assisted development more broadly. The choice is not between human review and AI review. The stronger approach is to use automation where it improves coverage while keeping accountable people responsible for the final technical decisions.

An AI reviewer can tell you that a function looks risky. It cannot accept the business consequences of deploying it. It can suggest that an architectural pattern is inconsistent. It does not own the long-term cost if the recommendation is wrong. It can generate additional tests. It does not decide what level of risk is acceptable for a payment system, healthcare workflow, marketplace, or internal business platform.

The final reviewer therefore does not have to manually type the code, and may not even manually inspect every character. But somebody still needs to understand the change well enough to approve it.

The new review system needs more than one reviewer

The answer to “Who reviews the software?” should not be one exhausted senior engineer reading thousands of AI-generated lines at the end of every sprint. As code generation scales, teams need a review system.

Layer 1: Automated engineering checks

Formatting, linting, type checking, unit tests, integration tests, dependency scanning, static analysis, security checks, build verification, and other repeatable checks should run automatically. There is little value in spending senior engineering time manually finding problems that reliable tooling can reject before review begins.

Layer 2: Human code and architecture review

An engineer should evaluate whether the implementation makes sense inside the existing system. This includes data flow, component boundaries, duplication, security, maintainability, performance implications, failure handling, and whether the generated change solves the requirement in an appropriate way.

Layer 3: Product and domain validation

Technically correct software can still implement the wrong behaviour. Product owners, founders, operations teams, or domain specialists may need to confirm that business rules are represented correctly. This becomes especially important in applications where software reflects industry-specific rules instead of generic CRUD operations.

Our ALIFF case study provides a useful example of this distinction. The AI styling experience could not rely on a generic model simply producing outfits. Modesty requirements were implemented as structured rules around the AI, while quota management, caching, and streaming were engineered into the production system. The important lesson is broader than fashion technology: reliable software depends on someone defining constraints around generated behaviour and verifying that those constraints are actually enforced.

Layer 4: Production monitoring

Review does not end when a pull request is merged. Production reveals combinations of traffic, user behaviour, integrations, data, devices, and failure conditions that development environments cannot reproduce perfectly. Logging, monitoring, alerting, analytics, rollback procedures, and incident handling therefore remain part of the review system.

This is why the traditional development lifecycle still matters even when AI participates heavily in implementation. At NLS, the lifecycle remains planning, design, build, test, deploy, and maintain. AI can accelerate work inside those stages, but skipping stages because code appeared quickly creates a different problem rather than a faster process.

Smaller AI-generated changes are easier to trust

One practical consequence of agentic coding is that teams need to become more disciplined about the size of changes. An AI agent may be capable of modifying dozens of files in one run. That does not mean allowing it to do so is always the best engineering decision.

Large changes increase review difficulty. The reviewer has to understand more context, trace more interactions, recognize more unintended side effects, and distinguish important architectural decisions from routine generated code. The probability that somebody approves a large change because it looks generally reasonable increases as review fatigue grows.

A better workflow often gives the agent a narrow objective, clear acceptance criteria, explicit constraints, and a limited surface area. Generate one understandable change, verify it, integrate it, and then continue. AI gives teams the ability to move faster; it does not require them to move in larger, harder-to-review increments.

The value of senior engineers is moving toward judgment

If AI writes more code, it can be tempting to assume that experienced engineers become less important. In many teams, the opposite may happen. The value of a senior engineer has never been limited to typing syntax faster than a junior developer.

Experienced engineers recognize architectural consequences before they become incidents. They know which apparently simple changes deserve extra scrutiny. They understand when an abstraction is useful and when it is unnecessary. They can evaluate trade-offs between speed, complexity, cost, performance, and maintainability. They know when the generated solution is clever but wrong for the product.

AI can compress implementation time, which means these decisions arrive more frequently. A team that previously made five meaningful technical decisions in a week may now encounter many more because agents can explore and implement changes so quickly. The limiting resource becomes judgment.

That also changes what businesses should evaluate when hiring software teams. The question is no longer only how many developers will be assigned to the project or how quickly they can produce features. A more useful question is who owns the architecture, who reviews high-risk changes, how generated code is validated, and who remains accountable after deployment.

Some generated changes deserve more scrutiny than others

Risk-based review is more practical than treating every line of code as equally dangerous. A generated style change is not the same as a database migration. Updating copy is not the same as changing authentication. Adding an internal analytics event is not the same as modifying a payment webhook.

Teams should require additional review for authentication and authorization, database migrations, payments, subscriptions, infrastructure, credentials, third-party integrations, sensitive data handling, administrative permissions, destructive operations, public APIs, and critical business rules. Applications operating in industries with sensitive information or important operational consequences may require an even higher standard. NLS works across different software industries, and the review boundary should always reflect what is actually at risk in that product.

A practical workflow for reviewing AI-generated code

A useful AI-assisted workflow can remain fast without treating generated output as trusted by default. Before asking an agent to implement a change, define the requirement, acceptance criteria, architectural boundaries, data access, permissions, and failure behaviour. Give the agent enough context to work within the existing system instead of allowing it to invent a new pattern for every feature.

Once the change is generated, review the diff rather than judging only the working interface. Run automated checks and tests, inspect security-sensitive changes, review newly introduced dependencies, confirm database behaviour, and verify that existing functionality has not regressed. High-risk changes should receive experienced engineering review even when the generated implementation appears straightforward.

After approval, deploy through a controlled environment. Test the change against realistic conditions, monitor its behaviour after release, and make sure the team can reverse the deployment if an unexpected problem appears. Documentation should describe the final system as it exists, not depend on the prompts that happened to generate it.

This process may sound slower than simply accepting everything an agent creates. Compared with correcting production incidents, broken permissions, corrupted data, failed payments, or a codebase nobody understands, it is usually the faster path.

What founders should ask an AI-assisted development team

Founders do not need to become code reviewers themselves, but they should understand whether review exists. If a development team uses AI coding agents heavily, ask who approves generated code before it reaches production, which automated tests and security checks run before deployment, how architecture decisions are made, how permissions are reviewed, and what happens if an AI-generated change causes a production problem.

Also ask whether the team can explain the resulting system without referring back to the prompts that created it. Software ownership means the developers responsible for the product understand how it works now. “The AI generated that part” should never become the final explanation for a production system.

If you already have a product built largely through AI tools and nobody can confidently answer those questions, that does not automatically mean the application needs to be thrown away. Our guide to what happens after an AI-built app becomes difficult to trust explains how to audit an existing system and decide what should be kept, fixed, or rebuilt.

AI should increase engineering leverage, not remove engineering ownership

AI coding agents are becoming extraordinarily useful. They can reduce repetitive work, help engineers explore unfamiliar codebases, speed up prototypes, generate tests, explain complex functions, perform refactors, and turn well-defined requirements into working implementations faster than traditional workflows allowed.

The mistake is assuming that because code generation has become easier, everything that comes after code generation has also disappeared. Architecture still matters. Security still matters. Product requirements still matter. Testing still matters. Deployment still matters. Monitoring and maintenance still matter.

In fact, those disciplines may become more important because AI lets teams create and change software at a much higher rate.

The future of professional development is therefore unlikely to be humans writing every line manually or AI agents operating without oversight. It is more likely to be teams where AI handles more implementation while engineers spend more time specifying, reviewing, testing, integrating, and improving the system.

For businesses exploring AI-assisted applications, the same principle applies whether AI is inside the product or inside the development workflow: generation is only the beginning. Reliable software comes from the constraints, engineering decisions, testing, and ownership around it.

Final thought

AI can write the code. It can increasingly test some of it, explain it, refactor it, and even review parts of what another AI agent produced. That is a meaningful change in software development, and teams that ignore it may become unnecessarily slow.

But the most important question has not disappeared. Someone still has to decide whether the system can be trusted.

That person may use AI. They may rely on automated tests, security tools, static analysis, additional agents, and sophisticated development infrastructure. What matters is that the software has an accountable owner who understands the architecture, the risks, the product requirements, and the consequences of putting that code in front of real users.

The competitive advantage is no longer simply generating more code. It is being able to generate more software without losing the ability to understand, review, and trust what you ship.