Getting better at AI coding

Describe the contract before the code

A vibe coding idea usually arrives as a single sentence: a form that emails the team, a dashboard for last month’s numbers. That is enough to start a conversation and not enough to write code against. Before the agent types anything, write down three things: what goes in, what comes out, and what must not happen.

The third one is what people skip, and it is what produces the messes. Nobody can see another customer’s rows. The import never runs twice against the same file. Amounts stay in whole cents. Two or three lines like that cost a minute and turn a vague request into something with a right answer.

Work in steps small enough to check

Let the size of a step be set by what you can verify at the end of it, not by what the agent can produce in one go. It will happily write six files, and if the only way to check them is to read all six, you have bought speed with a debt you pay later.

A good step ends in something you can run: a test, a page you can open, a command whose output you can read. When it works, commit. That commit is where you return to when the next step goes sideways, which beats untangling changes you never fully understood.

A step you cannot verify is a step you cannot trust, however good it looks. When you hit one, add the check that is missing, or throw the step away and ask for half of it.

Write the project’s context down once

If you explain the same three things at the start of every session, that is a file waiting to be written. Agents read instruction files from the repository they are working in, so context you put there is context you stop repeating.

Include what is not visible from the code: which directory holds what, the commands to run the tests and start the app, the conventions you genuinely care about, and the decisions somebody already made and does not want revisited. Keep it short and specific, so the one instruction that matters is not buried under forty that do not. Add a line whenever you catch yourself explaining something for the third time.

Review the seams first

The mistakes that are hardest to spot sit where new code meets everything else, because that is where it needs knowledge of the wider application that no prompt fully gave it. Read those seams closely before anything else. A function with complex logic, or one where a mistake would be expensive, still deserves a careful read of its own.

• Boundaries Every place the new code calls into existing code or gets called by it. Check that the arguments mean what the other side believes they mean.

• Error paths What happens when the call fails or the response comes back empty. Generated code writes the happy path well and the failure path optimistically.

• Assumptions about the data It was shown an example and wrote for that example. Ask what it does with an empty list, a missing field, a duplicate row.

• Anything it invented New dependencies, new configuration, new tables. Each one is a decision that somebody should be making on purpose.

Make the feedback loop fast

An agent is only as good as what it can find out. If it can run the tests, it catches many of its own mistakes before you see them, at least the ones the tests cover. If it cannot, you become the test suite, and you are slower and less patient than one.

So spend time on the loop itself: tests that finish in seconds, a dev server that reloads, an error message that names the line. That work pays back every session afterwards.

For behaviour you cannot check locally, the loop has to reach something running. AppHaven gives each branch a preview with its own database, so a change can be tried against real behaviour before it reaches anyone. Deploying an AI-built app covers the setup.

Know when to take the keyboard back

Some problems are faster to solve yourself, and recognising them is a skill worth building. The signal is repetition. If the second attempt did not fix it and the third made it worse, more prompting is unlikely to help. The agent is guessing, and every guess adds code you have to read.

The ones that go faster by hand are usually where you hold information the agent does not: a bug that depends on how your data actually looks, a choice between two designs where the tradeoff is about your plans rather than the code, half a page of fiddly logic you could simply write. Do that part yourself, then hand the work back with the hard bit settled.

Taking the keyboard back is part of the same habit: hand the agent problems it can get right, and stay close enough to tell when it has.