Stop Prompting. Start Building Systems.

A friend texted me this week, lit up about Claude. He'd asked it how to turn an artifact into a standalone app he could use on his desktop and phone, and instead of answering, it just started building the thing. "It's nuts."

Then the doubt showed up, the same one almost everyone hits. "It's great, but the guts of what it builds have problems a lot of the time. Getting things to work right 99% of the time still takes someone who can read the code, review it, and tweak it. I can't see this staying affordable if that's the case."

It's a fair worry. It's also the exact spot where most people get AI wrong.

Here's what I told him. You don't need to read the output. You need to understand the system it lives in, and you need to know what good looks like.

That can sound like a dodge. It's the opposite. It's the whole game. Let me walk through why, because once you see it you can't unsee it, and it changes what AI is worth to you.

How AI actually works

Start here, because everything else falls out of it. An LLM is a probability engine.

It doesn't reach into a database and pull your answer. It predicts the next piece of text, one small chunk at a time, based on everything you've put in front of it. "Product strategy is," then the most likely next word, then the next. It's autocomplete that studied most of the writing on the internet.

That's not an insult to it. It's the key to using it. If the thing is predicting the most likely useful next words, then your job is easy to say and hard to master: raise the probability that those next words are the ones you actually want.

This is why "act like a senior product leader explaining this to executives" beats "explain product strategy." You are not unlocking a secret senior-product-leader mode. There is no mode. You're steering the probabilities. Out of every direction the answer could run, you're telling the model to favor executive framing, business outcomes, sharper tradeoffs, a confident advisory tone.

A vague prompt is a wall of fog. "Explain leadership" can come back academic, military, motivational, religious, fluffy, or tactical, and you have no control over which. Every piece of context you add burns off some of the fog: who it's for, what they already believe, what good looks like, what to avoid. You're not asking a better question. You're narrowing the space the answer gets pulled from.

And the strongest steering of all is examples. "Make it sound like me" is weak. "Here are three things I've written, match this" is strong, because now the model can see the pattern: the sentence length, the rhythm, the words I use, the moves I make, the things I never do.

If you want a cheat sheet, a strong ask usually carries most of these: a role, the context, the goal, the audience, the constraints, the output format, and an example or two. "Write a LinkedIn post about product managers" gives the model a continent to wander. "Act like a product coach. I'm writing for PMs who feel like order-takers. Make them feel seen, then challenge them to reclaim discovery. Sharp, no buzzwords. Five two-sentence options." gives it a room to stand in.

None of that is magic. It's context. You're compressing the whole situation into something the model can aim at.

Why most people get garbage

Now the mistake, and it's almost always the same one.

Most people treat AI like a vending machine. One prompt in, one answer out. "Write this." "Build that." If what comes back is weak, they shrug and decide the whole thing is overhyped.

Watch someone use it to code. They type "build me X," copy whatever it produces, and run it. No agents. No skills. No review step. No tests. No second tool checking the first. One prompt, one shot, eyes closed.

Of course the guts have problems. You'd get the same result handing a junior engineer a one-line spec and shipping whatever they typed, untouched, without a single review.

That isn't an AI problem. It's a missing-system problem. There is no system.

The people who pull great work out of AI think differently. They don't think in prompts. They think in systems, and they spend most of their effort improving the system instead of perfecting one message. They ask sharper questions about how to operate. They borrow patterns from other fields. They stay locked on the outcome they want and treat the mechanism as something to keep upgrading. Most people never work this way, and it shows in everything they get back.

Checks and balances

So what does a system look like? The same thing a good engineering team looks like. Just with far fewer humans.

You don't do it all inside the LLM. Some of it is the LLM. The rest is other tools, each doing one job well. When I build, the model writes the code, but it never gets the last word. CodeRabbit reviews the pull request. Snyk scans for vulnerabilities, gitleaks hunts for secrets that slipped into a commit, SwiftLint keeps the style in line. If something breaks, I don't open the file and start hand-patching. I tell the LLM what broke, it fixes it, and I run the pipeline again.

That's a real engineering org: write, review, test, scan, ship. I've just collapsed the org chart. The reviewers and the security team are tools now, and they run in minutes.

Now back to my friend's worry, that this can't stay affordable if a human still has to babysit the code. Look at what actually happened to the cost. The expensive part of software was never the typing. It was the team. When the reviewer, the security analyst, and the tester become tools that one person runs, the economics don't get worse. They flip. You're not paying for the babysitter. You've turned the babysitter into part of the machine.

Here's the part that unsettles people, and shouldn't. I don't need to read every line to trust what ships. I need to know what good looks like, and I need to build the checks that enforce it. The reviewer catches what I'd catch. The scanner catches what I'd miss. My job moved up a level, from writing the lines to designing the system that produces them and proves them out.

And the thing nobody clocks: none of that is really about code. It works on anything you can define "good" for.

I built one of these to write

I'm deep in a playbook right now. A long one, in my own voice. And "my own voice" is the hard part, because the fastest way to make writing feel fake is to let an AI sand it down into a competent, voiceless report.

So I didn't single-prompt it. I built the same kind of system I'd build for code, and I pointed it at writing.

There's a voice rubric: the actual rules of how I sound, written down and loaded every time. There's a researcher that digs through my real material, my books, my posts, my old work, so the pages get built on things I actually said and never on something invented. And there are two independent critics, one for voice and one for story structure, that review every page before I ever lay eyes on it. Those critics are the code review and the security scan of my writing. They don't ask permission, they don't rewrite the page, they judge it and hand back a verdict.

Then came the moment that taught me the most.

A page came back and it was fine. Clean, organized, competent. And it didn't sound like me. The lazy move is to roll up my sleeves and edit it line by line, forever, every page, for the life of the project. Instead, the AI and I stopped and asked a better question: why doesn't this sound like me?

So we went and found out. The AI pulled my two books and studied how I actually write, side by side with what it had drafted, and we named the real differences. I reach for a specific, recognizable name where it reaches for a vague category. I act out the reader's doubt in their own voice instead of describing it from across the room. I lean on a particular rhythm and a particular kind of pause. We even measured the small stuff, like how often I really use a trailing pause versus how often it had been sprinkling them in.

Then the part that matters most. We didn't just fix the page. We wrote those findings back into the rubric. We fixed the factory, not the one product. Every page after that one starts closer to my voice on its own, because the system got smarter, permanently.

That's also where the word collaborator gets earned. It pushed back on me when I was wrong. When it needed a fact, it didn't guess. It went and read the actual source document instead. Once it caught itself about to credit a well-known line to the wrong person, checked it against the record, and corrected it before I'd have ever noticed. Working across several of these sessions, it flagged a story I'd lined up for one section that I had already used in another, and stopped me before I spent it twice. That kind of cross-cutting catch is exactly what I can't hold in my own head. The system can.

One more. Partway through, I told it about a podcast I like, The Diary of a CEO, where the host and his team do deep research on every guest and build questions designed to pull the best material out of them. I asked: can we make the AI's research work like that, instead of just searching for keywords? In an afternoon, we rebuilt the research step into a prepared interviewer that shows up with real, sourced options for me to react to instead of a blank page and a question. That's the move most people skip. A pattern lifted from a completely unrelated field, used to upgrade the system. And before we changed it, we saved the old version, so we could see how the method evolved. The system has a memory.

What it unlocks next

Here's why this matters more than one playbook.

I built this thing to write a single project. But the system doesn't care what it's pointed at. The rubric, the researcher, the critics, the library of what good looks like, none of it is playbook-specific.

So now the same system writes my LinkedIn posts in the same voice. It drafts emails that sound like me instead of like a form letter. It can pressure-test a new idea before I commit money to it, score a lecture before I stand up and give it, or read an article I'm about to publish and tell me where the argument goes soft. It can synthesize a pile of customer interviews, draft onboarding docs for a team, or hold someone else's work up against a standard and tell me where it misses. Same system, new target.

The expensive part, building the system and teaching it what good means, is already paid for. Re-pointing it is nearly free. And that library of what good looks like, the rubric, the real stories, the checks, is the real asset. The model underneath will keep changing. The system I've built on top of it is the thing that compounds.

That's the difference between building a product and building a factory. A product is one thing. A factory makes whatever you point it at, and it gets better every time you tune it.

Where to start

If you've already decided AI is overhyped, be honest: you probably proved it to yourself with a single prompt. Try the other thing.

Stop asking AI to "do the thing." Build the system around it. Give it the role, the context, the examples, the constraints. Add the checks that catch what you'd catch, and the ones that catch what you'd miss. When it's wrong, don't just fix the answer. Fix the system, so it's never wrong that way again. And steal shamelessly from other fields while you're at it.

The one piece you can't outsource is knowing what good looks like. You don't have to read every line. You have to be the person who knows what you're aiming at and builds the machine that hits it, over and over, a little better each time.

That's not prompt engineering. It's just engineering. Start there.

(I wrote this with the system I just described: drafted in my voice, run past the same two critics, sharpened from their notes. It pushed back on a few of my lines. That's the point.)