Nate B Jones explains "contract-first prompting" as a structured technique for resolving intent ambiguity before an LLM begins work
A solo presentation by Nate B Jones on a prompting technique he calls "contract-first prompting."
Summary
Nate B Jones presents a prompting technique he calls "contract-first prompting," arguing that the most common reason prompts fail is not poor wording but insufficient communication of intent. He draws an analogy to software engineering contracts — the technical specifications teams write to define how microservices interact — and applies that concept to human-LLM collaboration. Rather than asking an LLM to generate clarifying questions freely, which he describes as scattershot, his approach structures the LLM to systematically identify gaps in intent, ask targeted questions one at a time until it reaches 95% confidence, and then present an "echo check" summary for the user to approve, edit, or interrogate before any work begins. He demonstrates the technique with two examples: a deliberately ambiguous 500-word history summary request, and a software project he is actively developing.
Key Takeaways
FULL TRANSCRIPT
The Core Problem: Intent Ambiguity in Prompting
Nate B Jones: Almost every prompt that fails fails because intent wasn't clearly communicated. Human language is really, really rough on intent. And it's not just a function of a particular language. It's not just a function of the fact that it's human language. It's really the fact that we as individual people bring so much domain expertise. We bring so much passion. We bring so much energy, so much experience to a particular subject we want to work on. And we try and convey it in these words to the LLM and say, "Please work on this with me." And I will tell you, even as someone who's relatively experienced with prompting, it is also frustrating for me sometimes. I also struggle with getting that intent across in a way the LLM understands.
Introducing Contract-First Prompting
I want to suggest a technique I haven't seen elsewhere that I've had success with. It's called contract-first prompting. And you might think to yourself, contracts — are we signing things? No, that's not what I mean. I mean contracts in the sense that engineering teams use them, where they write contracts and agreements with one another about how their microservices will interact, what the service level agreement will be, what the latency will be, all these technical specifications. In the same way, we need to get to a point where we have very tight, technical, shared understanding with the LLM of the meaningful work we want to do together before it starts to work.
And that has been very difficult to do. And I am not satisfied with the usual answer here, which is just to ask the LLM to ask some clarifying questions. People report success with that. I have also had some success with that. But I want to emphasize that that is a very scattershot, unprofessional approach to actually dealing with this issue. You are giving the LLM — which is swimming in a sea of ambiguity — free rein to pick a question that it thinks may help. You are not really giving it any parameters or structure around that question set so that it knows it got it right and it knows that it understood your intent. And that is why asking clarifying questions can be helpful but not sufficient.
Walking Through the Contract-First Prompt
So what's better? What does contract-first prompting look like? We're going to actually look at a prompt I wrote that illustrates contract-first prompting, and I am going to talk you through it. It's quite fun.
I want to call out each of the key elements here. I am not a believer in trying to claim that there are magic words in prompting. Everything has a reason, but obviously you are going to be able to build these in ways that are useful to you. So it's not that this is the only way to build a contract-first prompt. I want you to walk away with the intent, not the magic words.
First of all, it's always good to give an LLM a mission. "Your goal is to turn my rough idea into a very clear work order." I am assuming you have work that matters here — so maybe it's building educational materials, or a PowerPoint presentation, or the script for a PowerPoint presentation. I don't expect ChatGPT to do a great job with a PowerPoint presentation directly. Or maybe it's building software. Whatever it is, it is meaningful work, and it will deliver the work only after both of us agree it's right — which is the critical contract piece to this.
So what goes into this? Number one, we need to make sure that it understands what the gaps to goal are, what the gaps to intent are. And so when you write and print this thing initially into the chat and say go, it's first going to say, "I'm ready. What do you need?" And you're just going to write out a rambling sentence or two, because so often when we're defining work, we don't know any more than a sentence or two. And that's what stops people from doing a better job prompting initially. So you just write what you have. It can be really messy.
It's then going to silently scan and list every fact or constraint that it still needs. And then it's going to start digging. It's going to ask one question at a time until it gets to 95% confidence that it can ship the correct result. And this gives it some examples of places to dig — purpose, audience, facts, success criteria, length, tech stack if code, edge cases, risk tolerance, etc. But I will tell you from experience running this prompt, that is not an exhaustive list. It will go other places.
The History of the Bacans: A Test Case
An example that's really useful — I wanted to really stretch it with a highly ambiguous human prompt. And so I asked it for a 500-word summary of the history of the Bacans since 1660. Why? Because that's pretty ambiguous. There's a lot that goes on since 1660 in the Bacans. And you know what it figured out? It figured out that one of the key leverage points to writing a good 500-word summary was how it was going to handle the evolution of political entities and their naming conventions across all of that time period. It needed to figure out what kind of scope I wanted so it could cover the arc of history in a way that made sense for my work assignment. And so even though it wasn't named as a constraint, it had three or four rounds of questions for me, asking me to pull apart my intentions around political entity discussion and description for this 500-word description.
And by the way, why did I put 500 words? Because I wanted to challenge it. Shorter is harder than longer here. And it eventually got to something that was a really solid summary of Bacan history since 1660 — in 1,600 words. And all of that clarification was really helpful.
The Echo Check and the Decision Menu
The echo check is when it thinks it's close. It replies with a crisp sentence. It states the deliverable. It states something that it knows it needs to include. And it states a hard constraint — designed to make it a very easily readable summary of work that you can engage with.
And then this prompt has what is effectively a mini program inside. You can say yes and lock it. You can edit it. You can ask for a blueprint or outline of what's going on. Or you can call out the risks and ask the LLM to define what's risky about the prompt as it stands. And it gives it directions for what to do in each case. How to handle yes to lock is very intuitive. Edits are intuitive. But it defines blueprints and risks so the LLM understands them.
When it's building and self-testing, it gives it special instructions for how to handle code — so it's responsible and reminds it to review code, which is something I could have extended into documents, etc., but code is often error-prone, and so I thought that was worth it. And it gives you the option to reset.
Why This Works Without a Long Prompt
This is really short. You might wonder, how on earth does this work? Well, it turns out you don't necessarily need a long prompt to get to contract-first intent. You just need clarity around the sequence of steps. All we're doing is: one, list the gaps to goal — which I almost never see in prompts. Two, dig for those gaps until you get to 95% confidence. And then from there, offer a path forward that I can choose and control, because we're trying to write a contract together.
Is this the only way to write contract-first intents? Absolutely not. Is it a really useful way to talk about getting to clarity of intent? Yes.
Applying It to a Software Project
And I didn't just do this with history. I did it with software. I've actually been working on a software project because I'm interested in centralizing comments in live streams across multiple channels. So I've been playing around with a software idea for that. And it's again ambiguous. How many channels? What do I include? What counts? What's an MVP? The number of users. All of these things that I could try and put into a heavy PRD prompt initially, but I'm not really there yet. I really want to just talk about it, and I want to talk about it in a structured way.
This was really useful for that, because I could actually say, "I really want you to produce a PRD for this, but I don't have the intent yet — so dig with me until we get to an agreed contract of work to produce a PRD with clean, clear intent." And it did.
Prompting That Assumes Humans Are Humans
Now, if you look at that and it feels really obvious to you — congratulations. That means it should exist in the world and you should try it. But I will tell you, I have done a fair bit of digging. It is not as obvious as you would think. This is not a technique that I can find other places. And I'm a little bit surprised, because I think it's a very token-efficient way of getting to clarity of intent when we assume that humans are humans.
And I'm increasingly interested in prompting techniques that assume that humans are humans. We are not perfect. We do not always write the full prompt out. We do not always have the full, crisp, complete intent. In fact, mostly we don't have any of those things. What we have is a vague human idea backed by a tremendous amount of context and experience, and we need help fishing that out of our heads and getting to clarity. That is what a contract-first approach to prompting seeks to do.
How can we get to a point where the LLM deeply, fully, completely understands your intent with this piece of work — in a way that you can just converse with it, let it ask you questions, and let it dig that out for you?
You might think this is only for product managers — PMs need to get clarity on intent when writing requirements — or it's only for this or only for that. This is a very intentionally wide-ranging prompt set. It is supposed to be something that is workable for virtually any piece of serious work where you need to define intent first. And I wrote it that way on purpose, because I think our use cases for AI are really wide-ranging. Any survey you see, any white paper you see on how we use AI — we do a lot of different kinds of serious work. But the common failure mode remains clarity of intent. That is what this is designed to fix.