How I use AI agents without handing over engineering judgment

Start with the decision the software needs to support

My experience spans financial services, enterprise accounting systems and building and selling a SaaS product. Those environments make the consequences of a misunderstood requirement tangible. An attractive interface or a passing test suite does not compensate for processing the wrong transaction.

Before implementation, I want a clear description of who needs to do what, which rules apply and what failure looks like. I turn that into examples the business owner can challenge. Agents can help investigate the problem and draft the specification, but I remain responsible for resolving the assumptions behind it.

• Read about my engineering background →

Give the agent a design and a boundary

I approach an agent task with an explicit scope: the behavior to change, the systems involved, the constraints and the evidence needed to call it complete. Architecture comes first where the decision affects data ownership, access or future maintenance. I want those choices visible, not buried in an implementation diff.

For example, a background job that updates customer records needs a retry strategy and an authority model before an agent is asked to implement the happy path. Splitting the work into reviewable changes makes it easier to spot a wrong assumption before it spreads across the system.

Separate implementation from the checks that judge it

Agents are useful for writing tests, but I do not treat a test as independent evidence simply because it was generated separately. The requirement needs its own examples. I look for checks that could fail if the implementation has misunderstood the business rule.

For conventional logic, that includes repeatable automated tests and important browser journeys. When the product itself uses AI, it also needs representative evaluation cases and a definition of acceptable output. A model can produce an answer that is well formed but unsuitable for the task. That distinction matters when choosing the checks.

• Check the requirement against the implementation, including cases that must be rejected.
• Review consequential changes such as permissions, data migrations and external actions.
• Inspect failures and the changes made to address them, rather than relying on a final success message.
• Keep approval separate from the agent’s ability to propose or implement a change.

Know when an agent is the wrong abstraction

A known business rule should usually be implemented as explicit, testable logic. An agent is helpful when there is uncertainty to investigate or a variable path to work through. I consider the cost of a wrong action, the ability to verify the result and whether a person can meaningfully review it.

Anthropic’s guidance recommends starting with the simplest suitable approach. That fits the engineering decision here: adding autonomy should solve a real problem. A fixed workflow with one AI-assisted interpretation step can be easier to operate than an agent asked to own the entire process.

• Compare agents with workflow automation →

Carry responsibility through to production

My work also includes deployment and server management. That changes what I ask during development: can the change be deployed predictably, diagnosed from logs and rolled back? Who owns the credentials and the infrastructure? Can another engineer understand how it runs?

The benefit I am aiming for is faster delivery with those responsibilities intact. A useful handover includes the code, the operating arrangements and the limits of what has been verified. AI helps produce and investigate the work; engineering judgment connects it to an outcome somebody can depend on.

• Work with James on an engineering project →
• See the production-readiness checklist →