How to Build Software with AI | Ep 1: You're the Director Now

Transcript

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

Devon: For about 70 years, the only way to make software was a human being sitting at a keyboard, typing instructions character by character in a highly complex language. If you wanted software, you needed that person. Well, that entire paradigm has just collapsed.

Marcus: It really has. I mean, the barrier to entry, the physical, mechanical act of typing code has essentially fallen to zero.

Devon: Which means we are standing at the edge of a massive cultural and professional shift. And, that is exactly why we're launching this specific series. This is part one of a 10-part deep dive where we are unpacking a comprehensive guide for non-coders on how to build real working software with AI.

Marcus: Right. And right at the top, we should probably establish the house style for this series. Absolutely no hype and no doom narratives.

Devon: Exactly. We are not indulging that fantasy where an AI magically builds a flawless business while you sleep on a beach.

Marcus: No. And nor are we spinning a dystopian tale about the end of human work. We are taking an accurate, plain-language look at what building software actually entails when you no longer have to write the code yourself. Because, you know, the hard part of software development hasn't disappeared. It's just relocated.

Devon: Relocated. Right. And if you're listening to this right now, whether you are a small business owner, an academic researcher, maybe someone working in a charity, or just insanely curious about where technology is actually heading, this matters directly to you. You are about to learn the new rules of directing software, rather than typing it.

Marcus: Spot on. But to understand how to direct it, we first have to understand the underlying engine, don't we?

Devon: Yeah, if typing code isn't the barrier anymore, what exactly has taken its place? Let's get straight to the mechanism.

Marcus: Well, the core new concept you need to grasp immediately is the agent. And we have to define this clearly because literally everything in this new landscape hangs off it. An agent is not a chatbot.

Devon: Okay, so it's not just me asking a question and getting an answer?

Marcus: Exactly. A chatbot is something you ask a question, it gives you an answer, and it stops. An agent is an AI that you give a goal to.

Devon: So, uh, instead of me being a driver steering a car, constantly asking the machine to turn left, turn right, speed up, I'm, I'm getting in the back seat of a taxi and just giving the agent the destination address.

Marcus: That is a brilliant way to picture it. It handles the pedals, watches the traffic, navigates the diversions. Mechanically, giving an AI a goal means the agent can take autonomous actions to pursue that outcome.

Devon: Right.

Marcus: Think of an agent as an AI with virtual hands and eyes. When it writes code, and that code inevitably fails, the agent doesn't just throw up its hands and wait for you. It actually reads the red error text on the screen.

Devon: Oh, wow. So it's actively debugging its own work?

Marcus: Yes. It goes back into the file, erases the bad line, types a new one, and hits run again. It might execute that feedback loop 50 times a minute until the software works. It's much less like asking a knowledgeable friend a trivia question, and much more like hiring a highly capable, incredibly fast contractor to do a job.

Devon: A contractor. Okay, let's ground that with a real-world parallel. If I'm not typing the code, but I am managing this autonomous contractor, what is my actual role in all of this? I mean, I'm sitting at a desk looking at a screen, what am I doing?

Marcus: Well, think about the last time you or someone you know had a new kitchen fitted. You didn't plumb in the dishwasher, did you?

Devon: Definitely not.

Marcus: Right. You didn't wire the oven, you didn't chase the electrical cables into the plaster, or cut the bespoke worktop around the sink. A fitter did all of that because fitting a kitchen is a highly skilled trade.

Devon: Sure.

Marcus: But when the job was done, nobody stood in that room and told you that you didn't make the kitchen. Of course you did. You decided a new kitchen was needed. You chose the layout. You decided exactly where the rubbish bin should go.

Devon: Right. I walked through the finished job, opened every drawer, ran the taps, and, uh, pointed at the one cupboard door that didn't close properly before handing over the final payment.

Marcus: Exactly. You were the director. You made the decisions. Someone else's hands did the fitting. And notice what you didn't do in that kitchen scenario. You didn't micromanage the hammer. You managed the outcome.

Devon: I see.

Marcus: And this is where we hit the crucial turn in how we think about AI. The common story you see in every headline is that AI writing code makes the human redundant. But the reality is the exact opposite. The human becomes the whole game.

Devon: Because the skill of building software was never really the typing.

Marcus: Spot on. The typing was just the medium. The actual skill was the underlying judgement. And when the building process gets exponentially faster, well, that human judgement becomes far more critical, not less.

Devon: Let's follow that thread. Because if we have this incredibly fast, tireless AI builder and we just sit back as director, that sounds brilliant on paper. But speed introduces a massive hidden risk. There is a dark, almost horrifying and amusing edge to this.

Marcus: Oh?

Devon: Returning to your kitchen analogy, if I build a kitchen badly, an unfinished kitchen looks entirely unfinished. You know, there's a copper pipe sticking out of the wall, water leaking onto the floor, a massive hole where the oven should be. You simply cannot miss it.

Marcus: It announces its own failure.

Devon: Exactly. But unfinished software, it often looks completely finished, and that is incredibly dangerous.

Marcus: It is the single biggest trap for the non-coder.

Devon: Mm.

Marcus: A login page with absolutely no real security underlying it looks utterly identical to a login page with military-grade encryption.

Devon: Right.

Marcus: An application that quietly loses one customer record in every 100 looks exactly like an application that never loses anything right up until the day it matters and the whole thing catches fire. Software's surfaces simply do not reveal its insides.

Devon: But why is that? What is it about an AI agent that makes it produce these polished facades?

Marcus: Well, generating the visual layer, the buttons, the layout, the colours, is mathematically very easy for an AI. Its training data is just full of beautiful front-end templates. It knows exactly what a secure banking login screen looks like visually.

Devon: Right, it can mimic the design perfectly.

Marcus: Exactly. But setting up an actually secure database requires abstract, structural logic that doesn't have a visual representation. So the agent paints a very nice front door on a house with no walls.

Devon: Which means checking the work becomes intensely difficult. You know, when human developers were building software, the process was notoriously slow and expensive. But that slowness was actually serving a structural purpose, wasn't it?

Marcus: It really was. The slowness itself was the natural quality control. A professional developer spent weeks deep inside the minutiae of the code. Because they were moving at a human pace, they tended to notice what was missing.

Devon: They spotted the edge cases.

Marcus: Exactly. They realised that if a user clicked a button twice, the system would crash. But fast, agentic building strips that natural quality control out entirely. When an agent can produce something that looks beautifully complete in a single afternoon, the looking-complete problem gets exponentially worse.

Devon: So who actually pays for this when it goes wrong? Because we're talking about a totally different demographic building software now. We aren't talking about a Silicon Valley engineering team with a dedicated quality assurance department.

Marcus: No, not at all. The people building these tools now are the non-coders themselves. It's the small business owner who desperately needs a bespoke booking system but cannot afford a £50,000 development agency.

Devon: Or an academic researcher trying to wrangle 10 years of messy notes into a searchable database.

Marcus: Right. It's people in marketing, in charities, in law, tradespeople.

Devon: And they are the ones carrying the ultimate risk. They are building the specific tools their daily work needs, but they're suddenly holding the bag when something looks finished and isn't. And that leads to the absolute nightmare scenario.

Marcus: The security issue.

Devon: Yes. Imagine you run a charity and you use an AI agent to build a database to hold highly sensitive information about vulnerable people. You log in, you see a padlock icon, you see a password field, and you assume it's secure.

Marcus: But it isn't.

Devon: Right. A month later, you discover the security was switched on, yet quietly protecting absolutely nothing. Anyone on the internet could query the database by just changing the web address slightly. It is a terrifying prospect.

Marcus: It's more than a prospect, honestly. Field interviews with early adopters show this exact trap happens constantly. The agent did exactly what you asked. It built a login screen.

Devon: Mm.

Marcus: But if you didn't specifically instruct it to secure the underlying database against unauthorised server requests, it simply didn't do it.

Devon: I can hear people listening to this right now feeling a massive wave of imposter syndrome. They're thinking, 'Um, I struggle to set up the Wi-Fi on my smart TV. There is absolutely no way I have the technical discipline to direct an AI to build a secure database without it blowing up in my face.' What is your response to that intimidation factor?

Marcus: My response is that the discipline required to pull this off isn't coding discipline. You do not need to learn to read the code. The discipline required is process discipline.

Devon: Process discipline?

Marcus: Yes. If you know how to run a complex project, if you know how to manage a team of tradespeople, or organise a major charity event, you already have the exact skills required to direct AI software development. The job of the director boils down to a practical spine of three repeated steps: decide, brief, verify. You just do these three things over and over again.

Devon: Okay, let's pull those apart, starting with step one: decide.

Marcus: Right. Decide what is being built, and just as importantly, decide what is not being built. What does done actually mean? What must this software never do? It sounds obvious, but most bad software, much like a bad kitchen, comes from decisions that nobody quite made.

Devon: The client sort of assumed, the builder sort of guessed.

Marcus: Exactly. You have to make decisions explicitly, and you have to put them in writing.

Devon: Give me a concrete example. Say I'm that small business owner and I want an inventory app for my warehouse. What am I deciding?

Marcus: You're deciding the boundaries. You explicitly write down, 'This app will track stock levels in real time. It will not process payments. It will not connect to our accounting software. It must require a staff ID to log a stock removal.'

Devon: And if you don't decide those boundaries?

Marcus: Then the AI will try to guess your intentions, and it will likely build a bloated, confusing mess that attempts to do everything poorly.

Devon: Which brings us to the actual communication bottleneck. Step two: brief. I imagine this is where most non-coders fall down, assuming the AI has common sense and can essentially read their mind.

Marcus: Oh, entirely. A brief is an instruction the agent cannot misread. Agents are astonishingly capable, but they're also completely literal. Let's take your inventory app.

Devon: Mm.

Marcus: If you give an AI a vague brief like, 'Build me an app to manage my warehouse stock,' you won't get an error message.

Devon: No, of course not.

Marcus: The agent won't stop and politely ask you to clarify whether you want barcode scanning or manual entry. It will just confidently invent features you don't need and omit the ones you do. You will get a polished, wrong thing.

Devon: So a good brief leaves no room for interpretation. You're describing the exact data you want to track, the specific user roles, the constraints, and what finished actually looks like.

Marcus: Precisely. Writing a rigorous brief is the single biggest lever you have over the quality of the final product.

Devon: But then we hit step three, which is, frankly, the most daunting for a non-coder: verify. If I have just written a brilliant brief, and the agent spends 10 minutes generating a thousand lines of code, and presents me with a beautiful interface, how do I actually verify it without reading the code?

Marcus: Verifying means asking for evidence and checking outcomes.

Devon: Mm-hmm.

Marcus: It's the walk-through before you pay the kitchen fitter. You refuse to let anything count as done until you have seen it be done in front of you. Does the page actually load? Can the wrong person actually be kept out?

Devon: But how do I test that? I mean, I don't know how to act like a hacker to test my own security.

Marcus: You don't have to. You make the agent do it.

Devon: Wait, really?

Marcus: Yeah. You literally type to the agent, 'Write an automated script that attempts to log in to this database with a fake password 100 times, and show me the plain English log of it failing.' You're forcing the AI to play the role of an adversary against its own code.

Devon: That is clever. You don't read the code it wrote to build the app, and you don't read the code it wrote to test the app. You just read the final report. You demand evidence that the outcome was achieved.

Devon: That is a phenomenal mental shift. The hard parts these builders hit are the director's parts. It's deciding clearly, briefing precisely, keeping honest records, and checking the work meticulously. As you said, these are highly transferable skills from everyday project management.

Marcus: That is exactly why non-coders can genuinely succeed at this. The agent handles the syntax, you handle the logic.

Devon: I buy into process discipline completely. That sounds robust. But we have to talk about the other end of the spectrum because there is a bit of a wild west element to AI development right now. I want to bring up the term 'vibe coding', and I have to push back hard on this concept.

Marcus: Go on.

Devon: From everything we just discussed about unfinished software looking finished, the idea of vibe coding sounds like a guaranteed recipe for disaster. Letting an AI build something that you do not understand and that you do not rigorously verify sounds like professional negligence.

Marcus: I understand the hostility towards the term, but I am going to defend vibe coding, provided it's used in the right context. The term was coined by AI researcher Andrej Karpathy in early 2025. He used it to describe a workflow where you ask for what you want, you accept the visual result, and you do not read the code or run rigorous tests, you just look at what it does. If it feels right, if the vibes are good, you keep going.

Devon: But that is exactly my point. If it feels right. We just established that a fake login page feels right until a bad actor downloads your entire customer database and you are facing a massive privacy fine. Vibe coding sounds like the last thing someone does before their business collapses. That's not engineering. That's just hoping for the best.

Marcus: You're assuming that all software holds sensitive customer data or runs mission-critical operations. Vibe coding got an unfair reputation as a punchline because people applied the term to the wrong types of software.

Devon: Mm-hmm.

Marcus: Vibe coding and disciplined agentic engineering are not rivals. They are two ends of one spectrum.

Devon: Okay, map that spectrum out for me. Because I'm struggling to see where hoping it works is ever a valid professional strategy.

Marcus: Think about the stakes of what you're building. If you are building a little bespoke tool to automatically rename your messy folder of holiday photos by date, or a quick web calculator to split a complex restaurant bill among 12 friends, or, I don't know, a simple trivia game for a child's birthday party, if it breaks, what actually happens?

Devon: Well, I suppose if the holiday photo renamer glitches, it might accidentally rename all my wedding photos to 'seagull 01'. Annoying, but not a crisis.

Marcus: Exactly. Nobody is hurt, no sensitive data is leaked to the internet. You simply delete the tool and ask the AI to build another one in three minutes. The stakes are functionally zero. In that scenario, applying rigorous process discipline, writing a multi-page brief, and demanding automated security tests is a massive waste of your time.

Devon: Fair enough.

Marcus: Just vibe away. Ask for the tool, click the button, and if it works, use it.

Devon: Right, I can see the low-stakes toys. If it doesn't matter if it breaks, you don't need to over-engineer the oversight.

Marcus: But as you move along the spectrum, the rules change entirely. Say you build a tool that your entire team starts using every day to track warehouse inventory. You're moving up the stakes. And then you move further along to a system that holds real medical information about real people in a clinic. That is where 'it seems to work' stops being good enough.

Devon: And that is where the line of safety sits. The moment other people rely on the software to do their jobs, or the moment real sensitive data is involved, vibe coding becomes reckless. You have to switch your mindset completely to agentic engineering: clear briefs, honest records, tested security, and automatic checks.

Marcus: We agree completely on where the line is drawn. Vibe coding is a fantastic, frictionless way to prototype ideas or build disposable, low-stakes utilities. The danger only arises when people are seduced by the speed of vibe coding and use those exact same relaxed methods to build high-stakes, public-facing systems.

Devon: Which brings us to the concrete takeaway for you, the listener. We promised no hype, and the reality is deeply practical. If you are a non-coder and you are stepping into this space to build something real, not a toy, but a tool for your business, your charity, or your research, you must treat yourself as the director.

Marcus: Absolutely.

Devon: You have to take the time to explicitly decide what done means. You must write a brief that the agent simply cannot misread. And you must fiercely verify the outcomes by forcing the agent to provide evidence that the code works under pressure. Do not trust the polished surfaces.

Marcus: The agent is a brilliant, tireless, endlessly willing contractor working at superhuman speed, but it is just slightly too confident in its own abilities. Your judgement and your process discipline is the only thing standing between a good idea and a beautifully executed disaster.

Devon: This has been just the first deep dive in our 10-part series. Make sure you follow along for the next part of this deep dive series, where we will move on to exactly how you can start using AI effectively to create your own software. We're going to explore a crucial working pattern: why a builder can never, ever sign off their own work.

Marcus: And I leave you with a final thought to mull over. If the primary skill in software development is no longer the ability to write code, but rather process discipline, clear communication, and rigorous judgement, will the most successful software of the future be built not by traditional tech companies, but by project managers, head chefs, and tradespeople who already know how to direct complex work flawlessly?