How I use AI agents without outsourcing engineering judgment

AI coding agents can produce code, research a repository, inspect logs, and compare several implementation paths much faster than a person working through each step sequentially. That does not make them the architect.

The difficult part of architecture is rarely producing another diagram. It is deciding what evidence matters, which uncertainty is expensive, what can be reversed, and where a product or operational constraint should outweigh technical elegance. I use AI agents to widen the investigation and challenge my assumptions. I keep those decisions explicit.

This is the workflow I use for production reviews, architecture decisions, and changes that cross product, backend, cloud, and operations.

Start with the decision, not the tool

“Review this repository” is too broad. A useful investigation starts with a consequential question:

• Can this workflow recover after a partial failure?
• Which boundary should own customer state?
• Can the team release this independently without duplicating infrastructure?
• What must be true before this AI workflow is safe enough for production?

That question defines the evidence to collect and the stopping condition. It also prevents an agent from turning a focused decision into an attractive but unnecessary rewrite.

For a future product, this becomes an Architecture Decision Sprint. For a live system, it becomes a Production Systems Review. The AI workflow supports the investigation. It does not replace the engagement model or the accountable decision.

Give the agent a real operating context

Good results depend less on a clever one-off prompt than on durable context. Repository instructions describe the architecture, build commands, quality gates, security boundaries, and actions that require approval. Reusable skills carry a particular workflow, such as a design review, PDF inspection, browser test, or release check.

In Codex, I use AGENTS.md for rules that should remain true throughout work in a repository, and skills for repeatable procedures that should load when relevant. OpenAI describes skills as packages of instructions, resources, and optional scripts for reliable workflows in its official skills documentation.

Claude Code has similar building blocks. Its documentation separates durable project guidance, reusable skills, and isolated subagents, each solving a different context problem. The useful idea is not which product has which file. The useful idea is that operating constraints should be explicit, reviewable, and close to the work.

Use independent lenses, not a committee of agreement

When the decision is large enough, I give separate agents distinct jobs. A typical set might include:

1. A system mapper that traces state, dependencies, failure paths, and ownership.
2. A production skeptic that looks for recovery gaps, hidden coupling, security assumptions, and operational blind spots.
3. A product reviewer that tests whether the proposed system actually supports user behavior and commercial constraints.
4. A delivery reviewer that checks whether the team can implement and operate the plan incrementally.

These are not five votes on the same prompt. Each reviewer needs an explicit lens and enough independence to disagree. Claude Code’s subagent documentation makes the context-isolation benefit concrete: a focused worker can investigate in its own context and return a summary rather than flooding the main decision thread.

The final synthesis is still human work. Conflicting findings are often more valuable than consensus because they expose the tradeoff that needs a decision.

Keep an evidence hierarchy

AI agents are persuasive even when the evidence is weak. I therefore separate what was observed from what was inferred.

My usual evidence order is:

1. Runtime behavior, production telemetry, and reproducible failures.
2. Executed tests and local browser or device checks.
3. Current code, infrastructure, and data contracts.
4. Maintained documentation and team explanations.
5. An inference that still needs validation.

Every important recommendation should point back to one of those levels. If it cannot, it belongs in a hypothesis or validation plan, not in the findings.

This matters especially in AI products. A strong demo says little about latency variance, fallback behavior, model cost, evaluation coverage, data exposure, or what happens when the model is confidently wrong. My production AI case study shows the kind of release, observability, and recovery controls that make the difference.

Make approval boundaries part of the architecture

An agent that can edit code, query systems, send messages, or deploy software needs the same thing any powerful automation needs: a narrow authority model.

I distinguish between read-only investigation, local reversible changes, and external actions. Reading a repository or running a local build is different from changing production data, sending a customer message, merging a pull request, or deploying a release. The latter actions require explicit authority and an inspectable result.

This is not administrative friction. It is a system boundary. The more capable the agent, the more important it becomes.

Verify where users and operators feel the result

An AI-assisted change is not finished when the diff looks plausible. I expect the normal engineering loop:

• build and type checks;
• targeted and regression tests;
• contract and migration review;
• local browser checks at desktop and mobile widths;
• console and network inspection;
• a final diff review for unintended scope;
• an explicit commit and deployment decision.

For architecture work, the equivalent is a decision record with tradeoffs, assumptions, a validation plan, and an implementation sequence. The output must help a real team act next week, not merely sound intelligent today.

What AI changes for an architect

AI gives me more investigative surface. I can trace several paths, test competing explanations, compare documentation with runtime evidence, and ask independent reviewers to attack the same decision from different angles.

It does not remove accountability. If anything, it raises the standard. Producing options is cheaper, so the value moves toward evidence quality, constraint design, verification, and choosing what not to build.

That is the part I do not outsource.

Related: A practical AI coding workflow with Codex, Claude Code, and reusable skills explains the operating layers and review gates behind this method.