Writing code is one part of engineering. Choosing which behavior to change, understanding the system that surrounds it, and accepting the consequences of a release are also engineering work. AI assistance can help produce an implementation. It does not accept responsibility for the result.
For a technical leader, the useful question is therefore operational: who understands this change well enough to approve it, and what evidence supports that approval?
Assign an owner before generating an implementation
Start a task with a named engineer and a product decision-maker. The engineer owns the technical result. The product decision-maker confirms that the requested behavior serves an actual need. On a small team, one person may hold both roles, but both decisions still need to happen.
Consider adding a retry button to a failed payment screen. A short request can conceal several decisions: whether the original request might have succeeded, how duplicate charges are prevented, and what the customer sees while the status remains unknown. Generating a button is easy. Deciding what retry means requires knowledge of payment state and business rules.
Write the invariant first: a retry must not create a second charge for the same purchase. Then record the relevant state transitions, the authority for payment status, and the behavior when that authority is unavailable. This gives implementation and review a shared target.
Keep architecture decisions visible
An assistant working from nearby files may reproduce a local pattern that conflicts with the wider architecture. Before implementation, identify the boundary the change belongs to. Does a business rule live in a shared domain service, an API handler, or the interface? Which component owns persistence? What contract do other consumers depend on?
For the payment example, duplicate prevention belongs at the authoritative transaction boundary. Disabling a browser button can improve the experience, but it cannot establish that invariant across devices or repeated network requests.
A brief architecture note should describe the chosen boundary and the alternative rejected for a concrete reason. It need not become a long document. A paragraph in the pull request can explain why an idempotency key is tied to a purchase rather than generated anew on every click.
Review generated code as an engineering proposal
Create a Git branch for a bounded change. Ask for the smallest implementation that satisfies the acceptance criteria. Review the diff before accepting extra abstractions, dependencies, configuration changes, or unrelated formatting.
Read the code along a failure path as well as a success path. For a retry flow, follow a request that times out after the payment provider accepts it. Then follow two requests arriving concurrently. Check whether error handling preserves enough information to recover without exposing sensitive payment data in logs.
The reviewer should be able to explain the behavior without referring to the assistant’s confidence. If nobody can explain a new abstraction, simplify it or investigate it before merge. A fluent explanation accompanying the patch is a hypothesis to check against the code.
Demand independent evidence
Tests generated alongside an implementation may repeat its assumptions. Start some tests from the invariant and the public contract instead. In the example, submit the same purchase twice, simulate an ambiguous timeout, and verify that transaction state remains consistent.
Use different checks for different risks:
- Type checking catches incompatible interfaces, but cannot establish that a charge occurs only once.
- Unit tests exercise state transitions and boundary conditions cheaply.
- Integration tests check persistence constraints and provider contract handling.
- A browser test confirms that customers receive clear feedback and cannot accidentally start an unrelated purchase.
Record which checks ran and which risks remain. A passing suite is evidence about the cases it covers. It does not resolve an untested concurrency assumption.
Approval extends beyond the merge button
The pull request should identify the behavioral change, the evidence, the release mechanism, and the recovery plan. For a payment change, recovery might mean disabling the new retry path while preserving transaction records for reconciliation. Reverting application code alone may not undo external side effects.
After release, the owner verifies the intended production behavior using an approved test account or controlled transaction. Inspect relevant errors and state transitions. Define what would trigger rollback and who makes that call before the release begins.
Production access and customer data require deliberate boundaries. Give automation only the access needed for its task. Keep credentials out of prompts and repository files. Treat instructions found inside external content as input to assess, not authority to expand the task.
Make accountability observable
A useful delivery record connects the original problem to a branch, a reviewed pull request, test evidence, and production verification. That record lets another engineer answer why the system behaves as it does and what to do if it fails.
Evaluate AI assistance through that complete workflow. If implementation becomes quicker but reviews become opaque or releases lose clear ownership, the process needs adjustment. The standard remains straightforward: a human team can explain the change, show its evidence, and take responsibility for operating it.