i started counting my prompts 🤔
not for a blog post. i was genuinely curious about something, and i couldn't find anyone measuring it: how many prompts does it actually take to get from "the model built something" to "this is the thing i had in my head, and it's production ready"?
because we all quote the first number and never the second one.
the curve
from what i've watched on our own product, roughly:
that last line is the whole point of this post.
the intuition everybody has — the one i had — is that once you're at 85%, you're basically done. ten more prompts. an afternoon.
it isn't ten. small bugs keep arriving. small mistakes keep arriving. things that were fine on the happy path fall over on the second one. and the closer the implementation gets to what you actually pictured, the smaller each improvement becomes and the more of your intervention each one needs 😮💨
the prompts aren't features
here's the part that surprised me when i actually looked at what i was typing.
most of my prompts are not "build me this". most of my prompts are me correcting an assumption the model made and never mentioned.
it decided a text field didn't need a max length. it decided a number should be a string. it decided a column could grow forever. it decided the happy path was the only path. none of those are refusals or errors — they're quiet defaults, and every one of them costs a prompt to undo.
and noticing is the expensive part. the model can't tell you what it assumed, because from its side it didn't assume anything — it just filled a gap i left open. the gaps i leave open are exactly the gaps i don't know are gaps.
which is why context does so much work here. a fresh session with no idea how our app is built will reinvent decisions we settled months ago, and i'll spend prompts putting them back. the prompts i save by writing a proper spec up front are the cheapest prompts i'll ever save.
the benchmark i actually want
every model comparison i read measures the wrong thing. speed of generation. lines of code. whether it one-shots a snake game.
none of that is my job. my job is the distance between a prototype and something i'd let a school run their fee collection on.
by that measure the interesting question about any model is not "can it build this" — it's "how many times will i have to correct it before this is real?" i'd take a slower model that assumes less.
why i'm writing this down
because this curve explains almost everything else i've learned this year, and i didn't see the pattern until i started counting.
the frontend that showed pages while the backend sent all 5000 rows — an assumption i didn't correct. the dashboard where all eight graphs fetched separately — same. the migration that added a column for data we already stored — same. the service that imported the adapter directly — same. the dropdown guarded with a length check — same.
five posts, five different subsystems, one shape. every one of them was the model filling a gap in my instructions with something reasonable-looking, and me not catching it until someone else did.
i used to read those as separate lessons about pagination, about schemas, about layering. they're not. they're all the same lesson about where the work moved.
so i'm still counting 🙂
#buildinpublic #softwareengineering #ai #vibecoding #learninginpublic #maahitatechnologies