Reviewing and Testing Code

When agents produce code quickly, review and testing become even more important.

Your goal is not only to make the code compile. Your goal is to understand what changed, verify that it matches the requirement, and make the work reviewable for other engineers.

Self-review first

Before asking someone else to review agent-written code, review it yourself.

Ask the agent to summarize the diff:

Review the current branch. Explain the user-facing behavior change, the files touched, and any risks or tradeoffs.

Then inspect the diff yourself. The summary helps you navigate, but it is not a substitute for reading the code.

You can also ask the agent to give you the full branch diff:

Show me the full diff for the current branch and call out any changes that are unrelated to the requested feature.

Prepare for peer review

Agents can produce many code changes at once. That can become one large commit that is hard to review.

We recommend using small semantic commits with clear descriptions. Each commit should represent one logical unit of work so reviewers can understand what changed and why.

Cleaning up commits is boring to do manually, but agents can do it for you:

1. Build the feature freely.
2. Once everything works, ask the agent to reorganize the history into reviewable pieces.
3. The agent resets to main, reads all changes, and plans a logical commit sequence.
4. The agent validates that the final diff is identical to the original.

Verifiable goals

To help ensure correctness, give the agent clear signals for whether the code is right:

• Which tests should pass.
• Which browser flow should work.
• Which API response should change.
• Which bug should no longer reproduce.

The more checks you have, the more confidently you can delegate work to agents.

Let agents write tests

Building thorough test coverage used to take a lot of effort. Agents make test writing much more approachable.

You can ask an agent to write tests from any perspective: unit tests, integration tests, even e2e tests.

Write integration tests for the discount-code API endpoint and e2e tests for the checkout discount flow.
Follow the existing test infrastructure in `src/__tests__/`.

Good prompts for test creation:

• "Plan how to get e2e coverage for our checkout flow. Which scenarios should we cover?"
• "Set up an integration test for the payments API. Use our existing test infrastructure."
• "Which edge cases are not covered by our current tests for the discount feature?"
• "Write a regression test for the bug we fixed in PaymentService.ts."

Speed up your feedback loop

As you start working with more coding agents, the bottleneck moves to the slowest part of your development cycle: build, test, and type check.

Every agent conversation pays these costs. If your tests take 10 minutes to run, your agent cannot verify its code until 10 minutes have passed.

Ways to speed this up:

• Make your test suite faster.
• Trim your dependency tree.
• Optimize your CI pipeline.
• Reduce build time.

Tests are not proof by themselves

Passing tests do not guarantee the code is correct. Tests may check the wrong thing, or the implementation may do the wrong thing in a way that happens to satisfy the tests.

You still need to understand the code changes. If they are too large to understand at once, split them into smaller pieces and review each piece separately.

What you learned

You now understand how to deploy a new feature, debug issues, and validate changes through code review and testing. In the next lesson, you will learn how to customize agents for your team's workflow and conventions.