AI Writes Code Fast—Can You Still Explain the Choices It Made?

Core Problem: Code Completes, Judgment Doesn't

Addy Osmani's article highlights a shift: as models improve, obvious errors decrease and developers stop questioning generated code. The code passes tests and looks clean, but the human may not have experienced the "I was wrong" moments that build judgment. The article argues that delivery speed shouldn't come at the cost of understanding why the code works and what it assumes.

Example: Transaction Order and Message Sending

A hypothetical 600-line change moves the message-sending call a few lines. If the message is sent before the database transaction commits, the downstream service may query an order that doesn't exist yet. If sent after commit, the order exists but the message might fail to send. Both sequences can pass normal tests; the difference appears only under failure. The reviewer must ask: does this change alter conditions other services depend on? Is failure easily recoverable?

Review Strategy: Predict Then Verify

Before reading the diff, state your expectation. For the post-commit send example, a reviewer might expect "interface errors mean the order wasn't created." Walking through the three steps (commit order, send message, return success) reveals that a send failure throws an exception after the commit, so the order persists while the interface returns an error. If the caller retries without idempotency, duplicate orders can appear. This prediction-then-verification loop surfaces the mismatch between interface result and actual system state.

Testing: Expectations from Requirements, Not Implementation

Comments from Dave and Alex warn that tests and implementation may share a flawed premise. If the requirement is "notify downstream after order commit," a test that only mocks the send function and checks call count cannot verify the order was committed first. Two concrete checks are proposed:

In the test environment, make the send call throw before the message leaves; then verify both the interface response and the database record to confirm whether the order exists when the interface errors.

If the requirement states "retry with same request ID must not create duplicate orders," invoke the endpoint twice with the same ID and assert only one order exists. The expectation comes from this requirement , not from what the implementation happens to do.

These checks don't guarantee message delivery; they clarify what is and isn't covered. The reviewer must know which rules the expectations derive from and what remains unchecked.

Training Junior Developers: Small Decisions, Visible Consequences

Anthropic's January 2026 experiment with 52 Python-experienced engineers learning the Trio async library found that the AI-assisted group scored 50% on a post-test versus 67% for the hand-coding group, with the largest gap in debugging tasks. Time-to-completion showed no statistically significant difference. This suggests that receiving working code and learning to handle its problems are distinct.

To build judgment, juniors should make a small choice and see its consequence. Using the order example: have them write the expected interface and database state on send failure, then add a test to verify. When the test fails, trace the code to find the mistaken assumption. Agent can point to relevant files and explain transaction behavior, but the junior must re-articulate what was wrong and why the judgment changed. Another exercise: implement a tiny piece like input validation or a state transition, clarify the contract, write normal and failure cases, and let the agent suggest missing checks.

Documenting Trade-offs: What Was Guaranteed, Why Chosen, What's Unresolved

Code shows what the system does; it doesn't record why the team accepted a certain failure mode. Without a record, future changes can't distinguish between changed conditions and overlooked risks. The article recommends keeping a few sentences per change: what was guaranteed, why this approach was chosen, and what problems remain open. For the order example, the review note could state: "Verified that on send failure the order persists; duplicate-order-on-retry not yet confirmed; need to align with interface retry contract. Implementation and test locations: ..." This isn't a full design doc but lets the next maintainer know what has evidence and what is still conjecture.

Business decisions like whether notification delay is acceptable or occasional missed notifications are tolerable cannot be inferred from code. Agents can compare options and explain costs, but the team's risk tolerance must be recorded separately.

References

Addy Osmani, Critical thinking when agents do the work (https://x.com/addyosmani/status/2117512471930167377)

Original post comments: Emanuele (@EmanueleUngaro_), Dave (@Dave_Joe_9377), Alex Torres (@alextorres_dev), Mitttt (@404Miten)

Anthropic, How AI assistance impacts the formation of coding skills, 2026-01-29 (https://www.anthropic.com/research/AI-assistance-coding-skills)

Judy Hanwen Shen, Alex Tamkin, How AI Impacts Skill Formation, arXiv:2601.20245 (https://arxiv.org/abs/2601.20245)

Simon Willison, Linear walkthroughs (https://simonwillison.net/guides/agentic-engineering-patterns/linear-walkthroughs/)

Present: A Code Walkthrough (https://github.com/simonw/present/blob/main/walkthrough.md)