Most people use AI like a vending machine. Question in, answer out, quality a matter of luck and phrasing. Then they conclude the machine is either magic or useless, and both conclusions are wrong the same way: they treat the tool as the variable, when the variable was always the person holding it.
The Thought-Partner Code is my answer to that. Six principles for working with AI as a partner in thinking rather than a machine for answers. They were not written in a retreat or workshopped on a whiteboard. They were built under load, out of real project work, then stress-tested the hardest way I know: I turned them into a training game for project managers, sixty-two scenarios of real decisions, and watched which principles held up when the choices got uncomfortable. These six held.
They are not prompt tips. Prompt tips expire with the next model release. These are about what stays human no matter how good the models get: defining good, thinking clearly, checking what you are told, understanding before you ship, deciding together, owning the outcome.
1. Define good first
Decide what good looks like before you touch AI: the question you are asking, the bar the answer has to clear, the outcome you are after. Measure when it matters. Do not wait for a metric to start thinking with a partner.
Measurement has its place. Running AI at scale, baselines and time saved and error rates are how you prove it works, and this principle asks for them. But the Code is not a measurement program with a thinking habit attached. It is the reverse. The value of a thought partner shows up first in the quality of the thinking: the assumption caught before it hardened, the option nobody had considered, the plan argued with before reality did it. None of that needs a stopwatch to be real. Define good so the partnership has an aim. Count what you can, when counting is the job, and never let the absence of a metric talk you out of the thinking.
2. Think with it
Make AI ask you questions, steelman the other side, and pre-mortem your plan. A draft is the start of the thinking, not the end.
The most valuable output a model can give you is not a document. It is a better question, asked before a bad assumption locks. Used this way, AI is a sparring partner: it argues the sponsor’s case, plays the skeptic in the steering committee, walks your plan into the wall before reality does. Accept its first draft as your thinking and you have not gained a partner. You have hired an extremely fast typist for your first idea.
3. Verify before you trust
Trace what the AI gives you to where it came from, starting with the facts that carry weight.
Here is the uncomfortable truth about a fluent machine: it can be wrong beautifully. A paragraph can be structured perfectly, sourced convincingly, and be built on a date that does not exist, a number that was never real, a quote nobody said. Plausible is the most dangerous quality AI output has, because plausible is what makes us stop checking. So the habit is simple and universal: treat everything the model hands you as a draft of the truth, not the truth. The facts your decision, your argument, your published words will stand on get traced to a source. The rest can ride. Not suspicion of the tool, then. Respect for your own name, which is the one attached to the output when it leaves the room.
4. Understand before you produce
Build context the AI can think with: projects, notebooks, agents, structured sources, watched over time. Your understanding is the deliverable.
The beginner uses AI on one document at a time, out of context, and wonders why the answers are thin. The practitioner builds context like an asset. A project space holding everything known, a notebook where sources accumulate instead of evaporating, agents monitoring what changes, flagging what contradicts itself, surfacing what went missing between versions. Run this way, the machine stops being a vending machine for summaries and becomes a research partner with a memory. But the summary it hands back is still not the product. The product is what you now understand and can defend in a room. If you cannot explain it without the model open, you did not finish the work. You outsourced it and kept the accountability, which is the worst trade in this entire field.
5. Bring people in
Use AI to surface differences and prepare the conversation. The team decides together.
The fastest way to misuse a thought partner is to let it replace the conversation it should be preparing you for. Its proper job in a team is upstream of the meeting: lay out where the stakeholders actually disagree, name the trade-offs in language each side recognizes, draft the options honestly. Then bring it to the people as a decision, not a problem: what needs deciding, what each path needs, and what moves forward once it is decided, because alignment produced by a model is fiction, and alignment produced by people who argued it out is the only kind that survives contact with a deadline.
6. Own the call
Keep people, sensitive data, and consequential decisions human. Knowing when not to use AI is part of using it well.
This is the principle the other five answer to. There are rooms AI does not enter: the conversation about someone’s performance, the data that was never yours to paste, the decision whose consequences a person has to carry. A code that only tells you how to use a tool is a manual. A code that also tells you where the tool stops is a practice. When the call is yours, make it, sign it, and be able to say why without pointing at the machine.
How to use the Code
Take one real task this week and run it against all six. Define what good looks like before you open the tool. Make it question you before it drafts for you. Trace the facts that carry weight. Read until the understanding is yours. Bring the disagreement to the people, not the summary. Then notice which decisions you kept, because those are the job.
The Code connects to The Maturity Curve, my series on enterprise AI adoption, the way a practice connects to a diagnosis. The Curve is about what happens to organizations. This is about what a person does on Tuesday. Both start from the same conviction: the tool is not the transformation. The thinking is.
This page is the canonical version of the Code and will be revised as the practice teaches me more. The principles have survived a training game, a year of program work, and every model release since. I expect them to survive the next one too, because none of them is about the model. All six are about the person.
