The Process Became the Work

While building a solo product with an AI agent, I kept adding safeguards. Types, contracts, browser tests, architecture rules, database boundaries, manual QA, observability, and review loops each addressed a real failure. Together, they formed another system around the product, with its own ways to fail.

I could change the workflow as quickly as the code. That made one pattern easy to see: adding a useful safeguard was easy; removing one took a deliberate decision. The safeguards could become their own success criteria. A green pipeline could stand in for product quality, reviews could keep producing audit records without reaching a decision, and rules could survive after the risks they addressed had changed.

I had to decide how much evidence was enough for the risk, what it cost to collect, and when to stop.

Proof had to match the claim

Green CI could not prove interaction quality. My workflow did not always require a visual pass, a check on a real device, or focus validation, so automated evidence could become the default definition of done.

I started asking what I was claiming and what evidence could prove me wrong. Different claims needed different checks:

• Static and contract checks cover types, deterministic behavior, dependencies, and schema invariants.

• Browser and automated accessibility checks cover implemented user journeys and part of the accessibility surface.

• Manual QA covers motion, audio, focus, real devices, and interaction feel.

• Semantic review and user evidence address ownership, lifecycle, authority, completeness, and whether the product creates value at all.

This shaped the development workflow around the agent: changes went through pull requests, CI checks depended on the paths changed, and architecture and database boundaries had executable checks. I also added browser and accessibility coverage, Manual QA classification, and observability. At one point, the merge path for this side project became stricter than the one used by some production teams, which is slightly ridiculous.

AI is good at producing fixtures, tests, classifiers, scripts, and review evidence. Deciding whether that evidence is sufficient needs judgment beyond the agent that produced the work. So does deciding whether a policy can be enforced by code.

I tried to turn a rule about global browser-state access in reusable components into a source guard. Two implementation attempts showed that it would either miss aliased access to browser globals or reject legitimate local values with the same names. I removed the guard and the documentation claim that said the control existed.

The documentation checker that shipped has a narrower job: file structure, links, compatibility anchors, and bounded growth. The repository can check those deterministically. Lifecycle meaning, implementation status, and authority still need semantic review.

All of this takes review time, CI minutes, and test maintenance. A quality gate can also become a ritual. Each check needs a defined scope and criteria for retiring it.

When the reviews kept going

In August, I audited the SDLC across 100 first-parent commits over two weeks. I looked for written rules without technical controls, privileged tools with too much authority, and processes that created the appearance of safety without providing it.

The audit led to protected main, required checks, automatic branch cleanup, and clearer executable architecture and database boundaries. It also set a direction toward least privilege for privileged connectors.

In 16 days, AGENTS.md grew from 191 to 514 lines. Much of the new text concerned documenting and reviewing changes. Median pull-request lead time barely moved, but the slow tail more than doubled. That median hid how much less predictable complex changes had become.

One small documentation-only pull request, with a +123/−2 diff, generated 11 successive audit records. Each invalidated the previous one. Some rounds found real issues; the rest kept the review mechanism running. Completing the audit trail had become the criterion for success.

I reset the governance model. AGENTS.md fell from 514 to 347 lines. Later governance edits brought it to 350, before a separate context-architecture pass reduced the root file to 91.

I retired the whole-contract audit machinery and the change-budget gate. I also limited the review loop to one review batch, one remediation batch, and one re-review. After that, the owner had to decide what happened next.

For new rules, I added this constraint:

A new process rule can be added only when it replaces or removes an existing one.

The review limit was tested almost immediately. A large implementation batch hit another valid blocker on re-review. I closed the pull request without merging it or starting another review round. I then recovered the work in much smaller, independent branches, each based on a fresh main.

I cut costs elsewhere too. Playwright E2E came out of the routine pre-push path. I retired remote CI for the development-only design catalog and made the full local catalog an opt-in diagnostic.

What I still decide

AI can inspect the repository, propose how to break up the work, and write code, migrations, tests, documentation, and review findings. Clear boundaries let it take on more of that work.

I still have to define the claim, decide what evidence could disprove it, and judge the remaining risk. I also have to decide when another review would no longer change the next decision. The agent does not decide that its own tests are sufficient, treat a hypothesis as a result, or put another audit ahead of delivery.

AI increased how much execution I could delegate. Designing the system around that execution became part of my work. I wanted the smallest amount of evidence sufficient for the actual risk, with a way to question, narrow, or remove controls when their cost was no longer justified. Without that, the agent could spend its effort maintaining the process around the product.

I developed this in a solo project, where I can change a rule as soon as I see the need. My experience here is limited to my own way of working. In a team, these boundaries would need shared ownership, explicit authority to change them, and enough simplicity for someone other than their author to use them.

Also on this

Context Is Not Permission: How context, ownership, and authority became part of the workflow around an AI agent.

Next Agent Workbench  opens in a new tab: A Next.js starter I built with guidance for matching checks to each change and setting a stopping point for review.