The tool changes. The engineering around it does not. Build the six disciplines that make AI-assisted software development reliable.
Six disciplines. One working environment.
Use Cursor, Claude Code, Codex, or whatever ships next month. The tool changes; the engineering around it does not. These six disciplines address the gaps that make AI work expensive, inconsistent and unreliable.
Each of those six gaps is an engineering discipline. None of them is fixed by a better prompt. They are fixed by building the environment.
Tick the ones you actually cover today. No cheating: “I paste the context into the chat” does not count — that is you doing it by hand, every time.
Tap each one to tick it.
Nothing ticked yet. If you are starting from zero, this is exactly what “sometimes the AI nails it and sometimes it doesn't” feels like.
Ordered by how much covering one changes your day. If you only cover one, cover the first.
What survives when you close the terminal?
Storing the decisions you make — and the reasoning behind each one — somewhere that still exists tomorrow and that any AI tool can read.
You re-explain the same things every morning, and every so often the agent enthusiastically proposes the option the team rejected a month ago. Nobody remembers why they rejected it.
What does it know about your world, right now?
Putting what actually exists within reach: your code, who calls what, and the docs for the library version you have installed.
It invents functions that sound entirely reasonable and do not exist. It rewrites things that were already built. It uses a library API as it stood two years ago.
What does “done well” mean on this project?
Writing the project's rules, conventions and procedures once, somewhere the agent reads on its own without being reminded.
Every session produces code in a slightly different style. You repeat “use pnpm”, “tests go here”, “don't touch that folder” endlessly. And when someone new joins, none of it is written down.
What can it touch, and what should it never be able to touch?
Giving it real access to what it needs — files, commands, external services — and setting explicit limits on what it does not.
Without access it describes the solution instead of doing it, and sometimes pretends it did. With unlimited access it eventually runs something destructive that nobody told it not to.
In what order does the work happen, and who does each part?
Splitting work into phases with something handed over between them, instead of asking for one large task in one go and seeing what comes out.
Long tasks start well and drift after an hour. Cost climbs without the result improving. And when something goes wrong, you cannot tell at what point it went wrong.
How do you know what it built works?
Having something that assumes the agent got it wrong and proves otherwise: tests that fail first, review not done by the author, and checks that cannot be skipped.
You merge code that passes every test and does not work. You ask the agent to review its own work and it tells you it is excellent, because a reviewer holding the author's own reasoning is in no position to find what that reasoning missed.
You do not need all six by tomorrow. These three stages add disciplines in the order that returns the most per hour spent, which is not the order of the list above: impact order is not adoption order. That list ranks how much each one changes your day; these stages start where starting is cheapest.
You have never configured anything beyond opening the tool
Write the project's rules and declare what may be touched. It is the highest effort-to-result ratio on the whole map, and it depends on no particular tool.
Covers
Effort
An afternoon, installing nothing
Rules are written and the repository has outgrown your head
You add the two ways of knowing: what exists in the code right now, and what we decided before. This is the stage that attacks hallucination at the root, and the first where context and memory are portable: they sit outside the tool, and whatever you use next can read them.
Covers
Effort
A weekend, with two services connected
A team that needs the same result on every machine
You add method and control: phases with deliverables, review that the author does not perform and that has a budget, and a configuration that installs identically anywhere. More ceremony; the return shows up once more than one person is involved.
Covers
Effort
Ongoing, with an agreed process