The Process Became the Work

Making an AI-assisted workflow safer seems straightforward: add more checks, more rules, and more review. I did that.

Types, contracts, browser tests, architecture rules, database boundaries, manual QA, observability, and review loops each addressed a real failure. Together, they created another system around the product — and that system could fail too.

I worked this out while building a solo product where I could change the workflow as quickly as the code. That made one failure mode unusually visible: adding a useful safeguard was easy; removing one required a deliberate decision.

The warning was not that the safeguards were useless. It was that they could become their own success criterion. A green pipeline could stand in for product quality. A review loop could produce audit history instead of a decision. A rule could survive after the risk it addressed had changed.

The problem was no longer only how to make the agent safer. It was what proof was sufficient, what that proof cost, and when the process should stop.

Proof had to match the claim

Green CI could not prove interaction quality, and the workflow did not always require the extra proof. Without a visual pass, real-device check, or focus validation, automated evidence could quietly become the definition of done.

So I started matching the verification form to the claim.

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

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

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

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

The question changed from “which checks should I run?” to:

What exactly am I claiming, and what evidence could prove me wrong?

That distinction shaped the SDLC around the agent: PR-only integration, path-aware CI, executable architecture and database boundaries, 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. The point was not the number of checks, but that the workflow should not try to prove everything in the same way.

AI is excellent at producing fixtures, tests, classifiers, scripts, and review evidence. It should not be the sole authority on what kind of evidence is sufficient for its own work.

That includes deciding whether a policy is executable at all. I tried to turn one rule about global browser-state access in reusable components into a source guard. Two implementation attempts showed that they would either miss aliased access to browser globals or reject legitimate local values that happened to use the same names. I removed the guard — and the documentation claim that said the control existed — rather than ship a check that only looked strict.

The documentation checker that did ship is narrower by design. It enforces what the repository can prove deterministically: file structure, links, compatibility anchors, and bounded growth. It does not pretend to infer lifecycle meaning, implementation status, or authority. Those remain semantic reviews.

That layer has a cost: review overhead, CI minutes, test maintenance, and the risk of turning a quality gate into a ritual. Verification needs scope and retirement criteria too.

Then the workflow started optimizing itself

In August, I audited the SDLC across 100 first-parent commits during two weeks.

I was not trying to prove that the process was mature. I was looking for places where written rules lacked technical controls, privileged tooling had too much authority, or processes created the appearance of safety without substance.

The audit led to real improvements: protected main, required checks, automatic branch cleanup, a least-privilege direction for privileged connectors, and clearer executable architecture and database boundaries.

Then the system began serving itself.

The clearest signal was AGENTS.md. In 16 days, it grew from 191 to 514 lines. Much of the added text focused on documenting and reviewing changes rather than on building the product.

Median pull-request lead time barely moved, but the slow tail more than doubled. The process looked healthy on average, while complex changes became much less predictable.

One small documentation-only pull request with a +123/−2 diff generated 11 successive audit records, each invalidating the previous one. Some rounds found real issues; the rest maintained the review mechanism itself. The success criterion had shifted from safe delivery to audit-trail completeness.

I reset the governance model. AGENTS.md  opens in a new tab fell from 514 to 347 lines. A few 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 change-budget gate, and bounded the review loop to one review batch, one remediation batch, one re-review, then an owner decision.

I added a conservation rule:

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

The stopping rule was tested almost immediately. A large implementation batch reached another valid blocker on re-review. I closed the pull request without merging it, instead of reopening the loop, and then recovered the work in materially smaller, independent branches, each based on a fresh main. A stopping rule is only real if it is allowed to stop real work.

I cut costs elsewhere too. Playwright E2E left the routine pre-push path. Remote CI for the development-only design catalog was retired. The full local catalog became an opt-in diagnostic.

A mature AI-assisted SDLC is not the one with the most safeguards. It applies the smallest proof sufficient for the actual risk and has a way to remove controls that no longer justify their cost. Otherwise, the agent starts serving the process graph around the product instead of the product itself.

What remains human

My role is not to write the perfect prompt or accumulate the most safeguards. It is to define what is being claimed, what evidence could prove it wrong, what risk remains, and when another review will no longer change the next decision.

AI can inspect the repository, propose a decomposition, write code, migrations, tests, documentation, and review findings. Clear boundaries give it more execution capacity, not less. But the agent does not decide that its own tests are sufficient, rename a hypothesis as a result, or prioritize another audit over delivery.

AI increased the amount of execution I could delegate. It also made the system around that execution part of the design problem.

I developed this operating model in a solo project, where I can change a rule as soon as I see the need. In a team, the same boundaries would require shared ownership, explicit change authority, and enough simplicity for people other than the author to use them. This is evidence for my way of working, not a universal standard for every organization.

The workflow did not need the most controls. It needed the smallest proof sufficient for the actual risk — and a way to question, narrow, or remove controls when they no longer earned their cost.

Someone still has to decide what counts as enough.

Also on this

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