How I use AI agents to build and verify software

Start with a change someone can accept

My tickets carry the plan, acceptance criteria and verification steps. A useful ticket says what should change for the user, what is outside scope and how we will know the work is complete.

I use Claude for investigation and planning, with Codex providing a second opinion. The point is to surface missing cases or a simpler approach before implementation. I assess the feedback on its merits and keep review rounds bounded; unresolved judgment calls come back to me.

This is also where product clarification matters. An agent can implement an ambiguous request convincingly. It cannot decide on behalf of a business what the request should have meant.

Give each agent a bounded piece of work

I use isolated Git worktrees so changes can progress separately. Each task has a defined scope and a clear handoff. Isolation helps keep edits separate, but it does not settle shared architecture decisions or prove that the pieces will work together.

Permissions belong in that boundary too. Implementing a local change and taking an external action are different responsibilities. I keep consequential actions under explicit control and review the combined result before accepting it.

Review the change, then exercise the journey

Independent agent review and CodeRabbit provide additional scrutiny. Focused tests and service checks give evidence about the implementation. I also check the surrounding contract: documentation, schema changes and configuration can be part of whether a feature actually works.

For AI products, I use evaluations and end-to-end tests to examine behavior across a workflow. A response can sound plausible while the system takes the wrong next step. The useful questions include whether the conversation reaches the right state, whether the right service is called and whether the expected data is persisted.

The lesson is about coverage across boundaries. A passing component test supports a specific claim about that component. A successful user journey needs evidence about the connections between components as well.

Spend CI resources on useful verification

My CI improvements combine better hardware providers, optimized workflows and conditional test suites during pull requests. The aim is to run the checks relevant to a change and avoid repeating work that no longer helps assess the current revision.

Subsequent commits deserve particular attention. When a new commit supersedes an earlier revision, obsolete runs should not continue consuming resources unnecessarily. Workflow triggers, dependencies and cancellation behavior need deliberate design.

Conditional testing also needs care: shared code and cross-service changes can affect more than one area. A faster pipeline is useful only if it still provides the evidence needed to accept the change.

Keep acceptance a human responsibility

I distinguish between code being written, checks passing, a change being deployed and the intended behavior being observed in production. Those are different kinds of evidence.

At acceptance, I ask whether the change solves the original problem, whether its important boundaries were exercised and what remains uncertain. AI agents help me do more of the work. Responsibility for the decision stays with me.

This is the engineering capability I want a team to develop: people who can define the work clearly, use agents effectively and judge the result with evidence.