Kathryn Good spent months trying to build her own recipe app. Add a recipe, mark it a favorite, pull it into a grocery list. With AI doing the heavy lifting, she got most of the way there. Then it threw an error she couldn’t read, on a project with nothing but her own grocery list at stake.
Jesse Lilly has spent thirty-two years on the other side of that error message. He started programming secretly in high school, competing quietly while everyone else thought his thing was football. He built his first company in 2014, writing software for industries where a mistake carries real weight, and now his team builds almost entirely with AI, with real developers still checking every step that matters. He’s also one of Kathryn’s oldest friends, and lately, her AI development partner.
This episode is about the gap between those two experiences: what it feels like to build something real with AI, and what a developer actually sees underneath it. Jesse’s answer isn’t to slow down. It’s to know exactly when to bring in a real developer, and why.
Why can AI-built software look like it’s working when it isn’t?
AI can generate something that looks functional on the surface while failing quietly underneath. Jesse has seen it firsthand: an app that appears to save data correctly while nothing is actually being tracked, logged, or protected the way the business assumes.
The danger isn’t obvious because nothing breaks in a way you can see. Data can be structured wrong, unsecured, or lost entirely, and the first sign of trouble is often a problem the business can’t reverse. A recipe database that throws an error is a wasted weekend. A customer database built the same way is a different kind of risk.
How do you know when to bring in a developer?
The line Jesse draws is simple. Ask who else is affected if it breaks. A tool for your own use, with no money changing hands and nothing sensitive stored, is safe to build, break, and rebuild on your own. The moment it touches customer data, payment information, or something the business depends on, it needs a developer’s eyes before it goes further.
That doesn’t mean waiting to build. It means bringing someone in early, before the stakes get high enough that a mistake becomes expensive to fix. Jesse put it plainly: the earlier a developer gets involved, the better, because it gets you back on the right track before the headaches pile up.
What does it mean to treat AI like a junior developer?
Jesse’s clearest rule from the conversation: treat every AI output the way you’d treat work from a junior developer. Useful, often faster than doing it yourself, but never unchecked. You wouldn’t hand a brand-new hire your production database with no review. AI output needs the same posture.
That means reviewing what it built, understanding what it changed, and never assuming a clean-looking result is a correct one. It’s the same discipline that makes any team function. You can delegate the work. You don’t delegate the responsibility for what it produces.
Why do businesses keep losing their own AI decisions?
The other risk Jesse and Kathryn get into is quieter: AI memory scattered across personal accounts instead of company systems. When someone builds a policy, a process, or a piece of software inside their own personal AI account, the business doesn’t actually own what got built. If that person leaves, the decisions leave with them, and whoever’s left has to start over without knowing why anything was built the way it was.
Jesse’s read on it: businesses have always known not to let people walk out the door with a company laptop. AI accounts deserve the same rule.
Use This Today
Pick one thing your team built with AI in the last month, a doc, a workflow, a small tool. Ask one question: if this broke tomorrow, who would know how to fix it? If the honest answer is nobody, that’s the thing to document or hand to a developer first.
None of this means AI is unsafe to use. It means the old rules about backups, documentation, and knowing when to call an expert still apply. They just apply faster now.
FAQ
Can I build my own app or tool with AI without hiring a developer? Yes, if the stakes are low. If nothing sensitive is stored and no one but you is affected if it breaks, building and rebuilding with AI on your own is fine. Once it touches customer data, payments, or something the business depends on, bring in a developer before you scale it.
What’s the biggest risk of building software with AI? The output can look like it’s working while failing quietly underneath, in how data is stored, secured, or tracked. The failure often isn’t visible until it’s already a problem.
How do I know if my AI-built tool needs a developer? Ask whether anyone besides you is affected if it breaks, and whether it handles money, personal data, or anything the business relies on. If yes to either, get a developer’s eyes on it before it goes further.
What happens to AI-built work when an employee uses a personal account? The business doesn’t own what was built. Decisions, documents, and tools live in one person’s account instead of company systems, and if that person leaves, the knowledge leaves with them.
What does it mean to treat AI like a junior developer? It means using AI’s output the way you’d use a new hire’s work: helpful, often fast, but always reviewed before it’s trusted with something that matters.
Close
The tools have changed. The judgment they require hasn’t. Know when the stakes call for a real developer, and bring one in before you need one.