AI can now write the feature.

Then AI can write the tests.

Then AI can open the pull request.

Then AI can review the pull request.

Then AI can fix the review comments.

And finally, a developer clicks:

Approve.

That workflow sounds incredibly efficient.

It also creates a very uncomfortable question:

If AI writes the code and AI reviews the code, what exactly is the human verifying?

This is no longer theoretical.

GitHub says Copilot code review now accounts for more than one in five code reviews on GitHub, and its review system can explore repository context, inspect large pull requests, review bot-authored PRs, and re-check its own findings after changes.

That can be extremely useful.

But only if we are clear about what the human reviewer is still responsible for.

Because:

AI reviewing AI-generated code is not the same thing as independent verification.

The New Development Loop

A growing number of workflows now look like this:

Requirement
   ↓
AI generates implementation
   ↓
AI generates tests
   ↓
AI opens pull request
   ↓
AI reviews pull request
   ↓
AI fixes findings
   ↓
Human approves

On paper, this looks great.

Everything has been:

• implemented
• tested
• reviewed
• fixed

So what is left for the developer?

A lot, actually.

Because every step above can share the same misunderstanding.

The Biggest Risk: Shared Assumptions

Imagine the requirement is:

A user should only receive a refund if the payment was successfully captured.

AI misunderstands that as:

A user can receive a refund if a payment record exists.

The AI then writes the implementation.

Then it writes tests.

The tests use the same interpretation.

Then an AI reviewer inspects the code.

It sees:

• clean structure
• tests passing
• correct types
• reasonable error handling

Everything looks good.

But the requirement is still wrong.

The pipeline becomes:

Wrong assumption
      ↓
Correct implementation of wrong assumption
      ↓
Correct tests for wrong assumption
      ↓
Correct review of wrong implementation
      ↓
Green CI

This is why passing tests and positive AI review are not enough.

They can verify consistency.

They cannot guarantee that the original understanding was correct.

AI Can Review Code Without Understanding Your Real Intent

This is where human judgment still matters.

An AI reviewer can often detect:

• obvious bugs
• null handling
• unsafe patterns
• missing validation
• suspicious logic
• inconsistent naming
• duplicated code
• test gaps

That is valuable.

GitHub has been expanding Copilot code review with deeper repository exploration, severity levels, and stronger agentic review capabilities.

But your actual product intent may not live inside the codebase.

It may live in:

• a conversation with a customer
• a product meeting
• a support ticket
• a legal requirement
• a business rule
• an undocumented edge case
• a decision made six months ago

The model may never see that context.

And even if you provide it, it can still misunderstand it.

That means the human reviewer has to verify something deeper than syntax.

The Developer Should Verify the Requirement First

The first question should not be:

“Is this code good?”

It should be:

“Is this solving the right problem?”

Before reviewing the implementation, ask:

• What was the original requirement?
• What behavior should the user actually see?
• Which business rules matter?
• What should never happen?
• What assumptions did the AI make?
• Are those assumptions correct?

This is requirement verification.

And it may become one of the most important developer skills in AI-assisted development.

Tests Are Not Independent If AI Wrote Them From the Same Prompt

This is another subtle problem.

Suppose you give an AI:

Build a password-reset flow.

The AI writes the feature.

Then you say:

Write tests.

Those tests are often based on the same mental model the AI used for the implementation.

So if the model forgot an important requirement, the tests may forget it too.

You get:

Implementation assumption
          ↓
Test assumption
          ↓
Both agree
          ↓
Tests pass

That is not independent verification.

It is agreement.

And agreement is not the same as correctness.

Ask Tests to Challenge the Implementation

A better approach is to change the role of the test-generation step.

Instead of:

Write tests for this implementation.

try:

Act as a skeptical QA engineer.

Do not assume the implementation is correct.

Based on the requirement, identify:
- failure cases
- abuse cases
- race conditions
- boundary cases
- invalid states
- unexpected user behavior

Then write tests that try to break the implementation.

That creates more separation between:

creator

and

critic

It is still AI reviewing AI.

But at least you are changing the objective.

The Human Reviewer Should Look for Decisions

AI is very good at examining code.

Humans should spend more time examining decisions.

For example:

Instead of asking:

Is this function correct?

ask:

Why does this function exist here?

Instead of:

Does this API return the right type?

ask:

Should this endpoint be allowed to perform this operation at all?

Instead of:

Is this query efficient?

ask:

Should this data be queried this way in the first place?

Instead of:

Do the tests pass?

ask:

Are we testing the behavior the business actually needs?

This is where developers add the most value.

Architecture Still Needs Human Attention

AI reviewers can catch many local issues.

But architecture is often about tradeoffs across the entire system.

An AI-generated feature may introduce:

• another service
• another queue
• another database table
• another cache
• another dependency
• another abstraction

Each one can look reasonable individually.

Together, they may make the system worse.

That is why the human reviewer should ask:

Does this change make the system easier or harder to understand?

That question is often more important than whether every line is technically correct.

Watch for “AI Agreement Loops”

One pattern I think teams should actively avoid is:

AI writes code
↓
AI reviewer suggests change
↓
AI author accepts
↓
AI reviewer approves
↓
Human sees green check
↓
Merge

Everything in that loop may come from models with similar assumptions.

The process looks highly reviewed.

But the independence between steps may be weak.

I think of this as an:

AI Agreement Loop

The system creates the appearance of verification because multiple stages agree.

But those stages may not be truly independent.

That is the key danger.

Green Checks Can Create False Confidence

Developers are trained to trust signals like:

Tests passed

Lint passed

Type check passed

AI review passed

Security scan passed

Those signals are useful.

But they can create a dangerous feeling:

“Everything is green, so this must be safe.”

Not necessarily.

A green pipeline tells you:

The system passed the checks you chose to run.

It does not tell you:

You chose the right checks.

That distinction matters more than ever.

A Practical Human Review Checklist

When AI writes the code and AI reviews the code, I think the developer should verify at least these 7 things.

1. Verify the Requirement

Ask:

Does this actually solve what the user or business asked for?

Not:

Does the code match the prompt?

Those are different questions.

2. Verify the Assumptions

Ask the AI:

List every assumption this implementation makes about:

- user behavior
- data
- permissions
- APIs
- infrastructure
- ordering
- timing

Then review them manually.

Hidden assumptions cause a huge number of production bugs.

3. Verify the Failure Modes

Ask:

• What happens if the network fails?
• What happens if the DB write partially succeeds?
• What if the request is repeated?
• What if the external API times out?
• What if two requests happen simultaneously?
• What if the input is technically valid but unexpected?

Happy-path code is easy.

Production failures live outside the happy path.

4. Verify the Blast Radius

If this change fails, what breaks?

One component?

One customer?

All customers?

Payments?

Authentication?

Data integrity?

A change touching a critical path deserves more human attention than a small UI change.

5. Verify the Architecture

Ask:

• Did the AI add a new abstraction?
• Did it introduce another dependency?
• Did it duplicate existing functionality?
• Did it bypass an existing architectural boundary?
• Did it make the system harder to reason about?

Correct code can still create bad architecture.

6. Verify the Tests

Do not only read whether tests pass.

Read what they actually test.

Ask:

If the requirement were wrong, would these tests notice?

If the answer is no, you need better tests.

7. Verify That You Can Explain the Change

This is my final rule.

If someone asks:

“Why was this implemented this way?”

you should have an answer better than:

“The agent generated it and Copilot approved it.”

If you cannot explain the change, you are not ready to own it.

Use Different Agents for Different Roles

One useful pattern is to deliberately separate roles.

For example:

Agent 1 — Implementer

Implement the requirement using the existing architecture.

Agent 2 — Adversarial Reviewer

Assume this implementation contains subtle bugs.

Try to find:
- incorrect assumptions
- security problems
- failure modes
- race conditions
- architectural problems

Agent 3 — Test Designer

Ignore the existing tests.

Design tests directly from the original requirement.

Human

Verify:

Did all three understand the actual problem correctly?

Multiple agents do not replace human review.

But role separation can reduce simple agreement loops.

Review the Requirement and the Diff Together

One practical habit helps a lot.

Do not review a pull request with only the code visible.

Keep the original requirement next to it.

For every significant change, compare:

Requirement
     ↕
Implementation
     ↕
Tests

These three should agree.

If only:

Implementation ↔ Tests

agree, you may still have a perfectly tested wrong feature.

Ask AI to Explain Before Asking It to Fix

Suppose the AI reviewer finds a problem.

Avoid immediately clicking:

Apply suggestion

Instead ask:

Explain:

1. Why this is a problem.
2. What real-world failure it could cause.
3. What assumptions the current implementation makes.
4. Why your proposed change fixes it.
5. What new risks your fix introduces.

Now you are reviewing reasoning, not just accepting another generated diff.

That helps maintain ownership.

AI Review Should Increase Human Leverage, Not Remove Human Judgment

I am not arguing against AI code review.

Quite the opposite.

AI review can be extremely useful.

It can catch issues humans miss.

It can reduce repetitive review work.

It can inspect large changes quickly.

It can help teams focus attention where it matters.

But the goal should be:

AI checks mechanics
+
Human checks meaning

Not:

AI writes
+
AI tests
+
AI reviews
+
Human clicks approve

That second workflow may be fast.

But eventually the developer becomes little more than the final button in an automated pipeline.

And that is dangerous.

The Human Role Is Moving Up a Level

The developer's value is gradually shifting.

Less time may go into:

typing syntax

More time may go into:

understanding requirements

designing systems

challenging assumptions

verifying behavior

evaluating risk

debugging failures

making tradeoffs

taking ownership

That is not the disappearance of software engineering.

It is software engineering becoming more about judgment.

The Question I Now Ask Before Approving AI Code

I used to ask:

“Does this code look correct?”

Now I think the better question is:

“What do I know that the AI systems in this loop might not know?”

Maybe it is:

• customer intent
• historical context
• production behavior
• an undocumented dependency
• an organizational constraint
• a previous incident
• a business rule

That missing context may be the most important part of the review.

Final Thought

We are quickly approaching a workflow where AI can:

write the code

write the tests

review the code

fix the review

and maybe even:

merge and deploy it

That does not make human verification less important.

It changes what humans need to verify.

The developer's job is increasingly not to check whether every semicolon is correct.

It is to ask:

Did we build the right thing?

Are the assumptions correct?

Do we understand how it can fail?

Can we explain why this design exists?

Are we willing to own the consequences?

Because if AI writes the code and AI reviews the code, the most valuable thing the developer can provide is something neither system automatically guarantees:

Independent judgment.

AI can review the implementation.

The developer still has to review reality.