Denshin / Blog / Engineering
AI coding agents: guardrails for shipping real software
Vibe coding is fine for a prototype and dangerous as a delivery method. The guardrails that make AI-written code safe to ship: a conventions file the agent reads first, tests and typecheck as the feedback loop, small diffs, permission gates on anything irreversible, and a named human who owns the PR.
Denshin Engineering · Engineering Team · 27 August 2026 · 6 min read
Letting an AI agent write code by feel is a great way to get a prototype in front of someone by Friday. It is a bad way to run delivery. The difference is not the model and it is not the prompt, it is the set of constraints around the agent: what it reads before it starts, what tells it that it is wrong, how big a diff it is allowed to produce, and who signs their name to the result. This post is the guardrail set we would want in place before an agent touches a repository that real users depend on.
Vibe coding versus delivery
"Vibe coding" means accepting generated code based on whether the thing appears to work, without reading it closely. That is a legitimate mode for a throwaway prototype, a spike, or a script you will run once. It stops being legitimate the moment the code enters a repository that someone else will maintain, because the reviewer of last resort has quietly become nobody.
The guardrails below are what convert the second case back into normal software delivery. None of them are exotic. Most are things a good team already does, applied with more discipline because the code is arriving faster than a human would produce it.
The guardrails that make agent-written code shippable
A conventions file the agent reads first
Put a file at the root of the repo that states the stack, the commands to install, run, typecheck and test, the directory conventions, and the things that are forbidden. Every serious agent tool has a convention for this. It is the highest-leverage thirty minutes available, because without it the agent re-derives your architecture from scratch on every session and gets it slightly wrong in a different way each time. Keep it short and delete rules that stop being true, for the reasons set out in context engineering.
Tests and typecheck as the feedback loop
An agent with no way to check its own work will hand you code that looks right. An agent that can run the typechecker and the test suite will iterate until it is actually right, or until it gets stuck in a way you can see. This is the single biggest quality difference in practice, and it is why strongly typed codebases with fast test suites get disproportionate value from agents. If your test suite takes twenty minutes, the loop is too slow to help, and speeding it up is now an AI-productivity investment as well as a developer-experience one.
Make the commands explicit in the conventions file and require them to pass before the agent proposes a change. Schema validation at the boundaries helps here too, because a runtime validation failure is a clear signal the agent can act on, which is one more argument for the approach in why Zod replaced our hand-rolled validators.
Small, reviewable diffs
Agents will happily rewrite forty files. Do not let them, not because the changes are necessarily wrong but because a diff nobody can review is a diff nobody has reviewed. Scope each task to something a human can read in one sitting. If a change genuinely spans a lot of files, split it into a mechanical pass and a judgement pass, and review those separately.
Permission gates on anything irreversible
Reading files and running tests can be automatic. Pushing branches, opening pull requests, deploying, running migrations, touching infrastructure and calling paid APIs should require a human confirmation. Configure this in the tool rather than relying on instructions in a prompt, because a prompt is a request and a permission setting is a control. The distinction matters: an agent that reads untrusted content, such as a bug report or a web page, can be influenced by it, which is the threat model described in prompt injection and AI guardrails.
Secrets never in context
Real credentials should not be in files the agent reads, in environment output it captures, or in logs it can open. Use a local env file that is git-ignored and excluded from the agent's readable set, keep production credentials out of developer machines entirely, and assume anything that enters the context window may end up in a transcript or a log. If a secret does get exposed, rotate it rather than reasoning about whether it leaked.
A named human owns the diff
Whoever opens the pull request owns it, in the same way they would own code they typed. "The agent wrote it" is not a defence in a post-incident review and should never be a line in a PR description. This is the guardrail that makes all the others stick, because it puts the incentive to read the diff in the right place.
Where agents genuinely shine
- Scaffolding a vertical slice. A new entity end to end: handler, validation schema, shared types, query hooks, an admin form. It is repetitive, the pattern already exists in the repo, and the agent follows it faster than you would.
- Cross-cutting refactors. Renaming a concept across a monorepo, migrating a deprecated API call, changing a signature and fixing every caller. Mechanical, verifiable by the typechecker, tedious for a human.
- Test generation. Especially filling in the edge cases around code you already wrote, and writing the characterisation tests that let you refactor something old with confidence.
- Tracing a bug across layers. Following a value from a form field through an API handler into a database write and back, across files you did not write. Agents are good at reading, and reading is most of debugging.
- The first draft of the boring parts. Error handling, loading and empty states, input validation, the admin table nobody volunteers for.
Where they need a short leash
| Area | Why it is risky | Leash |
|---|
| Authentication and authorisation | Plausible-looking code can be subtly permissive, and tests rarely cover the negative case | Human writes the rules, agent may write the tests |
| Payments and billing | Errors are financial and hard to reverse | Line-by-line review, sandbox only, no live keys in context |
| Data migrations | Destructive, and often not reversible | Human authored, dry run against a restored snapshot first |
| Schema and index changes | In single-table designs an access pattern change can be a rewrite | Design by hand, agent implements against the agreed design |
| Dependency additions | Supply chain and licence exposure | Explicit approval per package, check it actually exists and is maintained |
| Deletions | Agents remove code that looks unused | Require justification per deletion in the PR description |
Review checklist for a PR an agent mostly wrote
Read this list against the diff, not against the description of the diff.
- Does it do what was asked, and only that? Scope creep is the most common failure. Unrequested "improvements" are the ones that break things.
- Is anything invented? Check that every imported package, config key, environment variable and API method actually exists in this version of the dependency.
- Does it duplicate something that already exists? Agents write a new helper more readily than they find yours.
- Are the tests real? A test that asserts a mock returned what the mock was told to return proves nothing. Check that at least one test would fail if you broke the behaviour.
- Error and edge paths. What happens on an empty list, a failed network call, a duplicate submit, an unauthorised user?
- Security-relevant lines. Any new endpoint, any change to who can access what, any place user input reaches a query or a file path.
- Deletions and config changes, which are easy to skim past in a large diff and are where the surprises live.
- Would you defend it? If you would not have written it this way and cannot explain why it is fine, send it back.
Before any of this reaches users, it still goes through the same release discipline as everything else, which for us is the pre-launch checklist we run before shipping.
What to do next
If your team is already using coding agents informally, formalise it this week. Write the conventions file. Turn on permission gates for push, deploy and migrations. Agree that a human owns every PR. Add the checklist above to your PR template. Then measure the thing that actually matters, which is not lines generated but how often agent-authored changes come back as defects.
For how this changed our day-to-day delivery rather than our guardrails, see how AI pair programming reshaped our delivery. If you are trying to get agents into a real delivery process without loosening your standards, talk to us.
Tags: AI Coding Agents, Code Review, Developer Productivity, AI Security, Software Delivery
All posts · Work with Denshin