How I work I build software by directing a small team of AI agents. I own the product direction, the experience and the decision to release. The agents investigate the system, implement focused changes, review one another’s work and help verify what actually reaches production.
1. Start with the person using the product 2. Turn the outcome into a bounded assignment 3. Give implementation a clear owner 4. Review from a separate context 5. Prove the complete change 6. Release into the real system An example grounded in real work I’ve built a custom process around that collaboration: one control lane coordinates the work, specialists operate within clear boundaries, and important decisions survive beyond any single conversation. Every change has an owner, a definition of success and evidence behind its release.
1. Start with the person using the product A customer request, an awkward interaction or a production issue starts the work. I describe the outcome in ordinary language: what should happen for the person using the software, and what must remain true along the way.
For visual work, I review working prototypes and make the design choice before implementation proceeds. Appearance, movement and how the product feels are part of acceptance.
2. Turn the outcome into a bounded assignment The control agent reads the existing system, checks the request against what is already there and identifies the dependencies. We agree on scope, acceptance criteria and the proof needed to make a release decision.
The scope includes consequences beyond the screen: saved work, offline behavior, permissions, data integrity, reporting and deployment order. Larger changes are divided into pieces that can be implemented and reviewed coherently.
3. Give implementation a clear owner An implementation agent works in an isolated checkout with an explicit assignment. It can make the decisions needed within that scope; broader changes come back to control.
It returns a reviewable pull request, the checks it actually ran and the gaps still open. Corrections usually return to that same owner so the work keeps its context.
4. Review from a separate context A separate agent examines the code and evidence against the agreed behavior. It looks for failures, unintended consequences and unsupported claims. The control lane reconciles those findings and sends back specific corrections.
For important guarantees, we deliberately break the implementation to check that the test notices. A passing assertion is useful only if it can distinguish correct behavior from a real defect.
5. Prove the complete change Local checks, independent review, protected CI and device checks answer different questions. We keep those results distinct and connect them to the exact version being considered for release.
When a check fails, we establish whether the problem is in the product, the test or its environment. Each additional pass needs a concrete question and evidence that could change the decision.
6. Release into the real system A release includes everything the feature depends on: frontend, backend, database changes and configuration, in the required order. I decide the timing around actual customer use, with the control lane handling readiness and sequencing.
After deployment, we walk through the product using a designated production test account and the devices relevant to the change. Monitoring and customer feedback feed the next round of work.
An example grounded in real work A retailer explained that staff often could not know why a shopper chose not to buy. The requested change sounded small: let the shopper answer on their phone.
Following that request through the product touched the staff’s finish action, the shopper’s question, offline answer recovery, configurable reasons, historical reports and database permissions. A reason could be renamed later without changing what an earlier shopper had answered. An unsent answer had to stay attached to the right visit. Staff corrections had to invalidate an old question safely.
That is the kind of work this process handles: a clear human need carried through the connected system, with review and proof at each consequential boundary.
My role runs through the whole process: deciding what matters, judging the experience, making tradeoffs and owning what ships. AI expands how much of the work I can carry through. Clear responsibilities, independent checks and durable decisions make that collaboration usable in production.
