When I code with AI, I roughly think of a full stack project in 3 layers:
I don’t treat them equally.
For the database, I spend a lot of time getting the schema right. And for actions that directly operate on the database, I review the code carefully.
I think software is basically a state machine.
The database holds the state, and these actions are what actually change it. This is the part where I really don’t want the AI to surprise me.
For business logic and APIs, I work differently. I have pretty strict conventions around them — inputs and outputs have schemas, things should be traceable, etc.
But most of my time is spent talking with the agent about behavior: what should happen, what shouldn’t happen, edge cases, failure cases, and so on. I want to make sure we’re thinking about the system in the same way.
Once the schema is settled, I find these conversations get much easier. A lot of context is already encoded in the schema, so there is less ambiguity between me and the AI.
Then for the interface, I loosen the leash a lot. I’m not a designer. I know some basic UI/UX and I care that the product is useful and easy to use. Beyond that, I’m happy to let AI try things. If I don’t like what it makes, I throw it away and try again.
So roughly:
The closer something is to the actual state of the system, and the harder it is to undo, the tighter the leash.
