Start with an outcome and an owned boundary
Before an agent touches code, I define the user-visible outcome, the source of truth, the part of the system it may change, and the checks that would make the result believable. A useful task is not “improve the backend.” It is closer to “persist tenant-scoped campaign drafts through the existing service boundary and prove one tenant cannot read another’s records.”
This work remains mine. The agent can inspect and implement inside the boundary, but it should not invent the product decision or silently broaden the scope.
Give the agent the repository, not a story about it
I point the agent at the real code, relevant documentation, current tests, and the exact files that establish the contract. When a decision depends on behavior, I prefer having it trace the implementation over pasting a long prompt that may already be wrong.
Good context is selective. The goal is enough evidence to act correctly, not every file in the repository. For large work, I split tasks by independent ownership boundaries so parallel work does not become parallel conflict.
Review the system change, not just the generated diff
I inspect whether the implementation used the right boundary, preserved existing behavior, and made the system easier or harder to reason about. A clean diff can still be wrong if it duplicates authority, adds a second persistence path, hides a failure, or “solves” a local symptom with a global abstraction.
I also check the claims around the work. If an evaluation uses synthetic fixtures, I say so. If a workflow proves mechanics but not live quality, I keep those evidence boundaries separate.
Test outcomes at the level where they matter
Unit tests are useful for contracts; they are not the complete proof of a product. I combine them with integration checks, persisted-state inspection, browser verification, fixture-driven workflows, and evaluation datasets depending on the system.
That approach appears across my projects: Kora has repeatable retrieval scenarios and integrity checks, KS App exercises a month of synthetic multi-company operations, and WorldBuilder verifies durable workflow, evaluation, and bounded repair mechanics offline.
Where agents help most
- Tracing an unfamiliar code path and assembling the relevant evidence.
- Implementing a clear vertical slice inside an established boundary.
- Generating test fixtures and checking many consistent cases.
- Finding mismatches across code, documentation, UI, and stored state.
- Running focused review passes for accessibility, failures, and edge cases.
What I keep accountable to myself
- The product goal and the tradeoff worth making.
- The authority boundary: which component is allowed to decide or mutate state.
- Whether evidence supports the claim being made.
- Whether the result is understandable and useful to the person it serves.
- The final review when failure could affect users, data, security, or trust.
The failure mode I watch for
The most expensive agent mistake is often not broken syntax. It is plausible work aimed at the wrong abstraction. The code runs, but a new layer duplicates something the repository already owned, a filter silently excludes valid data, or a generated metric loses its evidence boundary.
My response is to reduce the scope, return to the source of truth, state the contract plainly, and verify one complete path before increasing parallelism. Speed comes from clear ownership and fast feedback—not from creating more work at once.