How an Engineer Builds with AI (and How You Can Too)

Let me start with the thing nobody likes to hear. The reason your AI-built app worked perfectly in the demo and then quietly fell apart once real people started using it is almost never that the AI wrote bad code. It’s that the AI made a hundred small decisions you never knew were being made, and a few of them were wrong in ways you couldn’t see.

That’s the whole problem in one sentence, and everything in this guide is built around fixing it. So before we talk about process or documents or methodology, sit with that idea for a minute, because if you get this one thing, the rest follows naturally.

The problem isn’t dumb AI, it’s invisible decisions

Here’s what people get wrong. They think the risk with building software using AI is that the AI isn’t smart enough, that it writes sloppy code or makes mistakes a “real” developer wouldn’t. That’s not really it. The code usually runs. It usually looks right. The trouble is that building software means making an enormous number of choices, and most of those choices never get spoken out loud.

Should a user be able to edit somebody else’s order? Obviously not, to you. But the AI doesn’t know that unless you tell it, because it has no common sense about your business. Can someone order negative three of an item and get money back? You’d never type that in, so it never occurred to you, so it never occurred to the AI either. Should this page check who’s logged in before it deletes something? A human developer would pause and think about it. The AI just builds whatever the most likely-looking version of the code is, and if nobody mentioned the check, the most likely version often doesn’t have one.

These aren’t exotic edge cases. These are the exact things that go wrong over and over when people ship AI-built apps, and they all share one trait: they’re decisions that got made silently. Nobody chose to leave out the login check. It just never came up. The app has a hole in it, and the scary part is you don’t know the hole is there, because from where you’re sitting everything looks fine.

So the goal of everything that follows is not to turn you into a software engineer, in the sense of someone who writes the code by hand. It’s to put you in the engineer’s chair where it counts: making the silent decisions visible, so you at least know what’s being decided, even when you lean on the AI to decide it. You direct; the AI builds.

Breaking the work into parts so you can focus

The first tool for making decisions visible is almost embarrassingly simple: stop trying to do everything at once.

There’s a long-standing way of thinking about how software gets built, sometimes called the software development lifecycle, and you don’t need to memorize the term. The useful idea behind it is that building something goes through phases, and each phase is about a different kind of question. First you figure out the business side (what problem are we solving, for whom, and why). Then the product side (what should this thing actually do). Then design (how should it work and look and fit together). Then, finally, you build it.

The reason this matters for you specifically is focus. When you sit down and prompt the AI to “build me a marketplace app,” you’ve asked it to make all of those decisions at the same moment, in one shot, mostly without telling you. When you instead walk through the phases, you get to think about one kind of thing at a time. You’re not drowning. You can actually pay attention.

And here’s the part that pays off later. The habit you build doing this in the planning stages carries straight into the build itself. Once you’re trained to break a project into parts, you naturally start breaking the build into parts too: phases, then features, then individual tasks. Instead of one giant prompt that tries to create the whole application, you give the AI one focused task at a time. This is where it really earns its keep, because small tasks shrink what I’d call the blast radius of any mistake.

Think about it this way. If you prompt the AI to build the entire app and something breaks, you have no idea which of the fifty intertwined decisions caused it, so you re-prompt the whole thing and play whack-a-mole. But if you ask it to build one small piece and that piece breaks, you know roughly where the problem lives, the change it made is small enough that you can actually look at it, and the decisions involved are specific enough that you can check them. Smaller pieces mean smaller, findable, fixable problems. That’s the entire argument, and it’s a good one.

One caveat so you don’t overdo it. If you’re making a fun little weekend project that nobody depends on, you don’t need to march through a formal lifecycle. Match the effort to the stakes. The phases are there to tell you which decisions are even worth surfacing and when; a toy doesn’t have many that matter, and a real business app has a lot.

Surface, Explore, Record: the engine you run at each step

So you’ve broken the work into parts. Now, at each part, you run a simple loop. I call it Surface, Explore, Record.

Surface means using the AI to bring the hidden decisions out into the open. You ask it, in effect, what choices need to be made here, and it lays them out. This is the step that fights the invisible-decision problem head-on. You can’t make a choice you don’t know exists.

Explore means looking at the options for each decision. The AI presents the realistic choices along with the strengths, weaknesses, and tradeoffs of each, and you talk it through until you’re comfortable enough to pick one. Sometimes you’ll have a real opinion. Often you won’t, and you’ll go with what the AI recommends. That’s completely fine, and I want to be honest about it: a lot of the time you won’t have the experience to judge between two options, and you’ll take the suggestion. The win isn’t that you became an expert. The win is that you know a decision got made, and you know what it was, instead of the AI quietly deciding for you in the dark.

Record means writing the decision down: in a decision record, a requirements doc, a spec, whatever fits. You then hand these documents to the AI during the later phases as guides, and you keep them around to compare against later.

A word of warning on Surface, because it has a soft spot. The whole loop depends on the right decisions getting surfaced, and the same AI that forgets to add a login check can also forget to surface the question of login checks. So don’t rely entirely on the AI to raise everything. Keep a basic checklist of non-negotiables that you bring to every project: does every action check who’s allowed to do it, is user input being validated, are passwords and keys being handled safely, and so on. A lot of the most common security holes live in this cross-cutting stuff that no single feature prompt would ever think to mention. A short, blunt checklist covers a surprising amount of it.

How the AI actually uses your documents

Now I have to correct a misunderstanding before it causes trouble, because it changes how you use everything above.

The AI does not “follow” your documents the way a person follows instructions. It’s worth being clear-eyed about this. When you hand the AI a spec, it isn’t reading your rules and obeying them. It’s using the words you gave it to shape what it produces. Putting “users may only edit their own orders” in front of it makes the AI far more likely to generate code that checks for that, because you’ve put the idea in front of it instead of hoping it guesses. That’s a real and powerful effect. It’s just not obedience, and the difference matters in two practical ways.

First, the influence fades the moment the document isn’t in front of the AI anymore. The AI has no memory between tasks. Each time you prompt it, it starts fresh, knowing nothing about the decision you made three steps ago unless you show it again. So your documents have to be re-supplied as you go. You don’t write the spec once and assume it’s now in force forever; you bring the relevant decisions back into the conversation at each phase and each task. A decision the AI can’t currently see is a decision it will happily make differently this time.

Second, anything you leave vague gets filled in by the AI’s defaults, and its defaults are just whatever was most common in everything it learned from. That’s exactly where the weird stuff comes from, like orders for negative quantities. A human builder would fill a gap in the plan with judgment and common sense. The AI fills it with a statistical guess. So your documents need to be more explicit than you’d think necessary, more explicit than you’d bother being for a human, because there’s no experienced foreman on site quietly catching the things you forgot to say.

The blueprint, and the boulder

Here’s a comparison that helps a lot of people, as long as we’re careful with it.

A spec is a bit like a blueprint for a building. You wouldn’t let a construction crew start pouring a foundation with no plan, just vibes and good intentions, and somewhere deep down you already know that. The blueprint is what keeps everyone aimed at the same building. Your specs do the same job for your project. That’s the part of the comparison worth borrowing, because it connects to something you already respect.

But let’s push on it, because if you take the blueprint idea too literally you’ll get the wrong picture. Is a blueprint actually binding? What happens when the crew is digging the foundation and hits a giant boulder nobody knew was there?

They don’t just blindly follow the plan into the rock. Work stops. Somebody flags it, the engineer takes a look, the plan gets revised, and the revised plan becomes the new reference. The blueprint was never an unbreakable contract. It’s a living document that gets amended the moment reality disagrees with it. And here’s the key thing: the blueprint’s real value in that moment is that it let everyone notice the boulder was a problem in the first place. You can only tell you’ve hit something unexpected if you had a plan that said what you expected.

This is exactly how to think about the AI and your specs. Remember how I said the AI doesn’t really follow instructions, that it drifts and sometimes produces something different from what you asked? That drift is just the AI’s version of hitting a boulder. It happens more often than a real boulder, and more quietly, but it’s the same kind of event: the plan and reality have diverged, and now you need to notice and respond. Sometimes the boulder isn’t the AI drifting; it’s the build itself teaching you something, like discovering a decision you made during design turns out to be impossible once you actually try to build it. Same situation. Plan meets reality, reality wins, plan gets updated.

So the two things I’ve told you, that your specs are like a blueprint and that the AI is unpredictable, are not in tension at all. They’re the same idea. The spec exists precisely so that when the AI drifts or reality surprises you, you can see it and fix the plan. Drift isn’t a sign your spec failed. The crew hitting a boulder doesn’t mean the blueprint was bad. It means the system is working the way it’s supposed to: you planned, you hit something, you adjusted.

The two mistakes everybody makes

When people first hear all this, they tend to bounce between two wrong beliefs, and they’re really the same mistake in two outfits.

One belief is “I don’t need these documents.” This usually comes from watching a spec get ignored or go stale and deciding the whole exercise was a waste of time. But the writing was never the point. Catching the drift was the point, and you can’t catch drift if you never had a plan to measure against. The person who skips the documents is the crew that hits the boulder and just pours concrete around it, because they never had a plan it could violate.

The other belief is “these documents are sacred and must never change.” This comes from the opposite experience: someone finally produces a clean, careful spec, falls in love with it, and then tries to force the AI to honor a decision that the build has already proven wrong. That’s the crew trying to drill through the boulder because the blueprint said so. Just as broken, in the other direction.

Both mistakes treat the document as a fixed, finished object. The truth is that it’s a living thing. It’s your current best record of what you intend, and it stays true right up until reality proves a piece of it wrong, at which point its most valuable moment is the revision.

Now, the “documents should change” idea has a failure mode of its own, so let me close that loop. Changing your spec carelessly, every time the AI produces something slightly different, gives you a document that’s worthless in a new way: it’s just whatever the AI last did, dressed up as a plan. The discipline is that you amend the spec when reality genuinely contradicts a decision, and you write down why you changed it (the boulder you hit). Change anchored to a real, surfaced conflict is the loop working. Change with no recorded reason is just drift wearing a costume. That distinction is what keeps “living document” from sliding into “disposable document.”

The frame to hold onto: stop asking “is this document right?” and start asking “does this document still match what we now know?”

Putting it into your hands

Reading about this only gets you so far. The moment it actually clicks is when you run it on something real, so the last and most important step is to take a small project all the way through. Break it into phases. At each phase, surface the decisions, explore the options, record what you chose. Carry those records forward into the build, re-supplying them as you go. Build in small, focused tasks, not one giant prompt.

And somewhere in the middle, on purpose, let yourself hit a boulder. Pick a project where you know the build will contradict something you decided earlier, or just wait for it to happen naturally, because it will. When it does, don’t let the AI quietly route around it. Stop. Surface the new problem. Look at the options again. Amend your record, and note why. Then keep going.

The first time you change a spec mid-build and watch the rest of the work get better because of it, the whole thing stops being theory. The document stops being a chore somebody told you to do and becomes yours: a tool you use, revise, and trust exactly as far as it deserves. That single experience teaches more than this entire guide.

That’s really the heart of it. None of this is about writing the code yourself or wrapping your fun in paperwork. It’s about doing the engineering thinking (making the invisible visible, breaking big scary things into small manageable ones) and keeping a plan that’s honest enough to argue with reality and flexible enough to lose the argument gracefully. You direct, the AI builds, and the apps that come out the other side will hold up a lot better than vibes alone could ever manage.