I need to confess something, because I suspect you've done it too.
A few months ago I caught myself saying, out loud, "Claude's gotten worse at this." I'd asked it to do something, gotten back something mediocre, sighed, and filed it under the model is slipping. Very satisfying. Nobody's fault but the AI's.
Then I watched a colleague hand the same model a better-formed version of the same request and get back exactly what I'd failed to get. Same model. Same day. Same task. Wildly different output.
It wasn't the model. It was me. I just really, really didn't want it to be me.
That's the whole article, honestly. But let me make the uncomfortable case in full, because I think this is one of the biggest quiet skill gaps in software right now — and almost nobody is treating it like a skill at all.
The model isn't the variable anymore. You are.
For a couple of years, "better results" had an easy explanation: better model. If your output was weak, you waited for the next release, upgraded, and things improved. The tool was the variable, so the tool was the excuse.
That excuse is dead, and it's not coming back.
Everyone has the same frontier models now. You, your teammate, your competitor, the intern — same GPT, same Claude, same Gemini, one click apart. Raw access stopped being an edge the moment it became universal.
So here's the part that stings: when two developers get dramatically different results out of the identical model, the difference has nowhere left to hide. It isn't the model — you both have the same one. It's the operator. It's the ask. It's the fluency.
We're standing in front of the same instrument getting different music out of it, and most of us are still blaming the instrument.
Prompt fluency is the last remaining variable in the equation, and the majority of developers are pretending it's still about the tool — because "the model isn't good enough yet" is a much more comfortable sentence than "I'm not good at this yet."
A vague prompt is a vague thought wearing a question mark
Here's the reframe that changed how I see this, and it's the part most "prompt tips" articles completely miss.
When you get a bad answer from a capable model, your instinct is that you phrased it wrong — that there's some magic wording you're missing, some incantation that unlocks the good output. That's why prompt-hack listicles do numbers: they promise the secret phrase.
But most bad prompts aren't a wording failure. They're a thinking failure.
You didn't fail to express what you wanted. You hadn't actually decided what you wanted — and the model, doing exactly its job, reflected your fuzziness right back at you. A vague request produced a vague result because the request was the vagueness, made visible.
The model is a mirror for the clarity of your intent. If the reflection is blurry, check the thing standing in front of it before you blame the glass.
This is also why "prompt hacks" are mostly a dead end. You cannot trick your way out of not knowing what you're asking for. There's no magic phrase that compensates for an undecided goal, unspecified constraints, and no definition of what "good" looks like. The secret isn't a better spell. It's actually knowing what you want before you ask — which is harder, less fun to tweet, and the entire game.
Winging it has a bill — and you're paying it without seeing the invoice
"Okay," you might say, "but I get there eventually. A few tries and it's fine." Sure. But look at what those few tries actually cost, because the invoice is itemized and most people never read it.
Charge one: the correction spiral. You fire off a fuzzy prompt, get something wrong, and start the "no, not like that" loop — fifteen rounds of nudging the model toward the thing a thirty-second upfront spec would have landed in one. You feel productive because you're actively working. You're just paying in small installments for a bill you could have settled once.
Charge two: the un-reusable result. Even when you finally get something okay, you got it through improvised back-and-forth you couldn't reproduce if you tried. So it doesn't compound. Tomorrow's similar task starts from zero, because you never captured how you got there — only the messy output, not the method.
Charge three — and this is the expensive one: the false verdict. You conclude "the AI just isn't good at this," and you stop. Except it wasn't the AI — it was the spec you handed it. So now you've done real damage: you've permanently underrated a capable tool based on your own unclear ask, and you'll avoid using it for exactly the things it could've handled.
That third charge is the real cost of winging it. It doesn't only waste your afternoon. It teaches you wrong lessons about what these tools can do — and wrong lessons are stickier and more expensive than wasted time.
What fluency actually looks like
None of this is mystical, and that's the good news. Prompt fluency is a set of learnable, boring, repeatable habits — closer to writing a good bug report than casting a spell. Here's the core of it:
State the constraints, not just the goal. "Write a function to parse this" is a wish. "Write a Python function that parses this CSV, handles missing fields by skipping the row, returns a list of dicts, and raises on malformed headers" is a spec. The model can only hit a target you actually drew.
Give it the shape of the answer you want. Format, length, structure, tone. If you know you want a table, or bullet points, or a single function with no explanation — say so. Leaving it implicit means you're gambling, then correcting.
Show it good and bad. One example of what you want and one of what you don't teaches the model more than a paragraph of description. Concrete beats abstract, every time.
Tell it what to do when unsure. "If you don't have enough information, ask instead of guessing" or "say you're not certain rather than inventing" — this alone kills a whole category of confident-wrong output.
Decompose instead of mega-prompting. A giant vague ask produces a giant vague answer. Break it into steps you can verify. You'll debug the pieces instead of the blob.
Capture what worked. This is the one nobody does and everybody should — more on it next, because it's the difference between a skill and a leverage machine.
Notice what's not on this list: clever phrasing, secret keywords, jailbreak tricks. It's all just precise specification. Clear thinking, written down.
The real unlock: fluency is reusable, not per-attempt
Here's where prompt fluency stops being a nice habit and becomes actual leverage — and it's the insight that reframes the whole thing.
Getting marginally faster at improvising prompts is fine. But the real move isn't improvising faster. It's not improvising at all.
A good prompt — a real, precise, constraint-loaded spec that reliably gets you what you want — is worth writing once and keeping forever. Save it. Template it. Turn it into a reusable form. After that, the marginal cost of getting a great result on that kind of task drops toward zero, because you're no longer re-deriving the spec every single time. You're invoking it.
This is the part that turns a 20%-of-the-time-it-works habit into something categorically different. The expensive part of prompting was never the typing — it was the deciding: what do I want, what are the constraints, what does good look like. Do that thinking once, capture it, and every future use is nearly free.
That's the difference between a developer who's a fast typist at the AI and a developer who's built a personal library of specifications that consistently produce reusable output. One is winging it quickly. The other has stopped winging it entirely. Only one of those compounds.
The part that'll annoy some of you
I know how a chunk of readers are reacting right now: prompting isn't real engineering. It's typing English at a chatbot. It'll be obsolete when the models get good enough to read my mind.
I want to gently point out that this exact dismissiveness is the winging-it problem, wearing a lab coat.
"It's beneath me to get good at this" is precisely the attitude that keeps someone improvising, blaming the model, and getting mid results while a colleague who took it seriously runs circles around them with the same tools. The disdain isn't protecting you from a fake skill. It's protecting you from noticing a real one you haven't developed.
And "it'll be obsolete when models improve" gets it backwards. Better models don't make specification less important — they make it more valuable, because a more capable model can execute a precise spec far more completely than a weak one could. The ceiling on what you can get out of these tools is rising, and the thing that determines how close you get to that ceiling is how clearly you can say what you want. That skill isn't going away. It's the one thing that's been appreciating this whole time.
The takeaway
Prompt fluency is quietly becoming table stakes — the way knowing how to search well, or write a clear commit message, or read documentation became table stakes. It's not glamorous. It's not a trick. It's clear specification, made into a habit, and then captured so you don't have to repeat the thinking.
The developers who treat it as a craft are getting consistent, reusable, compounding leverage out of the exact same models everyone else has. The ones winging it are getting inconsistent results and a growing list of wrong conclusions about what AI "can't do."
Same instrument. Very different music. The gap isn't the model anymore. It hasn't been for a while.
What's the one prompt habit that actually moved your hit rate — and, real question: do you save your good prompts, or retype them from scratch every single time? I'm trying to figure out if prompt-capturing is a rare discipline or if I've just been the last one to it.
Top comments (0)