Standardize what ships, not the workflow
How the Story Usually GoesLink to this section
The company discovers what AI tooling can do. The demos are genuinely impressive. Developers dive in. Stakeholders see the early wins and raise their expectations. Delivery speeds up.
Then the problems show up, in pieces:
- Code quality goes out of control in ways that are hard to pin to any single change.
- QA gets more tickets than the team can process. The review queue fills the same way.
- The sprint is not delivered, because the tickets were never fully done - they sit stuck in code review or QA.
- Under that pace, developers start skipping reviews, or treating them as optional, and the bar that used to be implicit starts to drop.
That is usually when someone decides the answer is one approved tool and one shared process for everyone.
I understand the instinct. I have been through a version of it on design systems, and it did not work the way I expected. Building the library was the easy part. Getting teams to use it was the job. A document explaining how to build a screen did not make the screens consistent. What did was the contract, the component API, the tokens, a review on anything that entered the shared package, and a CI gate that failed the build when a screenshot drifted.
The field moves faster than any process document can. Around me, no two setups match, and I see no honest basis for declaring one of them correct.
I have watched the cost show up on a package several products share. An agent was building one screen and needed a small helper. Instead of keeping that helper in the product, it added the function to the shared package and shipped the feature. The PR looked finished.
Other teams could now import that function, which means we owned it:
- We had to keep it working.
- We could not rename it without breaking someone.
- We could not delete it later without a migration.
Nobody had decided it belonged there. Generating it had cost nothing. Taking it back would not.
The useful move is not to pick how people build. It is to standardize the shape of what ships: the architecture, the contracts, the quality gates, the written standard of the codebase. A few walls around the expensive things. Freedom inside them.
Hard Walls, Free InteriorLink to this section
I would rather put the walls in the environment than rely on watching. I cannot review my way to safety at agent throughput. Watching harder just moves the exhaustion around.
A few of the walls below live on my machine. The rest only count if they live in shared infrastructure. I do not ask anyone to use my editor.
This is not an argument that every paved path is wrong. A short onboarding loop can be the right call for someone’s first week. A regulated surface can be the wrong place for a second way to reach production. Those are walls around a specific cost. They are not a reason to freeze how everyone prompts.
Walls - protect something expensive
- Secrets: env files, keys, and credentials unreachable
- Deploy and debug targets limited to granted environments
- CI gates: tests, types, lint, visual regression
- Contracts: APIs, packages, design system surfaces
- The prototype-or-production declaration
- A human on every production merge
Interior - leave it alone
- Choice of agent, editor, model
- Loop style: spec-first, test-first, conversational
- Personal rules and skills on top of the base set
- One agent or an orchestra of them
- Review tools and stacked-diff habits
- Prompting technique, session habits
The test for which column something belongs in: does it protect something expensive? Production, user data, secrets, the long-term readability of the codebase. If yes, it is a wall. If not, leave it alone. A rule that protects nothing is just friction.
Mode, a human on every production merge, contracts, and CI are walls. They change the shape of what can merge. A favorite editor skill, a review product, stacked pull requests: those help, and they are still interior. People still need a way to start. Onboard them to the walls and to a small base set of skills the tools load for everyone.
The Walls in PracticeLink to this section
A wall only counts if it holds when nobody is looking, which means it has to live in infrastructure rather than in a guidelines document.
Secrets
I work on products that handle sensitive user data, so hope is not a control. Agent sessions run sandboxed. Environment files, SSH keys, and cloud credentials are deny-listed at the filesystem level, and network access is allowlisted per host.
That does not empty the session. The working tree is still in the room. Tickets and screenshots can still carry data. The wall is the files and hosts the agent should never touch. A prompt instruction is a request and a filesystem rule is a fact. Prompt injection does not override a mount.
Deploy targets
The agent should hold no production credentials. It can deploy and debug exactly where it has been granted access, which by default is nowhere. The failure mode is quiet: an agent helpfully “verifying the fix” against a system it had no business reaching. I would rather make that impossible than hope to catch it.
Visual regression
This is the gate I would steal first if I were starting over. I rolled it out across the shared frontend architecture I maintain, and it is now part of the pre-release path for teams that consume that architecture. Anything that touches shared UI gets snapshots at laptop, tablet, and mobile. I review the screenshot diffs in Chromatic.
I have started preferring that diff to the argument in a pull request. A spacing drift on a shared button is cheaper to catch in a snapshot than to debate. The suite does not know whether a human or an agent produced the commit. That is the property I want from every wall. Tests, types, and lint already work this way. What changed is who hits them, and how often.
Contracts
Shared interfaces, module boundaries, and package APIs are walls in exactly this sense. A design system of 30+ components holds across multiple products because the public API is decided once, product-level one-offs stay out of the shared package, and the boundary is enforced in exports and types. I have already written how that works organizationally.
What agents changed is the rate. Generating a helper is free, so the package will absorb drive-by exports unless the boundary is a fact, not a review comment. Module boundaries in a monorepo do the same job for business flows. If the shape of what can cross lives only in a wiki, volume will walk around it.
Human review
This is the wall under the most pressure. The usual reaction is to lower the bar or skip the review so the queue can move. Production still needs a person on the questions a machine cannot answer: whether the change belongs, whether it is readable without the session that produced it, and whether it will still make sense six months from now. A typecheck can prove a type. A snapshot can prove a visual. Neither can decide that we should own this. Prototype merges skip this rung.
What can change is how long that hour takes. Before anyone else opens the diff, the change should already have been through the agent’s own pass and the gates. A pull request that arrives with typos, failing types, or an unexplained architecture shift is asking a human to do a machine’s job. A 40-file agent dump is unreviewable no matter who is looking. Keep production changes small enough that a person can actually hold the question. Stacked pull requests help if the team already uses them. They are a technique, not a standard.
Agent self-review
Before code reaches anyone, the agent reviews its own diff against the written standards, runs the gates locally, and iterates. This loop is cheap. It catches typos, dead code, style drift, the obvious bug. It will not tell you whether the change belongs in the architecture.
Automated gates
Tests, types, lint, visual regression. Deterministic and tireless. They treat the first commit like the last.
Human review on every production merge
Not as a formality and not as a typo hunt. The human looks at what only a person can judge: does this change belong in the architecture, is it the right change for the product, is it readable without the session that produced it.
The first rung can be a skill that reviews the diff against the written standard, or a review product. That choice is interior. The wall is that production still gets a person.
I have caught myself leaving a review comment on a type error CI had already failed. That is senior hours used as a linter. The hour is for whoever owns the written standard, plus the people closest to the product surface. Design and product belong when the question is about shape: whether this belongs in the system, or is a product-level one-off.
Prototype or ProductionLink to this section
This is a wall, not interior. It changes which other walls apply. The mode has to be named before the work is planned: prototype or production. Doing it later, after the first commit or after the folder already looks finished, is how code crosses from one to the other without the gates changing. Most of the AI quality trouble I have run into came from that crossing.
The mode follows from whether we are still validating an idea, or whether we have accepted it and now own the code.
| Aspect | ||
|---|---|---|
| Purpose | Answer a question cheaply | Ship |
| Tests | Only what forces a working result | The full pattern: unit, integration, visual |
| Standards loaded | Minimal | The full base set |
| Review | None | A person on what machines cannot prove |
| Fate of the code | Disposable by contract | Maintained for years |
| Agent autonomy | High | Bounded |
A prototype answers a question. The code is disposable by contract, even when it runs as an internal tool on production infrastructure so people can try it. Running somewhere, having people click it, or surviving a few weeks does not change the mode. If the team already depends on it as the path, calling it a prototype is how the walls stay down after people are already relying on it.
A working spike often already looks like a product, so keeping that code feels cheaper than rewriting it. Saying yes to a prototype is a yes on the idea, not on the code. Graduation is a rewrite under production gates. Renaming the folder, deploying it, or pointing an internal URL at it is not graduation.
“Minimal tests” is not “no tests.” Keep the tests that force a genuinely working answer. Drop coverage thresholds, style conformance, and the full testing pattern. Those exist for code you plan to keep.
On a flow someone has to finish with a keyboard or a screen reader, that is part of the production wall, not a later audit. I learned that building a portal for disability claimants, and wrote up why it has to be an architecture constraint. How you get to a throwaway answer is still interior. An agent can run with a lot of autonomy there because the directory can still be thrown away.
Write the Standard DownLink to this section
People call this taste, which makes it sound innate. It is a specialization: architectural knowledge, good patterns, the expectations you build by watching what stays maintainable and what decays. Concretely it is the readability bar, the level of testing considered done, and the architectural direction being built toward, written down so the tools can load it the way they load a lint config.
Someone has to maintain that standard, or it gets renegotiated in every review comment. That is the same job as maintaining a design system: people contribute, API designs get reviewed, and the owner is a maintainer rather than a gate every line has to pass through by hand.
I did not write a standard before I started using agents, and in hindsight I am glad. The first rules I added were slogans - fix the root cause, prefer complete implementations. Agents followed them badly, and I spent review time arguing with the wording. I deleted them. What survived is short, named, and about the shape of what merges:
- Do not add a public export to a shared package to unblock a single screen.
- A product-level one-off does not belong in the design system.
- If a review finding can be a check next time, put it in a check. Do not keep catching it by hand.
Every rule has to be maintained, and every rule spends a slice of the agent’s attention. A small set of precisely named rules has worked better for me than any comprehensive framework I have tried. Skills are the same: fewer of them, named precisely, scoped so they fire only when they are relevant. When I am unsure a skill should exist, I delete it.
Enable the InteriorLink to this section
Freedom inside the walls does not do much if it just means nobody is stopping you. People still need to see what is possible, share what they are trying, and have time to find out what actually works.
The form that already works for this, at least on the design-system side, is a regular working group. Not a ticket queue. Not a changelog. People bring friction, show a loop, share a skill. Someone shows a setup that collapsed a recurring chore, and other people try it the next day. That is how a personal orchestra becomes a team asset without becoming last month’s workflow document. People also need a way to push back on a wall, or to ask why a skill is in the base set. When engineers have input into the thing they are asked to use, adoption mostly takes care of itself.
The time on the calendar has to be for how people build, not for the next feature. That is internal R&D, not permission to wander on product scope. If the only sanctioned work is the next ticket, nobody notices what is slow, what is repeated, or what would unlock everyone else. Fund that time the way you fund a design-system working group. Do not hope it happens after standup.
This is unlike the editor era, when you picked JetBrains or VS Code, learned it deeply, and stayed for a decade. I miss that stability. The tooling now gets replaced in months. Mandating a process just freezes whatever was current when you wrote it down. Large teams that treat developer experience as real work sometimes end up with something in-house that fits how they actually work. The point is not to copy their agent. The point is that they spent the time.
The wall side has the opposite failure: the walls quietly grow until there is no interior left. Every painful review wants a new rule.
- If a finding can be a check, it becomes a check.
- If it cannot, and it is not expensive to get wrong, it stays in the interior.
A rule that only a reviewer can enforce is just a reviewer with more to read.
Start With One WallLink to this section
None of these walls are AI inventions. Tests as a gate, visual regression, design system contracts, restricted credentials, review that exercises judgment: a multi-team codebase wanted them with or without agents. Agents took the job that was already there - adoption, contracts, making the right path the only easy path - and made it the whole job.
If the story at the top is unfolding around you, skip the process document.
- Put one wall in infrastructure and make sure it holds when nobody is watching.
- Write down the rules your reviews keep repeating, and load them where the tools can see them.
- Name prototype or production before the next piece of work is planned.
- Spend the time that saves on showing people what is possible, giving them room to experiment with how they build, and a place to show each other what they find.
The walls keep the quality bar where you put it. The interior, given room and time, is where the improvement comes from.
Related: how a design system holds across products without a mandated workflow, and why WCAG works better as an architecture constraint than as a checklist.