I'm a technical partner for businesses that outgrew the internal tools they built with AI.
These are the practices I use on real projects to keep systems built with AI agents working. You don't need all of them, and you don't need them all at once. Which ones matter depends on two things: how many people and agents use your system, and how many people and agents build it. I learned most of these the hard way.
The quality of a system comes from the practices around it, not from the talent of whoever writes the code. That holds for a team of people and for a team of agents.
There is one real difference. A person builds up experience with your system over time. An agent starts from zero every session, like the main character of the film Memento, who has to read his own notes to know what's going on. So what the system knows about itself has to live in the system: in files the agent reads before it touches anything.
Without that, an agent makes decisions that are sensible locally and make the whole thing more complicated. Every next change costs more and breaks more. The goal is the opposite: each change should leave the system a little simpler than before.
Practices also have a price. A test suite, a review process, a staging environment: each one is worth it at some point and a burden before that. So I pick them by stage, and I don't apply everything to everyone. The list below is organized that way.
Two questions place your system: who uses it every day, and who changes it? Count people and agents both.
You don't need all of this today. That's normal. The diagnostic settles your exact stage.
You're building this yourself with an AI agent, and hardly anyone uses it yet. The main job is to keep the system from becoming a pile of one-off decisions.
Languages, frameworks, versions and what not to use go in a file the agent reads before every task.
Without it: The agent picks different libraries in different corners. A month later nobody can say what the system runs on, and every change costs more than the last.
A single file in the repository: rules, boundaries, where things live, what never to do.
Without it: Every new chat, the agent starts blank and guesses the rules again. It guesses differently each time.
Every change is recorded, and any earlier version can be brought back.
Without it: One bad change from the agent and there's nothing to go back to. The whole system lives on one laptop.
One task, one change, one check. Not “rework everything.”
Without it: The agent rewrites half the system in one go, and nobody can tell what exactly broke.
A few checks on critical flows, growing with the system. They also tell the agent how things should work.
Without it: The agent fixes one thing and quietly breaks another. You learn about it from your team or a client.
A machine catches small mistakes and keeps the code in one consistent style.
Without it: Small mistakes a tool would catch in a second reach your client. Code looks different in every file, and the agent copies the worst examples.
Before calling a task done, the agent must run linters, formatters and tests, and they must pass.
Without it: When the agent says “done,” it means “I finished writing,” not “it works.”
Recurring problems get one proven solution chosen for your system, not every pattern in the book.
Without it: Every feature is built its own way. The system turns into a heap of one-off solutions, and each change costs more than the last.
Buttons, forms and tables are defined once, and the agent reuses them.
Without it: The agent draws a new button and form on every screen. The interface drifts, and a style change becomes a manual pass through every page.
A description of the system lives next to the code, and the agent must update it after every change.
Without it: What the system does lives in the author's head and old chat history. In three months neither you nor the agent know why. Outdated docs are worse than none.
Short notes on what was decided and the reason.
Without it: The agent “improves” something you did on purpose and brings back a problem you already beat once.
Exact versions are pinned in the repository. Installing a package can't run the package's own code.
Without it: One day a library updates itself and the system stops building. Or a package brings code that can reach your keys.
People use it, things break, and you should hear about it before they do.
Copies of your data are made on a schedule, with nobody having to remember.
Without it: One mistake or a server failure and the company's data is gone, with nothing to restore.
Regularly I restore a backup into a separate environment and check the data is there.
Without it: You find out the backups don't work on the day you need them.
New work gets tried on a copy of the system, not on your clients' live data.
Without it: Changes get tested on live data, and one mistake corrupts real orders or sends wrong emails to clients.
One dataset for manual checks, another that never changes for automated tests.
Without it: Tests pass one day and fail the next because the data moved. Checking turns into “let's look at it by eye.”
Configuration and secrets live outside the code, and the system starts the same way anywhere.
Without it: The system only works on that one server. Moving or restoring it becomes a week-long quest, and keys sit in the code itself.
The system itself tells you when it's down or when a key process stops working.
Without it: You hear about a breakage from your team or a client, not from the system.
When something fails, a trail remains: what happened, where and why.
Without it: “Something broke,” with no answer to what or why. The agent fixes by guesswork, and the problem comes back.
Any update can be rolled back to the previous working state quickly.
Without it: A bad update means hours of downtime while someone repairs it on the fly.
Step-by-step instructions: if X happens, do Y.
Without it: It breaks on Friday evening, and how to restart it or where to restore from is known by one person, or by a chat that's gone.
A short review: what happened, why, and which practice changes as a result.
Without it: The same breakage comes back every few months.
Known security holes in the libraries you use are flagged automatically (Dependabot, for example).
Without it: A library with a known hole sits in your system for years. Everyone knows about it except you.
Periodically I check database permissions, exposed endpoints and leaked keys.
Without it: Client data is open to anyone who knows the address. You hear about it from a stranger.
Once per cycle I look at which critical parts of the system no test covers.
Without it: Tests exist for show while new critical code sits uncovered. It feels safe, but isn't.
Once per cycle I measure cyclomatic complexity to find parts that have grown into a tangle.
Without it: Some parts turn into a tangle that both people and agents are afraid to touch.
More than one person or agent is changing the system at the same time. The main job is keeping them out of each other's way.
If the system works and one person is what limits it, the move into this stage from stage 1 or 2 is Speedup. A system that is breaking starts at Rescue.
Each parallel task runs in its own working copy (git worktree).
Without it: Two agents, or a person and an agent, edit the same files in one folder and overwrite each other's work.
Every change goes in its own branch and a person reads it before it reaches the main code.
Without it: Nobody looked at the agent's change, and a client finds the mistake.
Build and tests run by themselves on each change.
Without it: “It works on my machine,” and the main code is broken for everyone by morning.
Once per cycle I compare the system to what was agreed: stack, patterns, access rules, no extra dependencies.
Without it: Everyone reads the rules their own way. The system slowly becomes something nobody designed, and extra dependencies become extra risk.
Every change to the data structure is written in the repository, applied automatically and reversible.
Without it: Two people change the database by hand, versions drift apart, and there's no way back.
Each external service is handled in exactly one place in the code.
Without it: A service changes its API and fixes are needed all over the system. Switching vendors turns into a rewrite.
There are many users, and they fall into groups whose needs can conflict. The main job is making sure each group gets what it needs and nothing more.
Who can see and do what is described in one place and loaded into every task (an ACL).
Without it: When adding a feature, the agent guesses who sees what, and sooner or later shows a client someone else's data.
For each group, at minimum anonymous and signed-in users, tests confirm what each part of the system allows.
Without it: Access is checked by eye, and the mistake is found the day one client opens another client's data.
Who they are, what job they use the system for, and what habits and needs they have.
Without it: The system grows features for the loudest user and breaks the work of those who stay quiet.
A list of features: who needs each one and why.
Without it: Nobody knows who a feature is for or why it exists. Changing or removing it is scary because you can't tell whose work it breaks.
The system records who changed or viewed what, and when.
Without it: A dispute over who deleted something can't be settled, and after a leak you can't tell how far it went.
Four things I decline to do, and why.
The diagnostic finds your stage and the practices you actually need, in five business days.
Diagnostic: $1,900, 5 business days
You get a written report that stays yours. No obligation to continue.
Want to look around first? Try the free self-check.
Prefer email? Write to me directly: me@artkiselev.dev