Engineer-Directed AI

Ask AI to document your project and you’ll get comments on everything, neat headers, a thorough README, and a pile of text that mostly restates what the code already says. What it can’t capture is the reasoning living in your head: the choice that looks like a bug but isn’t, the constraint that will bite the next person who touches it. This episode shows how to let AI draft clear, organized docs while you keep the one thing it can’t see, deciding which surprising, non-obvious things are actually worth explaining before the obvious notes bury them.

AI can lay out a screen in seconds, arranging every field cleanly and putting nothing out of place. What it can’t do is decide what the screen is actually for. Hand it a feature and it gives every element the same size and weight, leaving your user to hunt for the one thing they came to do. This episode shows how to delegate the layout while keeping the judgment that matters: deciding what leads, what recedes, and what gets cut, so the screen does the hunting for the person instead of making them do it every time.

Ask AI to set up authentication and you get a login that works: sign-up, password hashing, sessions, reset emails, a door that locks. What you do not get, because you never asked for it, is any real sense of what each user is allowed to do once they are inside, so by default everyone who logs in can go anywhere. AI is genuinely good at the identity plumbing, and you should lean on it hard, since rolling your own is dangerous. But deciding who can see, change, and delete what, and where the walls between your users go, is a judgment call about the structure of trust in your app. This episode shows how to let AI build the lock while you decide who gets which key.

Ask AI to write tests for your code and you get a wall of green checkmarks that feels like safety, but really just proves your code does what your code does. If there’s a bug in there, AI writes a test that expects the buggy behavior, because that’s the behavior it saw. Writing tests is mechanical work AI does well, but deciding what is worth testing (which behaviors would be a quiet disaster if they silently broke) is a judgment call about what your feature is really promising. This episode shows how to bring the list of what matters and let AI build the alarms around it, so your suite stays quiet until something you genuinely care about breaks.

When you hand a feature to AI without saying what “done” means, it picks the easiest possible definition: the code runs and the happy path works. Everything else (the empty states, the error cases, the “what if two people do this at once”) quietly goes unbuilt, then resurfaces later as “bugs” that were really just scope nobody named. AI is great at spelling out every condition a feature could possibly need to satisfy, but deciding which of those conditions actually count as done for your version, right now, is a judgment call about what your feature has to guarantee for users to trust it. This episode shows how to let AI generate the full menu of finish lines so you can draw the one you’ll actually stand behind.

AI can build you a backup system that runs like clockwork, copying your data on a schedule and rotating out the old copies without you babysitting it. The catch is that “backups exist” and “the thing I can’t afford to lose is safe” are not the same sentence, and plenty of people find that out at the worst possible moment, staring at a backup that doesn’t reach far enough or only holds the already-broken data. This piece covers handing AI the mechanism while you keep the judgment underneath it: which data is precious, how far back it has to reach, and which disaster you’re actually guarding against. It also makes the case for the step almost everyone skips, which is proving you can restore from a backup before you ever have to do it in a panic.

Ask AI to add error handling and it will catch every failure in your app so nothing crashes, which is exactly the boring, thorough work it’s good at. The problem is that catching a failure and handling it are not the same thing, and a user who hits a dead download and sees a generic “an error occurred” is left with no idea whether to wait, retry, or give up. This piece walks through delegating the catching while you keep the real decision: what each failure means to the person hitting it, what they should see, and which failures you’d rather have blow up loudly than get quietly hidden. AI catches everything; you decide what’s worth telling the user and what’s worth telling you.

AI can take any feature and slice it into clean, ordered steps faster than you can read them, which is genuinely useful. The trap is letting it build the whole feature in one swing, because then the first thing that breaks sends you digging through a slab of code you never watched get written. The fix is deciding for yourself where the checkpoints go: after which steps you stop, run the thing, and confirm it works before you let anything build on top of it. AI slices the work; you decide how much to build before you look. This piece shows you how to hand off the decomposition while keeping the one call that keeps every bug small enough to catch the moment it happens.