How to Build Software with AI | Ep 10: Shipping, and Being Responsible

Transcript

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

Marcus: You know, the common story you hear about finishing a massive 10-part journey building software with AI is that shipping the final product is this grand, exciting climax.

Devon: Oh, absolutely. The prevailing narrative is that it's this dramatic Hollywood moment, you know? You throw open the doors, watch the user metrics spike, and just take a bow.

Marcus: A real ribbon-cutting ceremony for code.

Devon: Exactly. There's this persistent cultural expectation of a big green button. You push it, fireworks go off on screen, and your application is suddenly out in the wild, transforming the world.

Marcus: But the reality of going live responsibly is, well, it's deliberately, unapologetically boring.

Devon: Truly boring.

Marcus: Right. It is not a ribbon-cutting moment at all. Responsible shipping is staged, it's meticulously logged, and it is firmly pinned.

Devon: I love that. Staged, logged, pinned.

Marcus: So, in this final deep dive into the beginner series on building software with AI, our mission isn't about the mechanics of generating code or celebrating a launch.

Devon: No, we're past that.

Marcus: Yeah. It's about unpacking what it actually means to go live safely. And underpinning this entire process is one golden rule, really. There is one specific gate that never, ever opens early, and that is real people's data.

Devon: The contrast there is just fascinating to me, between the sheer velocity of building with AI and the gravity of releasing it. I mean, when you are writing prompts and testing logic, you're basically in a playground.

Marcus: Right. Breaking things is just part of the discovery.

Devon: Exactly. But the moment that theoretical architecture becomes concrete, the stakes shift entirely. You move from a space of infinite undo buttons to a reality where breaking things has actual human consequences.

Marcus: And to understand how we control those consequences, I mean, we really need to look at the geography of live software.

Devon: The geography?

Marcus: Yeah, because you might assume your application is just one monolithic entity, you know, the app living in one single place. But the source material outlines three very specific, distinct environments, and crucially, they are allowed to differ.

Devon: Which feels deeply counter-intuitive when you first start building. You sort of assume you write the code, and that code is the application, full stop.

Marcus: Well, software actually exists in phases of trust. The first environment is the workshop.

Devon: Which is your local machine, right?

Marcus: Right, exactly, your laptop. And let's talk about the mechanics of the workshop. It's messy, it's incredibly fast, and it is entirely private to you. In the workshop, you might bypass the security login entirely just to test a database query faster.

Devon: Because you take massive shortcuts when you're just testing isolated ideas.

Marcus: Yeah, and because no one else is watching, it's a space where bad decisions are safe precisely because they are quarantined to your laptop.

Devon: But you obviously cannot invite the public into the workshop.

Marcus: No, definitely not. So, you move to the second building, which is the practice room. And this is entirely different from your local machine.

Devon: How so?

Marcus: It's a disposable, clean environment that gets rebuilt from scratch for every single change you want to test.

Devon: Wait, how does that rebuilding actually work in practice? I mean, are we talking about manually setting up a server every single time?

Marcus: No, not at all. In modern workflows, the practice room is an automated staging environment. When you propose a change to your code, a system just spins up a temporary replica of your entire application in the cloud.

Devon: Oh, I see.

Marcus: It installs the dependencies, it runs the database migrations, and it boots up. It's a sterile laboratory designed to prove your changes work outside the messy context of your workshop. And once you verify it works, you just tear that temporary room down.

Devon: So, it exists solely to validate the code in a clean space.

Marcus: Precisely, which leads us to the third building, production.

Devon: Ah, the scary one.

Marcus: The real one. This is the real copy that real people use. It holds real information and carries real consequences. When someone asks, you know, "Is it in production?", they're asking if it is out in the wild, being relied upon by actual users.

Devon: The spatial geography of this is what makes it so safe. Staging your releases through these three buildings is essentially a masterclass in risk management.

Marcus: It really is.

Devon: And the source uses a rather brilliant analogy here. Think about how a truly excellent restaurant opens. They don't just unlock the front doors on night one, hand out menus, and hope the kitchen can keep up.

Marcus: No, they spend weeks in the kitchen first. That's the workshop, testing recipes on colleagues, figuring out the timing.

Devon: Exactly. Then, they do a soft launch. They invite friends and family, offer a very small menu, and perhaps charge half price. The crucial mechanism of the soft launch is that everyone in the dining room is briefed.

Marcus: Right, they know the service might be wobbly.

Devon: They're forgiving diners, and that is the practice room.

Marcus: Yes. And only after that trial by fire do they open to the public, production. And even then, wise restaurateurs start with a short menu that slowly grows.

Devon: But what is really interesting culturally is how people perceive this caution. I mean, new builders often mistake this staged approach for cowardice.

Marcus: They really do.

Devon: They think needing a soft launch means you lack confidence in your own code. But in reality, it's incredibly smart staging. Each stage looks more and more like the real thing, and each stage is allowed to differ, as long as everyone involved knows exactly how it differs.

Marcus: Right. Staging is not fear, it's the ultimate expression of control. But look, that raises a really important issue. If the workshop takes shortcuts that production never would like, bypassing that security login we mentioned earlier, how do you stop those shortcuts from becoming hidden traps?

Devon: Because a shortcut taken in the workshop, if you forget about it, becomes a catastrophic failure the moment it gets pushed to production.

Marcus: Exactly. You assume the security login works because you haven't looked at it in three weeks, having bypassed it locally.

Devon: So, how do you keep track of the differences?

Marcus: Well, this brings up a mechanism borrowed straight from aviation, actually. Aviation handles this exact problem of known imperfections beautifully. Aircraft routinely fly with known minor faults.

Devon: Like what?

Marcus: Uh, maybe an oven in the galley might not heat up, or a redundant gauge might act erratically. The aircraft still flies safely and legally.

Devon: Oh, wow. I didn't know that.

Marcus: Yeah, and the reason it's safe is that those faults are not hidden. They're logged in what aviation calls a deferred defect list.

Devon: The pragmatism of that is brilliant, honestly. It acknowledges that demanding absolute perfection before takeoff would mean no plane ever leaves the ground.

Marcus: Right.

Devon: But it makes transparency mandatory. You can fly with a broken oven, provided the crew knows the oven is broken.

Marcus: We use the exact same analogue in software. It's called a deviation. When your workshop or practice room does something that production never would, you don't just make a mental note to fix it later. You log it formally.

Devon: What does that look like?

Marcus: The mechanism for logging a deviation requires three very specific lines. First, you state what differs. Second, you explain why it is acceptable in this specific environment. And third, you define what production will do instead.

Devon: Let's ground that in a practical example for the listener. Say you are building an AI tool that analyses large PDF documents. In your workshop, generating a real analysis might take, say, two minutes and cost money in API fees.

Marcus: Yeah, that adds up fast.

Devon: So, as a deviation, you hardcode a fake response that appears instantly. What differs? The response is fake. Why is it acceptable? Because you are just testing the user interface layout. What will production do? It will call the actual AI model and wait two minutes.

Marcus: That written record is so important because it transforms the human element from a trap into a decision. A recorded shortcut is a boundary you have deliberately drawn.

Devon: Whereas a hidden shortcut is just a trap with a delay on it.

Marcus: Exactly. It's just waiting for the day you assume production works exactly like the workshop, and the whole system comes crashing down. A register of deviations is essentially you saying, "I know exactly where my pragmatism lives."

Devon: But logging those deviations only keeps the environment safe. It doesn't solve the history problem.

Marcus: What do you mean?

Devon: Well, if your application crashes on a Tuesday, knowing your deviations doesn't help if you don't know exactly which version of the application caused the crash. You need a historical record of what actually went out the door.

Marcus: Ah, right. Which is where we introduce the concept of the pinned release. If deviations manage the differences between environments, pinned releases manage the history of what gets shipped. The source uses the analogy of a food jar in your cupboard.

Devon: The batch number.

Marcus: Yes. Look at any jar of food, and it has a batch number printed on the glass.

Devon: And that batch number is the entire foundation of food safety. I mean, if a contaminant is found, the recall doesn't say, "Bring back all the jam."

Marcus: Right, that would be chaos.

Devon: It names precisely which batch number is affected. Every other jar on the shelf remains trusted because the system knows exactly what went out the door and when.

Marcus: So, translating that to code, what does a pinned release actually look like technically?

Devon: It means you never just deploy whatever is newest in your main folder. When you are ready to move from the practice room to production, you freeze the code. You attach a specific, immutable version number to it, let's call it version 402.

Marcus: Okay.

Devon: That version is packaged as a single, unchangeable unit. It is your batch number. So, when someone asks, "What is running in production?", the answer is never the latest update. The answer is exactly version 402.

Marcus: You know, this completely changes the emotional reality of shipping software. Think about the absolute terror you feel when you're about to push your application live. You're terrified of breaking something that users are relying on.

Devon: Yeah, with the sweat on the palms.

Marcus: Right. But when you ship as a pinned, immutable release, you eliminate that terror.

Devon: Because you've eliminated the ambiguity. If version 402 goes live and immediately starts throwing errors, you don't perform panicked heroics. You don't dive into the live server at 3:00 in the morning, frantically rewriting lines of code while users are staring at broken screens.

Marcus: You just take the bad batch off the shelf.

Devon: Exactly that. You calmly, quietly roll the system back to the previous known good batch. You tell the server, "Stop running 402, start running 401 again." It takes seconds.

Marcus: And then you take 402 back to the workshop and investigate it in peace. It transforms shipping from a high-wire act into a completely mundane administrative task. As I said, drama is for television. Engineering should be entirely, resolutely boring.

Devon: So, we have built a process that is safely staged across three environments, where faults are logged meticulously, and releases are pinned immutably. If the entire operation is this controlled, it begs a massive question.

Marcus: What's that?

Devon: Is there anything in this process you absolutely cannot rush or defer?

Marcus: Oh, the data. Specifically, real people's data.

Devon: This is the one gate you never rush.

Marcus: We've been talking a lot about code, but this is where the stakes stop being about broken logic and start being about human liability. There is this pervasive cultural narrative that held data is an asset. Companies constantly talk about data as the new oil.

Devon: Right, you hear that everywhere.

Marcus: But for you, building a system, held data is not an asset sitting in a vault. It is a liability that you owe care on every single day you hold it.

Devon: The moment a system holds real names, real email addresses, or real records of actual humans, you quietly take on a duty of care. The source compares it to opening a nursery.

Marcus: And it's a perfect comparison, really. You don't throw open the nursery doors, let the children in, and then, uh, figure out your safeguarding checks on the fly.

Devon: No, definitely not.

Marcus: The checks are the precondition of the doors opening at all. The source has a fascinating, if horrifying, edge to this. It contrasts the builders who held the line on this rule against those who didn't.

Devon: The builders who refused to let real data in until the paperwork is done say it feels slow exactly once. It's annoying at the start when you want to move fast, but it pays off at every subsequent audit, every client question, every security review.

Marcus: And the builders who rushed the gate?

Devon: They end up doing what the source memorably describes as archaeology, where the dig site is on fire.

Marcus: God, the mechanics of why that is on fire make me physically wince as an engineer. Just think about it. You have a live application. Users are actively clicking things, generating new data, updating their profiles.

Devon: It's moving constantly.

Marcus: Yeah, and meanwhile, you are digging through your own databases trying to figure out where personal information is stored so you can protect it.

Devon: We're retrofitting data protection onto a system that is actively running. Artifacts of personal information are scattered across different tables, logs, and backups, and the whole thing is a blaze because real people's privacy is actively at risk while you are doing the archaeology.

Marcus: It's a nightmare.

Devon: Slow once, or slow forever in a state of sheer panic. That is the actual trade-off you're making.

Marcus: And we have to be absolutely clear on the stakes here. This isn't just about being polite or having good engineering hygiene. In the UK and Europe, the General Data Protection Regulation, the GDPR, makes this a strict legal requirement.

Devon: It's not a courtesy to your users.

Marcus: No. Knowing exactly what data you hold, why you hold it, and how it can be deleted is mandated by law.

Devon: But hang on, I'm looking at this workflow, and if mapping databases for compliance is this deeply tedious, how do you actually get it done without drowning in administration?

Marcus: Well, this is where modern AI tools come into their own. Tools like Claude Code or Codex can do the heavy lifting. The source explains a mechanism for this. You can carry your shipping rules in a simple text file like `claude.md` or `agents.md` right in the root directory of your project.

Devon: Wait, how does a text file actually govern the AI?

Marcus: Because these AI agents are designed to scan your root directory before they execute any commands. Placing an `agents.md` file there acts as an automatic filter.

Devon: Interesting.

Marcus: It forces the AI to read your compliance rules before it writes a single line of code. You can literally ask the agent to walk through your database schema, identify every single field that could potentially hold personal information, and draft a perfect, tedious data inventory in minutes.

Devon: Oh.

Marcus: It does the exact kind of careful, monotonous work that humans hate and usually get wrong.

Devon: But wait, no, I have to stop you there. Doesn't that completely defeat the purpose of the safety gate? You are turning a legal duty of care into an automated click.

Marcus: I wouldn't say it defeats the purpose, it just removes the friction of the drafting.

Devon: But human nature dictates that if the friction is removed, the critical thinking often goes right out the window with it. I mean, if the machine drafts the data inventory instantly, you are just going to blindly wave it through. The AI says the paperwork is done, so I'm opening the doors. It turns a profound, legally binding responsibility into a rubber-stamp exercise. If you don't have to sweat over the document, do you actually understand the liability you're taking on?

Marcus: That is a fair concern, but the boundary the source outlines is incredibly sharp here. Automating the drafting of the paperwork is absolutely not the same as automating the decision to use it.

Devon: I don't know.

Marcus: Hear me out. The AI can draft the inventory. It can map the schema perfectly. But deciding to actually take on that duty of care, deciding to say, "Yes, I am ready to be legally responsible for these real humans," requires a signature. That is a director's call. The AI cannot make the choice to open the gate. That final approval rests squarely on your shoulders.

Devon: I hear that distinction, I do, but I remain deeply sceptical that a builder, staring at a perfectly formatted AI document and desperate to launch their project, will pause to feel the weight of that director's call. The temptation to just accept the AI's homework and declare the gate open is overwhelming.

Marcus: You think the friction is necessary.

Devon: The friction was the very thing that forced the pause.

Marcus: Perhaps that is the ultimate test of building in this era, though. The tools strip away the excuse of administrative burden. You can no longer say, "I didn't do the privacy checks because the paperwork was too hard." The paperwork takes three minutes.

Devon: Right.

Marcus: So, the only thing left is the stark human choice. Do you take this responsibility seriously or not? It is the last and most important human judgement the entire series teaches.

Devon: It leaves the tension entirely on the human side of the screen. The machine did its part flawlessly. Any failure from that point on is entirely a failure of human governance.

Marcus: We can leave that tension sitting right there, honestly, because the standard itself is unflinching, regardless of how you draft the documents. Which brings us to the practical reality. How do you actually hold that line?

Devon: You bypass the grand visions of the future, and you implement a concrete rule.

Marcus: The practical, concrete takeaway for anyone building software is this. You build entirely with invented, fictional people until the day you can answer five specific questions in writing.

Devon: The five questions that replace the champagne launch.

Marcus: Question one, what personal data do you hold? Question two, why do you hold each piece? Question three, for how long do you keep it, and what happens to it then?

Devon: Crucial ones, yeah.

Marcus: Question four, how does someone remove their data or see what you hold? And question five, who exactly can access it?

Devon: Five questions written in plain English, taking up barely a single page. But answering them transforms you from someone playing with code in a workshop into someone operating a live system with actual responsibilities.

Marcus: Your system needs realistic data to be built well. You need names, addresses, and complex records to test the architecture and ensure the database relationships work. But it absolutely does not need real humans to be built well.

Devon: No, just generate the fake data, hold the line.

Marcus: It is the ultimate boundary between the practice room and production. It is the gate you never rush.

Devon: Absolutely.

Marcus: So, the next time you hear someone talking about the thrill of shipping software, the grand opening, the champagne launch, ask yourself what their deviations register looks like. Ask yourself if they are staging their releases or just hoping for the best.

Devon: And most importantly, ask yourself if they answered those five questions before they let the first real human walk through the door.

Marcus: Because if they didn't, they aren't visionaries throwing open the doors to the future.

Devon: No, they're just archaeologists standing in a dig site wondering why everything is on fire.

Marcus: And on that note, we leave you to look at your own projects. Are your shortcuts logged? Are your releases pinned? And when it comes to the data of real people, are you truly ready to hold the line?

Devon: It's the only thing that matters.

Marcus: That is a question only you can answer.