Stop Prompting. Start Building Systems.

A buddy texted me last week, fired up. He'd asked Claude about an app idea, and instead of answering the question, it just started building the app. "It's nuts," he said.

Two texts later, the doubt showed up: "The guts of what it builds have problems a lot of the time. Getting it right 99% of the time still takes someone who can read the code, review it, and tweak it. I can't see it staying affordable if that's the case."

In other words: if every AI output still needs an expensive expert reading it, the savings are fake.

It's a fair worry. The conclusion doesn't hold, though, and why it doesn't hold is the most useful thing I know about working with AI.

I texted him back: you don't need to be able to read the output. You need to understand the system it exists in, and know what good is.

You don't need to read the code

How the code is written isn't the concern it used to be. I build working software, and I don't read it line by line. AI writes it. AI reads it. When I want to know what a piece of it does, AI explains it to me in plain English. What I bring is the HOW of building: what happens in what order, what gets checked before anything ships, and what good looks like at every step.

I can hear the pushback already. "If you can't read the code, how do you know it isn't garbage?"

Because I don't trust the AI. I trust the system around it. That answer only makes sense once you know what an AI actually is, so let's start there.

It's a probability engine

Strip away the hype and a large language model (an LLM: Claude, ChatGPT, any of them) is a probability engine. It writes one word at a time. Every word is a prediction: given everything written so far, what's the most likely next word?

Try it yourself. Type this into Claude: "Finish this sentence: peanut butter and." You already know what comes back. Jelly.

It didn't look up an answer. It didn't know anything. It predicted that across damn near everything humans have ever written, "jelly" is the word most likely to follow "peanut butter and." Then it stopped, because the most likely thing after "jelly" was being done.

That's all it ever does, even when the output is a thousand lines of code. When my buddy's Claude "decided" to build an app, it wasn't deciding. Given what he typed, the most probable response was code. So code came out.

Should it have started coding without asking? Probably not. He asked a question; it grabbed a hammer. AI does that sometimes, takes a step without getting proper permission, and the reason is the same mechanic: it's not checking with you, it's predicting what a helpful response looks like, and given his message, building looked helpful. But you can put guardrails in. Tell it to ask before it acts. Make it show you a plan before it touches anything. Most of these tools let you set standing rules that do exactly that. You're not hoping it behaves. You're stacking the deck so it does.

Once you see how it works, your job changes. You're not trying to ask a good question. You're trying to raise the probability that the output you want is the most likely output. You're aiming the engine.

Look at the difference. Type "write me a sales email" and you've given the engine almost nothing to aim with. There are a million plausible sales emails, so you get the average of all of them. Average is garbage.

Now stack the context instead. In that same message, before you ever send the prompt you provide info on: who the product is for, the one problem it solves, three past emails that actually got replies (pasted in, word for word), two that flopped and why. Same engine. Same ask. But its world just shrank from every sales email ever written down to yours. The most likely email for it to write now is one that sounds like your winners, aimed at your actual buyers.

That's half the job: aim it. The other half exists because probability is never certainty. Aim perfectly and it still misses sometimes. A wrong fact. Broken logic. Code that looks right and isn't. My buddy is dead right about that part.

So you do what every serious operation does with fallible workers, human ones included. You put checks and balances along the way.

It takes a team, not a prompt

Let's look at this from a coding perspective and walk through how an app actually gets built at my desk.

It doesn't start with code. It starts with a product-manager agent (an AI with one written job) interrogating the idea: who's the user, what problem are they actually having, what's broken today. It's deliberately skeptical, and fuzzy answers get pushed back on. Out the other end comes a written plan: the requirements, the screens, the technical approach. The work gets broken into small pieces, each with a written definition of done. Then I review the plan and approve it. Nothing gets built until I do.

Then the build starts. A developer agent writes the code, one piece at a time. SwiftLint, a standard tool that flags style problems and common bug patterns, runs on every change. And before any piece of work counts as finished, it has to clear a row of gates, each one a different specialist, and none of them the AI that wrote the code. The writer doesn't grade its own homework.

• A senior-engineer agent reviews the code, with CodeRabbit, an AI code-review product, reading alongside it: architecture, standards, the failure patterns we've hit before.
• A QA agent runs the tests against the written definition of done from the plan, not against whatever the code happens to do. And if the work has a screen, a second agent opens the actual app and takes screenshots to prove it works. I added that gate because agents kept claiming UI work was "done" that nobody could see. Now done means shown, not said.
• Security gets three reviewers, not one. One hunts known bad patterns: credentials, secrets, insecure connections. One reasons through the logic, hunting flaws. One audits Apple's platform rules: what the app is allowed to touch on your device. Underneath them, scanning tools (Snyk, Aikido, Trivy) sweep for leaked secrets and known vulnerabilities. I started with one broad security reviewer and it caught nothing specific, so I split it into three narrow ones.
• A product-manager agent checks the built thing against the plan. Did we build what we said we would?
• The last gate is me. I use the app the way a customer would and decide if it ships. The final judgment stays human.

And because two copies of the same AI can share the same blind spots, the gates that count hardest are the dumb, deterministic ones: the linter, the scanners, the test run, the screenshot. Those can't be sweet-talked.

The team isn't all homegrown, either. CodeRabbit, Snyk, Aikido, Trivy: those are third-party products, the same outside specialists most companies with an engineering team pay for. The AI plugs straight into Xcode, Apple's app-building software, so it can build the app and run the tests itself instead of guessing whether they'd pass.

A research agent verifies technical recommendations against current documentation on the web before we act on them, because an AI's training data goes stale fast, and anything it can't verify gets tagged for me to review. And a documentation agent keeps the project's own docs up to date as the code changes, so every agent that touches the project later is reading the truth, not last month's version. Some of the team is built, some is bought. All of it is staffed to a job.

When a gate rejects a piece of work, it routes back to the developer agent with comments on exactly what's wrong. The agent fixes it, and the reviews run again from the top. If the same piece gets rejected three times at the same gate, the system stops and comes to me, because at that point something deeper is wrong. The gates don't care who wrote the code or how many tries it took. They only care whether this version passes.

What if a fix is wrong too? It fails again, and we go again. That's the point. I'm not betting on the AI being right. I'm betting on bad work not making it through.

Why so much structure? Because shipping real software was never just writing code. It's requirements, design reviews, code reviews, testing, security checks. None of that is my invention; it's the boring, standard process every real engineering team already runs (the industry calls it the SDLC, the software development life cycle). The only new thing is who's staffing it. If nothing in your workflow forces those steps, they don't happen. And that's exactly what my buddy was complaining about: guts with problems. The model isn't the weak point. The missing team is.

I'm not a security expert, either. I couldn't trace a subtle security flaw through the logic by eye if you paid me. But I don't need to. I need to know the process a real security expert goes through, and then staff a specialist for each one. Same thing an engineering team does today. Just way fewer humans.

And I didn't write the team by hand, either. I built it with the AI, the same way you'd build anything with a sharp teammate: conversation, debate, research. I describe the role I need, we argue over what the job description should say, it drafts, we test it on real work, and we fix it every time it breaks. Every role is still a plain-English file. I just wasn't the one typing it.

That's not a side note. That's the whole point. You don't need to be a specialist in any of this. The workflow, the roles, what a code review checks, what a security audit covers: I learned it through the AI itself and plain web research, then fed what I learned back into the system. The knowledge of how good teams work used to be locked inside the companies that had them. Now you can ask for it.

That's the job now. AI lets you hire that kind of team for a couple hundred dollars a month. The one thing you can't outsource is knowing what good is.

And it goes way past code. You'll never out-scan Trivy. You don't have to. You can put a specialist on your team even when you can't judge their work line by line. Your standard just lives one level up: know the job belongs in the system, hand it to something whose only job is doing it, and check that it ran. For the jobs you can't do yourself, that IS knowing what good is.

I built the same thing for writing

Not one prompt that says "write this in my voice." A team, where every member has one job:

• A researcher that digs through my real material, my talks, posts, and notes, so every story and number in a draft is something that actually happened. No invented anecdotes wearing my name.
• A voice editor that holds the draft against how I actually write and flags every line that doesn't sound like me.
• A structure editor that checks the piece works as a story. Does the argument build? Does the ending land or just trail off?
• A "naive" reader that knows nothing about the topic and asks every question a beginner would, pinned to the exact sentence where they got lost.

None of these is a product I bought. Each one is a written job description that an AI follows: here's your one job, here's the standard, flag everything that misses it. An AI writes the draft, the reviewers read it, and I see it last, with their findings attached.

This article went through that team. The first version came back clean. Every check passed. And it still read like AI wrote it: too polished, too even, every line trying to be quotable. I caught that one myself.

So I did what you do when bad work gets past a check: I fixed the check, not just the draft. The AI and I pulled apart what made it read like AI, wrote those findings into the voice editor's standards, redrafted, and ran the whole team again. You're reading the version that passed the upgraded system.

Build it once, point it anywhere

A single prompt dies with the chat window. A system compounds.

That writing team doesn't just write articles. The same team drafts my LinkedIn posts. It writes emails. It pressure-tests business ideas before I pitch them, and the plain reader is brutal on a fuzzy idea. I built the team once. Now I point it at things.

The fixes compound too. That voice-editor upgrade wasn't just for this article. It's for every draft from now on.

This is where people get AI all wrong. They open a chat window, type one prompt, get a mediocre answer, and conclude the technology is overhyped. They're judging a team sport after playing it alone. No specialists, no checks, no standard. Single prompts get you single-prompt results.

The people who make this look like magic aren't holding magic prompts. They're running better systems, and they never stop improving them. When something breaks, they don't put manual labor in to fix the output, they fix the issue upstream so it doesn't happen again in the future.

And to the magic prompts. They don't exist. I despise people playing others on LI in this way. "Comment OPUS for my 10 magic Claude prompts that allow you to fire your $5M a minute consultant." Those prompts are generally garbage and it's just a way for them to get you on their marketing list.

A prompt is something you copy once. A system is something you work with daily and continually question it's habits. What does it check for today? What's still getting through? Where has somebody already solved this? Every field has its version. Finance doesn't move money on one person's say-so; a second set of eyes has to sign. Legal doesn't let a contract out the door unreviewed. Marketing tests the ad on a small audience before it spends the real budget. None of that structure is yours to invent. It's already there, proven, in whatever field you work in. Your job is to learn it, build your AI team around it, and keep improving it until it works for you.

And keep score on outcomes, not output. Output is what the AI hands you. Outcome is what happens when it ships. The draft doesn't matter. The shipped thing that worked matters.

This isn't prompt engineering. It's leadership.

Go back to my buddy's worry: it can't stay affordable if every output needs an expert reading every line. He's right that unchecked AI output can't be trusted. He's wrong about what the fix costs. The fix isn't a person who reads everything. The fix is a person who knows what good is and builds the system that enforces it. My whole team, every reviewer and every gate, runs on a $200-a-month plan. There are cheaper plans that work fine. That's not an engineer's salary. That's a decent phone bill.

Look at your own job. You already work this way. You don't do all the work on your team; you work with specialists. You hand the brief to design. You send the contract to legal. You pull in the finance person before the numbers go out the door. You've spent your whole career trusting work you couldn't do yourself and judging it by whether it meets the standard. That is the exact skill this takes. The only thing that changed is what the specialists are made of.

And here's what I firmly believe is coming, faster than most people want to hear it. The future of work isn't a team of people doing a thing. It's one person with deep domain expertise sitting in the executive chair, running a team of agents. Not a team of people. A team of agents. Companies get smaller. The output of one person gets bigger than whole departments used to be.

So get ahead of it: learn the systems. I build on Claude Code: agents, skills, commands, hooks, the connections that plug it into the software you already use. Whatever tool you pick, the concepts transfer. Agents are your hires. Skills are their training. Workflows are how the work moves between them. None of it requires a technical background. It requires the time to learn, and the AI itself will teach you as you go.

Then assume the new role you've created for yourself. Be the CEO of your company. The CPO. The CFO. Whatever seat matches your expertise and the system you're building. Nobody asks the CTO to read the code; they ask the CTO to staff the reviewers and define what good looks like. Build your team. Point it at your day job and produce on your own what used to take a department. Or point it at the company you've been waiting to start.

And starting is simpler than you'd think. Set up Claude Code or something like it. Tell it about the system you want to build. Point it at its own documentation first, so it's up to date on what it can do; the tools move faster than the AI's own training. Then build the system together. Tell it what you want. Ask it the best way to get there. Push back. Decide. You don't need to know the syntax of an agent or a skill; it knows the syntax. You need a clear picture of the outcome you're after, and the standard you'll hold the work to. The first version takes an afternoon.

The future of work isn't coming. It's here, sitting behind a login, waiting for someone to take it seriously. Most people won't put in the time to learn it. That's your opening.

Stop prompting. Start building.

**Note: With my system and a few paragraphs of an initial creative direction and story ideas, I wrote this entire article with the new Fable 5 model in under 20 minutes. I made a few tweaks, but overall, the writing sounded a lot like how I'd tell this story. On my own, this would have taken me a couple of days to write as I debated the words, the stories, the flow in my head.

20 minutes. All because I spent a few days building the writing system.