The Work Happens Before the Prompt

Every week I see another discussion about becoming better at AI.

People compare models. They trade prompt libraries. They debate whether Claude writes cleaner code than GPT, or whether a particular workflow saves a few more minutes.

Those conversations are useful, but after spending the past year working with AI on real software projects, I keep coming back to the same conclusion:

I don't think the biggest productivity gains come from prompting.

I think they happen long before the first prompt is ever written.

The pattern I couldn't ignore

Among the developers I work with, AI has landed very unevenly. Some engineers have become dramatically more productive. Features that once took days now take hours. Others improve a little, then seem to plateau.

At first I assumed the difference was technical. Maybe some people had discovered better prompts, better models, or better workflows. The more I worked with AI myself, the less convincing that explanation became.

Whenever AI felt almost magical, it wasn't because I had written an exceptional prompt. It was because I'd already solved the difficult part in my head.

Not the implementation.

The problem.

The work AI doesn't do

Before I ask AI to write a single line of code, I usually already understand most of the things that actually matter: which decisions will be expensive to reverse, where the architectural boundaries are, where a responsibility belongs, what assumptions I'm making, and what information I'm still missing. By the time I write the prompt, the implementation often feels almost inevitable. That's when AI becomes astonishingly effective. The prompt isn't carrying the intelligence—it's exposing it.

Over time, another pattern emerged. When I start working on a new problem, I rarely think about code first. I'm usually trying to identify the business capability, the authoritative source of truth, the architectural boundaries, and the assumptions that would be expensive to discover were wrong six months from now. Those questions don't produce code, but they shape every line that eventually gets written.

That has changed how I think about AI. Modern language models are extraordinary implementation partners. Given enough context, they can generate code, tests, documentation, infrastructure, and refactorings faster than I ever could manually.

What they cannot reliably do is invent context that doesn't exist.

If I haven't decided where a responsibility belongs, AI has to guess. If I haven't identified the real constraints, it has to assume them. If I haven't recognized an ambiguity, it can only choose one interpretation and continue.

Sometimes those guesses are perfectly reasonable.

Sometimes they're the beginning of months of technical debt.

One pattern keeps repeating in my own work. When AI produces something that doesn't feel quite right, the problem is rarely the code. More often, it's because I wasn't actually ready to ask the question yet. Halfway through writing the prompt, I'll realize there's still an architectural decision I haven't made or an assumption I haven't challenged. I close the AI window, work through the problem, and come back later.

The second prompt is usually shorter.

The answer is usually much better.

I ran into a much larger version of this on a system of my own that needed its own domain language. The difficult part wasn't the tooling around the language. It was defining the language itself. Until I understood what the core concepts actually meant in that system, AI kept producing good implementations of an architecture that didn't quite exist yet.

Once the language was clear, the tooling built on top of it became surprisingly straightforward.

The implementation didn't become easier because the prompts improved.

It became easier because the thinking did.

The most expensive decisions rarely look like code

Not every engineering decision carries the same weight.

Renaming a method is cheap. Refactoring a class is usually manageable. Replacing a library is inconvenient.

But discovering six months later that the wrong service owns a business responsibility? Realizing you've drawn the wrong architectural boundary? Building an entire workflow around an assumption that was never validated?

Those decisions ripple through everything that follows.

I've started thinking of them as load-bearing decisions. Once they're correct, implementation often becomes surprisingly straightforward. AI accelerates everything that comes after. It doesn't usually make those decisions for you.

Maybe this is what expertise has always been

For a long time I believed expertise meant knowing how to build systems.

I'm not so sure anymore.

I'm beginning to think expertise is the ability to identify what matters before anyone starts building.

It's recognizing ambiguity before it becomes code. Knowing which questions need answers first. Separating fundamental constraints from incidental ones. Seeing which decisions will still matter a year from now, long after today's implementation has been rewritten.

Those aren't implementation skills.

They're judgement.

And once that judgement exists, AI can amplify it remarkably well.

What happens next?

I don't think this advantage belongs permanently to experienced developers.

AI is improving quickly, and I can easily imagine an assistant that pauses before generating code to ask the kinds of questions an experienced architect would ask instead.

• What problem are you actually trying to solve?
• Which constraints are real, and which are assumptions?
• Which decision will be hardest to reverse?
• What information is still missing?

Helping someone build the right mental model may ultimately be more valuable than generating another thousand lines of code.

There's a less comfortable question hiding underneath that.

If judgement is built through years of implementation experience, and implementation becomes increasingly automated, where does the next generation of judgement come from?

I don't know the answer.

I suspect it's one of the most important questions AI will force our profession to confront.

The prompt is the receipt

This is only an observation from my own experience. It isn't something I can prove, and I may think differently five years from now.

We often talk about prompts as though they're where the work begins.

I've started thinking of them differently.

The prompt is the receipt.

It isn't where the value was created. It's simply the first visible record that the work had already been done.

The best prompts I've written weren't good because of the words they contained. They were good because they reflected hours—sometimes years—of thinking that happened beforehand.

Maybe expertise was never about writing code.

Maybe it was always about understanding the problem deeply enough that the code became the easy part.

AI didn't change that.

It just made it impossible to ignore.