Pre-AI Processes for a Post-AI Generation

AI is changing how quickly we can produce code. Our review processes have not changed at the same pace.

I recently had a conversation at work about this gap. Some developers are adopting AI across the development process. Others are more cautious, especially when a pull request contains code that the author cannot explain. That raised a question: what should we expect from a developer submitting AI-assisted code?

For me, the answer starts with responsibility. The person submitting the PR owns the result, regardless of who typed the code. AI-generated code can contain bugs, security issues, and poor design choices. Human-written code can too. The review standard should be the same when a tool helped produce the code.

What does it mean to explain a PR?

It does not mean memorising every line. A developer does not need to justify the name of every variable or spot every unused import from memory.

They should understand the purpose of the implementation and the decisions that shape it. They should be able to explain choices such as the data structure being used, whether an operation should be synchronous or asynchronous, why a cache or retry exists, and what complexity to expect. They should know which edge cases the tests cover and where the solution might fail.

The sequence of prompts and inputs can help explain how the code was produced. It cannot replace understanding the code. If an author can describe the prompt but cannot explain what the implementation does, the review still has a gap.

The review depth should match the work

The same responsibility applies to every PR. The amount of review should depend on how long the code will live and what it can affect.

A disposable experiment can be judged mainly by its intent, its result, and the evidence that shows whether it works. It may be reasonable to spend less time on naming, style, and future extensibility when the code will be thrown away.

That decision changes as soon as the experiment becomes part of a product. Before reusing it in production, the team should review it against the standards for long-lived code.

Long-lived production code has to meet the team’s minimum quality standards. Someone will need to debug it, extend it, and inspect it when an edge case appears. Complexity, security, performance, design decisions, and maintenance costs matter.

This is where code review becomes more useful than a style check. The question is whether the implementation is appropriate for the life it will have.

We need risk-based review

AI makes it possible to produce more code than a team can read with equal attention. Teams cannot give every PR the same process.

Teams could classify changes by risk. Low-risk changes with good automated coverage might move through a lighter approval path. Changes that affect data, security, payments, or core architecture would need deeper human review.

That model only works when the evidence is strong. Unit, integration, and end-to-end tests provide part of it. Performance, load, and stress tests matter for the systems where those risks are relevant. Automated checks can help classify a change, but they do not remove the need to define the criteria.

Give the tools enough context

AI works better when the application gives it clear boundaries. Each team should document the rules that matter to its codebase: conventions, security requirements, testing strategy, commit format, linting, and architectural constraints.

These rules provide the context a model needs. They also make expectations clearer for developers who are still learning how to use AI well.

A cross-team working group can help with this transition. It can map the most common uses of AI, compare practices, create a baseline, and help teams that are less comfortable with the technology. Adoption without guidance leaves people to invent their own standards, which makes collaboration harder.

Software engineering still depends on judgement

AI has lowered the cost of trying different implementations. That creates more room to compare options, question assumptions, and test alternatives. It also raises the value of judgement.

The work is moving away from typing every line and towards describing intent, checking evidence, understanding trade-offs, and taking responsibility for the system that reaches production.

The useful decision is more specific: what evidence does a particular change require, what must the author understand, and how much risk is the team willing to accept?

Our tools have changed quickly. The processes around them need to catch up.