The Real AI Skill Isn't Prompt Engineering — It's Being the Pilot

TL;DR: Everyone's racing to become a prompt engineer. It's the wrong skill to fixate on — too rigid, and already becoming basic literacy. The real skill, and the one the data says actually separates the projects that work from the ones that don't, is learning to pilot AI: managing it with judgment, like a project manager leads a team. Prompting is typing. Piloting is judgment. Here's how I actually do it.

Let me say the quiet part out loud: chasing "prompt engineering" as the AI skill is a mistake. It's too rigid — binary, X's-and-O's, ones-and-zeros thinking — and it strips out the real potency of what's possible. The market already agrees. As the models got good enough to understand plain language, prompt engineering stopped being a specialized job and started becoming basic literacy — like typing, or using a spreadsheet. Even Forbes has written that it's no longer the most valuable AI skill; what matters now is thinking like a manager — defining goals, setting guardrails, and applying human judgment.

I have a simpler word for it. Stop trying to be an AI prompt engineer. Become an AI pilot.

You're not writing prompts. You're managing intelligence.

Here's the reframe that changes everything. It's right there in the name: artificial intelligence. And whether you're managing biological, sentient intelligence — a team of people — or artificial intelligence, back up to the macro view: you're still managing intelligence.

That's the shift. You're not a person typing questions into a box. You're the project manager. The team lead. The pilot. And the moment you start thinking that way, a whole set of questions opens up that a "prompt" never accounts for: What's the scope? Who — or what — is best suited to each task? What context do they need? What has to be checked? If you sat at a conference table as the manager responsible for executing a project, you'd naturally sort all of that out. Most people just don't extend that same thinking to AI. They should.

To make it concrete: our team runs about 30 "employees" now — four of them human, and more than 25 of them AI. Everyone on our team gets their own AI thought partner, issued like a piece of company equipment, the same as a laptop or a phone — preloaded with context about our business, how we do things, and tuned to their specific role. Because if I can move fast with AI, why shouldn't they? Instead of letting people sit in fear of being replaced, we let them go faster and do more of what they're actually great at — keeping the human parts human and the AI parts AI.

The 95% failure isn't the tech. It's the piloting.

If you want proof this is the real issue, look at the biggest study on it. MIT's 2025 "State of AI in Business" report found that roughly 95% of enterprise generative-AI pilots delivered no measurable business impact — despite tens of billions of dollars invested. And here's the part that matters: the researchers were explicit that it wasn't the models' fault. The failures came from poor scoping, weak integration, and treating AI like software you bolt on. The winning 5%? They picked one clear problem and executed it well.

Read that against how most people actually use AI. They grab a fancy prompt they bought from somebody, and they start building. No project area. No scope. No spec. No stress test. No audit. That's the equivalent of hiring a person, handing them a job title, and saying "go have fun." We've all hired someone before — a freelancer, a contractor, an assistant — and we know the truth: your number one job is to put them in a position to succeed. Equip them, or watch them fail. AI is no different.

Set the table before you build

So here's what piloting actually looks like — the work that happens before the work. This is where the real skill lives.

Set the table. Before anything gets built, I scope it: what's the outcome, what skills are required, what context is needed, what has to be checked. Who's best for what task — and is this a job for an AI thought partner, or an ongoing agent that runs in the background? A thought partner is executive-level, in on the big decisions; an agent is more like an assistant handling a specific, repeated task. Label where each one operates and how it ties into the bigger picture.

Play the right card. Different tools are good at different things — the same way you wouldn't assign every task to the same employee. Claude's reasoning and precision are exceptional; it takes my raw thoughts and turns them into something sharp. But it's not my choice for design, so that goes elsewhere. Perplexity and Gemini shine at certain research. A ClickUp agent is great inside ClickUp and lost outside it. Know your cards, know your costs, know your scope.

Spec it and poke holes. I bring the idea to my primary thought partner and we sharpen the axe before we swing — scope it, pressure-test it, research whether anyone else has done something similar and what we can learn from it. The majority of the work is done before the actual work begins.

Red-team it. Then I take that spec to a different thread whose entire job is to rip it apart. I have an auditor project trained to scrutinize everything I build — to sink the battleship if the idea deserves sinking. And I'm genuinely glad when it does, because a killed bad idea is time saved, not time wasted. What comes back is a far more refined output than what I started with.

Phase it. When I first started, I tried to build the whole thing at once. Don't. Think in phases: how do you get something small off the ground to prove the idea works, then move to phase two? If you don't know what the phases should be, tell your thought partner: "Be my CTO on this — now that you understand the vision, tell me how to phase it out."

Control the pace. Your AI thought partner will always want to jump straight to building — it's eager. Slow it down. Make sure the plan is sound and everyone's on board before a single thing gets built.

You don't need to know how to do everything

Here's what frees people up: a CEO doesn't have every skill of the people they manage — they know how to manage them. There are plenty of times Claude is coding something and I have no idea what it's writing. That's not a skill I have. It doesn't disqualify me as the pilot, any more than a CEO is disqualified for not being able to do every job in the company. My job is to manage it — and to put checks in place. That's exactly why I keep a dedicated auditor thread whose only role is to scrutinize and stress-test the work, whether that's reviewing code or ripping apart a concept.

When my team — AI or human — brings me a judgment call I don't fully understand, I don't fake it. I say: explain that to me. What does it mean? What are the trade-offs, the pros and cons? What do we need versus what we'd like? What happens if we deploy this wrong? That back-and-forth is the job. It's the same whether the intelligence on the other side of the table is biological or artificial.

What piloting actually built

I don't make claims I can't show, so here's what this looks like in practice — and notice that none of it came from a magic prompt.

We rebuilt our own community app — replacing a buggy platform that had cost us clients and eaten our team's time for years — and shipped it in 15 days. Engineer friends told me a full development team would need six months. It didn't happen because of a clever prompt. It happened because I specced it, phased it, documented every decision in an ongoing record anyone could step into, and — at the milestones — had our CTO run his own audit: I made sure his AI thread had direct access to the codebase to crawl what we'd deployed and check the back end for security holes before anything shipped. He acted as the senior engineer reviewing a junior's audit; I mediated. That's piloting.

I've had an idea hit me at midnight and had a working prototype connected and running by 5 a.m. — a marketing tool for our clients that would have taken months before. But the first thing I did wasn't "go build it." It was bring it to my thought partner and run it through the wringer: what has to be true for this to work? What do you need from me? Has anyone done this — how did they build it? Can we borrow from that? The build was fast because the thinking was done first.

And yes — I migrated my own website, custom, in a single Sunday afternoon. Same discipline every time.

There is no prompt I can hand you to build any of that. But if you can manage well, articulate your vision clearly, and you're willing to challenge your own idea and get it specced, pressure-tested, and audited before you build — that's when you arrive at something that actually ships.

The good news: you probably already have the skill

Some people are going to rush off to become prompt engineers. Others will feel like they have to go learn to code. I'm not dismissing either — both are useful, and honestly there are days a coding background would help me move faster. Incorporate those skills into the bigger picture if you can. But hear this clearly: you don't need them to win. The scarce, valuable skill is being a good director — casting a clear vision, scoping the work, managing the process, making the judgment calls. That's a human ability you already have or can build. The whole shift is from operator to architect.

And I'll be honest about the part that surprises people: this is the most fun I've ever had with work. I keep trying to make myself go watch a show or play a game, and I can't put this down — I'm building ideas on walks, at midnight, in the margins. Because the friction is gone. Ideas I parked for years — things I assumed needed a full dev team, funding, and months I didn't have — I can now ship in an afternoon. As a believer, it's the closest thing I've felt to pure creation this side of heaven: imagine it, and build it. That's the era we're stepping into. The technical people built the technology. Now it's the entrepreneurs — the ones who understand it's not code, it's intelligence to be managed — who are going to take it somewhere new.

What to do this week

One shift: stop asking AI for finished things, and start directing it like you'd manage a capable new hire. Scope the outcome before you start. Break it into phases. Ask for a plan and poke holes in it before you build. Check the work — don't blindly trust it. Hold your standard, and control the pace.

You're not behind for not being a prompt engineer. You're exactly on time to become something more valuable: the pilot.