Treating Prompts Like Code

June 1, 2026

Most people treat a prompt like a sticky note. You scribble something at the model, it gives you something close enough, you tweak the wording, and when it finally works you move on. The prompt itself is disposable. The output was the point.

I stopped working that way a while ago, because the sticky-note approach has a problem: a prompt that worked once is not a prompt you can trust. Run it again next week and it drifts. Change a line and you can't tell whether you fixed anything or just got lucky. When it fails, you have no record of why. These are the exact problems that code has before anyone bothers to give it structure, and we solved them for code a long time ago. I started treating my prompts the same way, as versioned artifacts with typed inputs, evaluation criteria, and a log of every change and the reason behind it.

I keep each one in what I call a prompt doc, and it has the same parts every time. There is a purpose and a problem statement, so future-me remembers what this was even for. There are typed variables, which are the inputs, named and described like function parameters. There's the context the model needs, meaning which files to read and which data to pull. There are the instructions themselves. There are constraints and guardrails, which is a polite way of saying the list of things it got wrong before. There are evaluation criteria, so that "did it work?" is a question with a clear answer instead of a vibe. And there's an iteration log, version by version, with what changed and why.

That last part is the one that earns its keep, and the best way to show why is to walk through a real one.

My Weekly Meal Planner started as a single sentence: read my pantry inventory and give me a week of dinners. Version one did exactly that, and it was fine, until I noticed it kept serving me ramen three weeks running. So version 1.1 grew a rule to check the last three weeks of plans and never repeat. Then it confidently put an ingredient on the shopping list that the recipe didn't actually call for, because it had guessed at the recipe instead of reading it, so version 1.2 added a hard rule to verify every recipe before listing a single ingredient. Later it started planning meals around food I'd already eaten, because my pantry file had drifted out of date, so version 1.5 added a step where it audits the pantry with me before it plans anything at all. By version 1.6 it had learned that running the oven in summer is a war crime, and started defaulting to the air fryer and the Instant Pot in hot weather, or leaning on no-cook meals.

None of those versions were rewrites. Each one was a single bug, caught in the real world and then nailed down so it could never happen again. That is the entire trick. The iteration log isn't documentation I write for fun. It is a list of every mistake the tool has made, converted into a rule that keeps the mistake from coming back. A bug fixed in code stays fixed, and a bug fixed in a prompt doc stays fixed, too. That is the part most people miss when they treat prompts as disposable.

My Cover Letter Generator tells the same story in a different key. It exists because writing cover letters is miserable and I would rather not start from a blank page every time. Version one read the job listing and my resume and drafted a letter. It also, repeatedly, claimed I knew TypeScript, which I don't; I know JavaScript and can understand TypeScript, but I've never written a line myself. So that became a constraint. It kept writing that I had "been called the CSS Whisperer," which is flattering but false, because I appointed myself the CSS Whisperer at the consultancy because everyone knew I could help them figure out how to make that thing show up in the right place, thank you, and that became another constraint. It defaulted to a corporate tone that sounded nothing like me, so I started feeding it my real letters to calibrate against before it wrote a single word. By version 1.9 I had banned it from opening with "the line in your job description that caught my attention is," because quoting a recruiter's bullet point back at them is what you write when you couldn't find anything real to say. No one applies to a job because they care about "enterprise infrastructure for the agentic era", something the prompt claimed once.

Nine versions, and every one of them is an apology for a specific thing the model got wrong and I caught. Read the log and you can see the whole relationship: the places it's lazy, the places it inflates, the places it forgets who I am. The prompt doc is where I keep all of that, so I don't have to re-litigate it every time I want to apply for a job.

Here is the payoff: When you treat a prompt as throwaway text, every session starts over, and the model is free to make the same three mistakes it made last time. When you treat it as an artifact, the failures compound in your favor. Each one makes the doc permanently sharper, and a fresh run gets more reliable instead of less. That is the difference between getting an AI to do something once and building a tool you can actually depend on, and the second one is the only one worth your time.

Lately I've been doing the same thing one layer up. A Claude Code agent is really just a prompt doc with tools and a job description attached, and a skill is one of these methods packaged so I can reach for it on demand. I build them the same way: write the spec, watch where it breaks, and fold every failure into a rule the next version inherits. The artifact gets bigger. The discipline doesn't change.

The models will keep getting better, and some of these specific guardrails will age out, which is fine. The method won't.

Version your prompts. Write down why each rule exists. Treat the log as the most honest part of the document, because it is.