How to Build Software with AI | Ep 5: Where Everything Lives

Transcript

The full word-for-word transcript of this episode. Plain text version

Marcus: You saved a task in your newly built app. You closed everything down, the screen went black, and um the next day, it was still there.

Devon: Right.

Marcus: We ended the fourth instalment of our beginner build series on that exact cliffhanger. So where did that task actually go?

Devon: Yeah, I mean, it is the central mystery, isn't it? For anyone making their own software for the first time, the interface disappears, the power is cut, but something, somewhere, remembered you.

Marcus: Welcome to the fifth instalment of our beginner build series, which is aimed squarely at complete beginners making their own software. And uh before we get into it, if you are finding this series valuable, please do take a second to follow the show wherever you are listening. It genuinely helps us out.

Devon: It really does.

Marcus: Now, our mission for this deep dive is to understand the rememberer of your software. We need to figure out how to safely change where things live without losing them, and well, we're going to learn the single strictest rule in all of software design.

Devon: Yes, the unbreakable rule.

Marcus: Because there is something slightly spooky about it, isn't there? I mean, the idea of a machine holding on to a piece of yourself while you are away.

Devon: The spooky feeling is entirely natural, but uh I promise it is not magic. It is simply a database doing its one dedicated job.

Marcus: Okay, so just a database.

Devon: Exactly. To understand this, you have to separate the surface of your software from the depths. Like when you use an app, the buttons, the colours, the animations, that is all temporary.

Marcus: Right.

Devon: If that part crashes, you just refresh the page. No harm done. But the database is what we call durable state.

Marcus: Durable state.

Devon: Yeah. Its entire architecture is designed to grip onto information and absolutely refuse to let it go, even if the server catches fire.

Marcus: Oh, wow.

Devon: So anything you do online that stays done, you know, the order that arrives, the account that recognises your password, that is just a database holding onto a piece of durable state and fetching it back out when asked.

Marcus: Let's visualise the physical space this occupies, though. Because throwing around terms like durable state or uh the cloud, it's far too abstract for someone just trying to build a simple task manager.

Devon: Sure, yeah.

Marcus: How is this memory actually organised under the hood? Like physically?

Devon: Well, the most accurate physical picture you can hold in your mind is a really well-run records office. Think of a database as a massive industrial filing cabinet.

Marcus: Okay, a massive filing cabinet. I can picture that.

Devon: It is literally how the system is partitioned. The cabinet contains heavy steel drawers, which um in database terms are called tables.

Marcus: All right, tables.

Devon: And the cardinal rule of this cabinet is one kind of thing per drawer. You have a drawer for tasks, a totally separate drawer for customers, and another drawer for suppliers.

Marcus: So you don't mix them up. And what happens when we pull one of those drawers open?

Devon: Inside the drawer, you have folders, which are called records. So you have one folder per task or one folder per customer. But here is the mechanism that makes the whole thing actually work. Every single folder in a specific drawer must be the exact same shape.

Marcus: Wait. What do you mean by the exact same shape?

Devon: I mean it has the same tabs, the same printed boxes to fill in, in the exact same order. If the task drawer demands a due date box and a title box, well, every single folder in that drawer must have those boxes, even if they're left completely blank.

Marcus: See, I have to challenge this straight away.

Devon: Go on.

Marcus: Why do we need all this rigid ceremony? Why not just save things however we want? I mean, if I want to jot down a task on a sticky note and toss it into the cabinet, why shouldn't the system let me?

Devon: Because it turns into chaos.

Marcus: But imagine a medical records office that doesn't bother with identical folders. They just use shoeboxes, right?

Devon: Oh, the shoebox method.

Marcus: Yeah. A doctor writes a note on a napkin, tosses it into the patient A shoebox. An X-ray gets shoved in sideways. A referral letter is just folded in half. It feels faster in the moment.

Devon: It always feels faster in the moment.

Marcus: But when the receptionist actually needs to find something, it turns into a terrifying archaeology dig. I mean, they are pulling out receipts, half-filled forms, a letter from five years ago, just desperately trying to piece the history together.

Devon: And that archaeology dig is precisely what happens to software without a rigid structure. The common story told to beginners is that flexibility is fast and liberating. You know, just throw the data in, figure it out later.

Marcus: Right.

Devon: The reality is that without structure, a computer cannot search. When a computer looks for a specific due date across ten million folders, it does not read them one by one like a human.

Marcus: Wait, it doesn't?

Devon: No. Uh it calculates the exact physical memory address where that date should be, and it skips straight to it.

Marcus: Oh, wow.

Devon: Yeah. But it can only do that if every single folder is an identical shape. We call this labelling system the schema.

Marcus: The schema.

Devon: Yes. The schema dictates the rigid shape of the folders. It is a set of deliberate decisions about what your system is allowed to know.

Marcus: So this ruthless sameness is not a punishment for the beginner, then. It is the fundamental law of the application's memory. It stops half-versions of records from just drifting apart over time.

Devon: Exactly that. It is the only way a system survives at scale. It makes searching incredibly fast, and crucially, it allows multiple parts of your software to use the cabinet at the exact same time without causing absolute chaos.

Marcus: Because they all expect the same shape.

Devon: Right. If the mobile app and the website both reach into the cabinet at the exact same millisecond, they both need a guarantee that the folder they pull out will be exactly the shape they expect.

Marcus: Okay, that makes sense. But the natural next step in building an app is wanting to change it, right?

Devon: Of course.

Marcus: You have this perfectly organised cabinet, you have launched your beginner app, and a week later, you realise uh you need a new feature. Let's say I want to add a priority dropdown to my tasks.

Devon: Okay.

Marcus: The obvious, very human instinct is to just walk up to the cabinet, pull out the folders, and draw a little priority box on them with a red pen. We want to change the database live, right then and there.

Devon: And that instinct is the most dangerous trap for anyone making software.

Marcus: Really? The most dangerous.

Devon: Absolutely. The common story is that changing things live is the fast, efficient move. You are the sole founder, you own the app, so why not just tweak the drawer?

Marcus: Yeah, exactly. Why not?

Devon: Well, the reality is that a fast move quietly destroys your history, your ability to review changes, and your ability to undo mistakes.

Marcus: Because if I just reach in and rip out a drawer or, you know, change the shape of a form on the fly, there is no paper trail.

Devon: None at all.

Marcus: So if something breaks ten minutes later, I have no record of what the cabinet looked like before I took a pen to it.

Devon: Right. A cabinet missing a drawer looks perfectly fine from the outside, right up until the day the application reaches for it, grabs empty air, and the entire system crashes.

Marcus: Just totally breaks. Yeah.

Devon: You cannot change the schema live. Which brings us to the strictest rule in all of software design. You never rearrange the cabinet by hand.

Marcus: Never by hand. Every single change has to be documented. You know, it reminds me of moving house. If you want to move quickly, you can just throw all your loose belongings into the back of a transit van.

Devon: Oh, yes. Just chuck it all in the boot.

Marcus: Right. It feels incredibly fast. You are making great time on the motorway. But when you arrive at the new house and you desperately need a cup of tea, you have absolutely no idea where the kettle is.

Devon: Spot on. That is the live hand change. It trades long-term sanity for a ten-second burst of speed.

Marcus: But if you use a professional removal firm, they use a numbered inventory.

Devon: Yes.

Marcus: Box 41 contains the kettle and the mugs. Box 42 contains the cutlery. It feels overly bureaucratic when you are packing, it slows you down, but the moment you need to know exactly where something is, well, that numbered inventory list is the most valuable document you own.

Devon: And that physical inventory maps perfectly to how we change database. We use what is called a migration.

Marcus: A migration.

Devon: Yes. Migration is a small, numbered, reversible instruction sheet. So your migration stack might be uh sheet one, create a drawer for tasks, sheet two, add a title box to the task folder, sheet three, add a priority dropdown.

Marcus: I see.

Devon: These sheets are kept forever in chronological order. They are the permanent inventory of your system's memory. Replaying that stack of sheets from sheet one rebuilds the exact same cabinet design every single time, from scratch.

Marcus: Okay, I am going to press you on the human stakes here, though.

Devon: Fair enough.

Marcus: Because we are talking to complete beginners, people who have never written a line of code.

Devon: Sure.

Marcus: And introducing strict bureaucratic rules about numbered instruction sheets and migrations, I well, it sounds remarkably like classic developer gatekeeping.

Devon: Gatekeeping?

Marcus: Yeah. Does this not just make a beginner feel like they can never touch their own data? I mean, they just wanted to add one simple checkbox, and now they're being told they have to submit a formal instruction sheet to their own system. Must they learn SQL, the complex language used to program databases, just to add a box?

Devon: I get why it feels that way. This friction between speed and safety is the oldest debate in software. But I will push back firmly on the idea of gatekeeping.

Marcus: Okay, why?

Devon: Because this discipline is precisely what makes the memory trustable. If you cannot explain exactly, step by step, how your database evolved from day one to the present, you cannot trust it to hold your data safely.

Marcus: So it's about trust, not keeping people out.

Devon: Exactly. However, to address the beginner's fear, no, you never need to write SQL.

Marcus: But SQL is the traditional filing clerk language, isn't it? It is the only language the cabinet understands. So if I'm not writing it, and I'm not allowed to change the cabinet by hand, how does the instruction sheet get written?

Devon: You rely on your tooling. Specifically, your AI agent acts as the highly trained filing clerk.

Marcus: Oh, I see.

Devon: You simply describe the change in plain English. You say, "I want to add a priority dropdown to the task drawer." The AI agent takes that plain English, translates it into SQL, and writes the formal, numbered migration sheet for you.

Marcus: Wait, but if I cannot read SQL, how do I know the AI didn't just write an instruction sheet that says, you know, "delete the entire task drawer"? If I am enforcing this bureaucratic discipline, but I have to blindly trust an AI to write the rules, surely I am right back to a terrifying lack of control.

Devon: And that touches on exactly why changing a database is treated differently to changing a button colour. The tools themselves are acutely aware of how dangerous durable state is.

Marcus: So they know the stakes.

Devon: They do. They are already built to pause at these exact moments. Let us look at what the documentation for these systems actually says. For instance, at the time Anthropic launched Claude Code, their documentation explicitly noted that the agent pauses and asks for your direct permission before running any commands that change things.

Marcus: So it forces a human review.

Devon: Exactly. It forces you to stop. Now, it does allow you to give standing permission for safe routines, but the default posture is a hard stop before altering state.

Marcus: And OpenAI takes a similar stance, don't they?

Devon: Yes. If you look at the documentation for OpenAI's Codex, it states that it uses strict approval policies combined with a physical sandbox to confine the agent.

Marcus: A sandbox, right.

Devon: Yeah. The AI agent physically cannot touch the live database cabinet if it has not been given explicit, scoped permission to do so.

Marcus: So the industry understands the stakes, then. The tooling is designed to enforce a physical pause.

Devon: Precisely. The AI writes the migration sheet and hands it to you. The system halts. It says, "I am about to apply sheet four to the cabinet. Do you approve?"

Marcus: And I don't have to read the raw SQL.

Devon: No. You are just forced to acknowledge that a structural change is happening. You find an honest middle ground. The AI handles the translation into code, but you, as the human owner, enforce the bureaucratic discipline of the migration.

Marcus: Okay, but given that the tools force us to pause, how do we practically manage that moment without fear? Because staring at a prompt that asks, "Do you want to change the database?" still sounds quite terrifying for a beginner.

Devon: It becomes a calm, ordinary routine through two specific habits at the gate.

Marcus: Okay, what's the first one?

Devon: The first is the undo rule. Every single migration you or your AI writes must ship with its own exact undo instruction.

Marcus: Oh, that makes sense.

Devon: If sheet seven adds a priority dropdown, sheet seven's undo instruction must remove that exact dropdown and clean up any mess it leaves behind.

Marcus: You know, it reminds me of a master electrician's habit.

Devon: How so?

Marcus: A good electrician will never just walk up to a complicated fuse board and start pulling wires out.

Devon: Definitely not.

Marcus: No, they will photograph the board first. They document exactly where the blue wire and the brown wire are seated. At the gate, before touching a single live wire, they always ask, "How do we put this back exactly as we found it?"

Devon: That is the perfect mindset. Small step forward, guaranteed step back. If you apply the migration and the system complains, you don't panic. You just run the undo instruction, and the cabinet reverts to how it looked five minutes ago.

Marcus: Brilliant. And what is the second habit we need at the gate?

Devon: The second habit is look before you lock. This is where most beginners accidentally crash their own apps.

Marcus: Okay, how do they do that?

Devon: Well, suppose you decide to enforce a new rule in your schema. You look at your task drawer, and you decide that from this point forward, every single folder must have a due date.

Marcus: Right.

Devon: So you ask the AI to write a migration to lock the drawer down so it rejects any task without a date.

Marcus: Wait, but before I apply that lock, I must look at the folders already inside it. Because if I have been using this app for a month, I probably have fifty old tasks in there that have no due dates.

Devon: Exactly. And if you apply a strict structural rule to a drawer full of old records that do not meet the new criteria, the database engine will panic, and the migration will fail.

Marcus: It is like a local library announcing a strict new policy. You know, um, "every single book in this building must have a scannable barcode."

Devon: Right.

Marcus: But they don't bother to check the shelves first. They just turn the security gates on.

Devon: Which is a disaster waiting to happen.

Marcus: Totally. So on day one of the new rule, a patron brings up an antique reference book from the 1970s that only has a stamp on the inside cover, and the system just completely rejects it. The library's new rule breaks against their own existing books.

Devon: That is exactly what happens. Verify, then constrain. That is the order of operations.

Marcus: Verify, then constrain.

Devon: Yeah. You run a quick search to find those fifty old tasks with no dates. You manually give them a date, or you assign them a default value like, ah, sometime in the future. You fix the stragglers, and only then do you apply the strict new lock to the cabinet. Look before you lock.

Marcus: I want to talk about the horrifying, yet slightly amusing edge of all this, actually.

Devon: Oh, here we go.

Marcus: Because there is a very human comedy to how badly things go wrong when teams try to avoid the strictness of migrations and rely on manual descriptions instead.

Devon: Oh, you mean handwritten documentation of a database schema? It is a widespread anti-pattern.

Marcus: Absolutely widespread. A team will sit down and write a beautiful, comprehensive document, usually in a company wiki or a shared Notion page, describing their entire cabinet.

Devon: Yes. Drawer A has these folders, Drawer B has these folders, these are the rules.

Marcus: And they maintain this document entirely by hand. And within weeks, due to sheer human drift, the document quietly starts lying to them.

Devon: It is rarely malicious dishonesty, to be fair. It is just the reality of friction.

Marcus: Right.

Devon: Someone authorises a tiny hand change to the database, late on a Friday, to fix a bug. They mean to update the manual document on Monday, but they forget.

Marcus: And suddenly, the map no longer matches the territory. The brochure says the task drawer has a priority field, but the actual database does not.

Devon: And six weeks later, a new developer joins the team. They read the handwritten document, they trust the lie implicitly, they write code based on it, and they bring the whole system down.

Marcus: It is the terrifying archaeology dig all over again, just disguised as neat, official paperwork. The brochure is quietly drifting out of date.

Devon: Contrast that fragile setup with people who own real, serious systems, and I include complete non-coders in this, people building substantial businesses on their own software. You speak to them, and they are managing massive cabinets containing fifty to eighty different drawers.

Marcus: Fifty to eighty different tables. That is a massive amount of structure to keep in your head.

Devon: But they do not try to keep it in their head, and they do not write manual brochures. Beside their cabinet sits a stack of perhaps two hundred numbered migration sheets going all the way back to sheet one.

Marcus: Wow. Two hundred sheets.

Devon: Yeah. They trust their systems completely because nobody ever in the entire life of the software has changed the cabinet by hand. That stack of migrations is the honest biography of the software. If you want to know what the database looks like, you don't read a wiki, you read the migrations.

Marcus: So the fix for the lying document is to stop writing the brochure altogether. You generate your description from the cabinet itself.

Devon: You let the actual truth of the database generate the record. The migration stack is the single source of truth. It is immune to human drift because the database physically cannot change unless a migration is run.

Marcus: Let's bring this all back down to earth for the listener, then. The beginner who is staring at their screen right now, wondering how to manage their app's memory without breaking it. We have covered a lot of ground, from durable state to AI tooling. What is the single, grounded action they need to take?

Devon: The concrete takeaway is this. The migration stack is the real, trustworthy record of your software's memory. It is your inventory, your history, and your undo button, all rolled into one. Rely on your AI to write the syntax, but you must enforce the system.

Marcus: And the one unbreakable rule you must carry away, the strictest rule in all of software design. You never rearrange the cabinet by hand.

Devon: Never by hand.

Marcus: Whenever you want to change where things live, you use a migration. You always ask how you would put it back before you change a single thing.

Devon: If you maintain that discipline, even if you are building an app entirely on your own without writing a line of code, your software will never forget what it is supposed to remember.

Marcus: It is that simple and that profound. So to leave you with a final thought to mull over as you step away from this deep dive, look at the systems, the habits, or the records in your own life and work right now, completely outside of software. Where are you relying on a handwritten brochure that is quietly drifting out of date and lying to you, instead of letting the actual truth generate the record? Until next time, keep building.