A product owner asks a coding agent to add an approval step to a supplier portal. The agent produces a screen, a database migration, and an email notification. The preview looks right. What has not yet been decided is whether the person approving a supplier is allowed to see its bank details, whether an approval can be withdrawn, or what happens if the email fails after the record changes.
Those are not finishing touches. They determine what the feature means. AI-assisted software development changes how quickly a team can produce an implementation; it does not make the implementation an adequate specification.
What engineer-supervised development actually involves
“Keep a human in the loop” is easy advice to give and surprisingly easy to satisfy in name only. A developer who clicks approve on an unfamiliar change is technically in the loop. That does not mean anyone has checked the assumptions on which the change depends.
Useful supervision assigns decisions to people with the information and authority to make them. A product owner defines the approval rule. An engineer determines how it is enforced. A security specialist may review access to sensitive information. The release owner decides what evidence is sufficient before customers rely on the feature.
One person can cover several responsibilities on a small project. The important distinction is between explicit ownership and a vague expectation that someone else will catch a problem. The agent can draft implementation options and tests, but a confident explanation from the same agent is not independent evidence that either is correct.
The decisions to make before generation
Begin with a short description of the actual business operation. In the supplier example, identify who submits information, who reviews it, which fields are restricted, and which transitions are allowed. Write down at least one rejected action: a supplier must not approve its own application, for example.
Next, establish the boundaries the implementation must respect. Which system owns supplier identity? Where are documents stored? Does the application receive payment information, or only a reference to another system? Which users belong to the same customer organization? These answers affect the data model and interfaces, not just the screen.
Engineers can put this context into repository instructions, interface definitions, and acceptance criteria. That helps an agent work within the project. It is still worth checking that the resulting code respects the boundaries: an instruction saying “use the existing authorization service” is not an enforcement mechanism.
Review behavior as well as code
A readable diff can implement the wrong workflow. A passing test suite can contain tests that repeat the implementation’s mistaken assumption. Review therefore needs more than a search for suspicious syntax.
For the approval change, try requests from an applicant, a reviewer, and a user from another customer organization. Repeat a submission after a timeout. Remove a permission while a browser tab remains open. Check whether a failed notification leaves an approval in a defined state. These tests connect the business requirement to observable behavior.
Access decisions belong at a trusted boundary, not only in the interface. Hiding an approval button does not stop a direct request to its endpoint. The OWASP Authorization Cheat Sheet is a useful reference for designing and testing authorization independently of how the code was produced.
A reviewer should also inspect changes outside the requested feature. Did the agent loosen validation to make a test pass? Add a dependency the team cannot support? Put a migration into a startup path? The generated change should be small enough that someone can answer those questions before merging it.
Release ownership does not disappear
Before deployment, somebody needs to know how the database change behaves against existing records, which settings differ in production, and how to reverse the release. Rolling back application code may not reverse a destructive migration or an email already sent to a customer.
Operational checks should be proportionate. A temporary internal directory does not need the same release process as a billing service. Both need an owner, an appropriate access model, and a clear response when something goes wrong. The more consequential the application, the less reasonable it is to rely on “the preview worked.”
Logging and monitoring should answer questions the team may actually face. Can support tell why an approval was rejected? Can an engineer trace a background notification without exposing sensitive fields? Can the team distinguish a repeated request from a new business action? Those decisions are best made before an incident.
A working model for a small team
A practical starting point is one bounded change at a time. Agree on the behavior and its failure cases, ask the agent for an implementation, inspect the diff, test against independent acceptance criteria, and release through the project’s normal controls. Keep a record of architectural decisions that future changes must preserve.
Measure the result by accepted work and production reliability, not by how much code was generated. A short implementation that avoids collecting unnecessary data can be more valuable than an elaborate workflow completed quickly. Likewise, a fast first draft may create substantial review and cleanup work.
Engineer-supervised AI development is not a slower alternative to using AI. It is a way to use the tool without confusing output with responsibility. The team should be able to explain why the application behaves correctly even if the original conversation with the agent is no longer available.
Related reading
Put the right guardrails in place
SaM Solutions can assess your project, review its architecture, and help decide where AI-assisted development fits.