Inside a company, code you ship with an AI tool is judged on five things, and none of them is how fast it was written: is it right, is it safe, who reviewed it, can we keep it running, and what happens when you leave. This guide is the informed way to answer all five.
You can now build in an afternoon what used to take a fortnight. That is real, and it is also why your colleagues are nervous.
Plenty of people have been coding with AI tools for a year and are still doing it the uninformed way: fast, unreviewed, unwatched, and carried entirely in their own head. The tools reward that for a while. The company pays for it later.
This guide is in three parts, in the order that builds trust fastest, and it does not matter whether you are on day one or day four hundred.
Part one: change where you spend the time
The tool has taken over the typing. Your time goes to three places now, and the first shift is noticing that and moving with it.
Decide before you generate. For anything that touches a database, a system boundary or money, make the tool interview you before it builds. Three sentences do it: ask me about every part of this plan until we agree; one question at a time; give me your recommended answer with each; if the codebase already answers the question, go and read it.
You will get ten to fifty questions, and every one is a wrong assumption you did not have to ship. Then write the answers down in a file in the repo, because neither of you will remember them next week.
Read what it wrote. Fast for shape first: did it follow the patterns already in the codebase, or invent a parallel one? Send it back if so. Then slowly, for the places where business rules live: who can see what, anything that moves money or changes a status money depends on, anything that talks to another system. The tell to look for is confidence without a source: a case handled that you never described. Ask where it came from.
Write tests from the plan, not from the code. Tests the tool writes for its own code prove that the code does what the code does. Tests written from what you asked for prove something.
The standard at the end of this part: you can explain any change you shipped, line by line, to someone who does not use AI tools. That is the same standard that always applied.
Part two: make it safe and make it visible
The two things companies worry about most and AI-coders think about least.
Security is structural. The mistakes AI-built code makes are specific and repeatable:
- an object addressed by an id from the URL with no check that the caller owns it
- a secret that is optional in configuration and fails open when it is missing
- a server-side request to a URL a user supplied
- a permission check that exists on nine routes and is missing on the tenth
Learn to read for those, in that order, on everything you generate. The checklist is not long.
Add the checks that run forever. Tests cover the cases you thought of. AI-written logic is right on those and quietly wrong on the rest, and quietly is the problem. So add invariants: properties that must hold for every record, checked against real data. The total equals the sum of the lines. Nothing references another customer’s data.
Log and continue when one fails, never block the user, and fix or delete a failing check within the week. Tag every error with the version that produced it. When someone asks “when did this start”, you will be the person who can answer.
Do the homework on everything around the app. Where it runs, who has the keys, backups that have actually been restored, tests by someone other than you, a handover document. Your company will ask for these before it relies on what you built, and it is right to. The checklist for that conversation: The infrastructure around the app.
This is the part where the company starts to trust the output, because you can show what watches it and what surrounds it.
Part three: make it repeatable
By now you have learned things. The gotcha in the database’s permission model. The prompt that produces good tests. The reason the last migration went wrong. If those live in your head, or worse, in a chat history, you will relearn them, and so will the next person.
Keep a vault, not a chat log. A folder of short notes, one idea each, in a git repository, with an index the tool reads at the start of every session. Patterns, decisions with their reasoning, gotchas. When the tool starts a new task it already knows what you learned on the last three.
It takes an afternoon to set up, there is a guide, and it is the single thing that turned my AI-assisted work from fast into compounding. The whole section on it is here.
Make the repo carry the context. An instructions file under two hundred lines. A short architecture note that is actually re-read. A decision log. Update them before you close a session, and mid-session when something important is settled, because long sessions get summarized and the thing decided an hour ago is what gets lost. This is also your team’s coding standard, in the only form an AI tool actually reads: not a wiki page, a file every session starts from.
Write one thing up. Pick the most useful lesson you have learned and write it down for your team. Not a demo. A note: what you tried, what broke, what you do now. That note is worth more to your company than the feature it came from, and it is how you become the person people ask.
The five questions, answered
- Is it right: you decided before generating, read after, and wrote tests from the plan.
- Is it safe: you read for the structural mistakes and scheduled the security pass.
- Who reviewed it: you did, and you can explain every line.
- Can we keep it running: the invariants, the version tags and the homework say so.
- What happens when you leave: the vault and the repo files say everything you knew.
If any of this is useful, I would like to hear how it went. I write these from real work and I learn from what other people find. Connect on LinkedIn and tell me what you are building.