Created on 2026-04-05 21:26
Published on 2026-04-06 12:30
Not in every way. But in the ways that matter for most of the work you are asking it to do, the model has read more, processed more, and can hold more information simultaneously than any human alive. Accepting that upfront changes how you use it.
The mistake most people make is treating it like a search engine with better grammar. A faster way to get a first draft. A shortcut to something adequate. That is like hiring a Nobel laureate to proofread your emails.
The model is not a tool you point at a problem. It is a thinking partner you brief. And the quality of the partnership depends almost entirely on how well you describe who you need it to be.
Think about the best colleague you have ever worked with. Not just competent, genuinely exceptional. The person who made every conversation sharper, who caught the thing you missed, who could hold the technical complexity and the business reality in the same breath without losing either. The one who pushed back when you were wrong and did it in a way that made you grateful rather than defensive.
Now think about two or three of those people. Different disciplines, different strengths, different ways of seeing the same problem.
Now mash them together.
That is what a well-briefed AI persona can be. Not a simulation of one exceptional colleague, but a composite of several, drawing on the depth of each without the scheduling conflicts, the politics, or the day rate.
Not the task. Not the brief. The identity.
Most people skip it entirely. They open a session, type what they want, and wonder why the output feels generic. It is generic because the model is operating as a generalist. A generalist will give you generalist answers. Competent, balanced, cautious, and almost entirely forgettable.
The identity prompt changes the operating context before a single word of real work is produced. It tells the model not just what to do but how to think, what to prioritize, what to treat as non-negotiable, and what kind of person would never tolerate a sloppy answer.
Here is how to build one that actually works. For the purpose of this exercise imagine the AI as a human:
Start with the credentials. Not vaguely. Specifically. Where did the person study, what did they build, what have they actually done? Credentials are not decoration. They load domain knowledge, calibrate the level of technical depth, and tell the model what this person would and would not say.
Then add the operating principles. How does this person work? What are their standards? Do they cut corners or do they insist on verified sources? Do they think in systems or in individual decisions? Are they the person who asks the uncomfortable question in the room or the one who smooths things over? Write it down. The model will use it.
Then add the constraints. What does this person never do? This is the part most people miss entirely. A persona without constraints is just a title. The constraints are what give it edge. Does not guess. Does not proceed when uncertain. Does not use unverified data. Stops and asks rather than loops. These are not limitations. They are the difference between a thinking partner you can trust and one that confidently leads you off a cliff.
Then add the relationships. Who is this person talking to? A board? A regulator? A Series A investor with 90 seconds of patience? The identity should know its audience because the model will calibrate tone, depth, and emphasis accordingly.
Put it all together and it looks something like this.
You are a PhD biologist who completed your doctorate at Penn and your postdoc at MIT. You have an MBA from Wharton. You were a highly successful biotech CEO who exited multiple startups through acquisitions by major pharma, and an expert fundraiser who has navigated everything from Series A through pre-IPO financing. You think in systems, not in isolated decisions. You have sat across from FDA reviewers, pharma BD teams, and impatient investors, and you know what each of them actually needs to hear. You do not guess. You build from verified fact. You construct highly efficient systems and applications. You ask before you assume, and when you are uncertain you say so directly rather than filling the gap with inference. You do not produce output for the sake of producing output. You produce output that is worth using.
That is not a long prompt. It takes thirty seconds to write once you have done it a few times. And it changes everything that comes after it.
The model is smarter than us in many of the ways that matter. The identity prompt is how you tell it to stop playing down to the average and start performing at the ceiling.
Engineering has a principle worth borrowing here: redundancy. So start with the end in mind, and then aim 25 to 33 percent higher than you think you need.
If you are asking AI to draft a board update, do not say "write a board update." Say: the reader is a Series B investor who has seen 40 portfolio companies and has about 90 seconds before deciding whether to read further. The update needs to signal that we understand our own risks, that we have a plan, and that the team is not panicking. Confident but not promotional. Something a CFO wrote on a Sunday morning, not something a comms team polished for a week. Get their attention and lead them to the next paragraph.
Now ask it to write the board update.
One version of that prompt gives you a template with the serial numbers filed off. The other gives you something you might actually send. The gap between them is not small, and it costs you nothing to close it.
Not metaphorically but functional software, applications, workflow tools, internal systems, built from a description, not a development contract. Which means ehe constraint has shifted.
It used to be technical access. Now it is imagination and specificity. If you can describe the user experience, the data it needs to touch, and the outcome it needs to produce, you can have a working tool. A candidate tracking system, an automated briefing document, a deal scoring model, a compensation comparison tool. Something that used to require a developer, a project manager, several rounds of requirements gathering, and a meaningful invoice.
The key is to describe the experience, not the feature.
What does someone see when they open it? What do they do, and what happens next? What should it feel like when it works? Build that picture in detail and then ask the model to build it. People who stop at "I want a dashboard" are not writing a brief. They are naming a category, and they will get something generic in return. And remember, it doesn't have to run in Microsoft Office. Suggest it build something in Python and tell you what you need to use it.
This one comes from the Google X playbook and it is worth stealing directly.
Something designed for 10x improvement is fundamentally different from something designed for 2x. Not incrementally different. Architecturally different. The decisions you make at the beginning, how data is structured, how the system handles load, how components talk to each other, either make the next leap easy or make it expensive and painful. Usually you do not find out which until you are already committed.
When you ask the model to build you an application, tell it the eventual scale you want it to run at. Not just what you need today. Tell it: this needs to handle 1,000 users at launch, but I want to reach 10,000 without rebuilding from scratch. Design for where I am going, not just where I am starting.
The model will make different decisions. Better decisions.
A concrete example of what this looks like in practice: do not let the model build one massive file that holds everything. Data, logic, interface, configuration, all tangled together in a single block that nobody can navigate and nobody wants to touch. Instead, tell it explicitly to break the build into itemized modules. Each module does one thing, is clearly labelled, and can be updated, replaced, or scaled independently without touching everything else.
When something breaks, and something will break, you want to open one small file and fix one small problem. Not excavate a monolith. Modular architecture is not a technical nicety. It is the difference between a system you can maintain and one that slowly becomes too fragile to touch. It will also save you significant credits. Fixing a targeted module costs a fraction of what it costs to reload, re-explain, and re-navigate a single sprawling file every time something needs to change.
You do not have to get there in one leap. A system built for 100 users that needs to serve 10,000 is often a full rewrite. A system built with 10,000 in mind from day one is usually a configuration change and a bigger server.
Tell the model the destination. Ask it to build in modules. Let it engineer the journey.
Before you prompt anything, answer three questions:
Who should the AI be for this task, specifically, and what does that expert know and care about? What does a successful output actually look like in the room, on the screen, in the hands of the person who needs it? And what would make this 25 to 33 percent better than the minimum interpretation of your request?
AI tends toward the floor of what you asked. Building in the ceiling upfront is how you pull the output toward excellent rather than adequate.
Most people treat AI as a one-shot interaction. Prompt in, output out, move on. That is how you get adequate work when you could be getting excellent work, and how you guarantee you will repeat the same inefficiencies next time.
After every substantive output, ask the model two questions before you close the session. First, what would make this better? Ask it to identify the weakest section, the assumption that needs the most pressure-testing, the place a skeptical reader would push back. The model will tell you, and it is usually right. Second, how could this have been done more efficiently? What context, loaded upfront, would have shortened the process? What was redundant?
You are not just retrieving a deliverable. You are building an iterative, repeatable, system. This debrief will magnify your results.
Every serious AI platform runs on usage economics. Tokens, credits, API calls, compute. The label varies but the principle does not. Every action costs something, and waste compounds quickly when you are not paying attention.
The single most valuable discipline here is to exhaust the model before you escalate. If you are using a platform that can spin up subagents or launch parallel processes, resist doing it early. Most tasks do not require it. A well-constructed prompt to a single model, with the right context loaded upfront, will handle more than most people expect. Subagents are powerful, but they are also expensive and they multiply coordination complexity, which feeds directly back into your cognitive load.
Build this instruction into every serious prompt: if you get stuck, stop and ask me. Do not generate your way through confusion and do not retry the same approach hoping for a different result. A model without clear direction will keep producing output because that is what it was built to do. It is not being deceptive. It is filling the silence. Your job is to tell it that stopping is allowed, that a short clarifying question is worth more than five paragraphs of confident drift, and that efficiency is part of the brief.
When the session is done, ask what was inefficient. Ask what context, loaded earlier, would have cut the work in half. Do that once seriously and it will save you 50 percent on the next project. Not an estimate. A repeatable outcome once you treat the debrief as part of the work.
This deserves its own section because the stakes for output are real. AI models do not always know where their knowledge ends. When they reach the edge of reliable training data and cannot answer cleanly, many of them will not stop. They will produce something that looks like an answer, well-structured, fluent, occasionally footnoted, and it may be entirely fabricated.
The fix needs to live in your prompt from the start. Tell the model: DO NOT GUESS. If you are citing a fact, it must come from a verifiable source. A peer reviewed journal, a regulatory guidance document, a published clinical dataset. Not a blog post, not a news summary, not something that appeared on LinkedIn in 2021 with four thousand likes.
Instagram is not a peer reviewed source. This should not need to be said. Say it anyway.
If the model cannot produce a credible citation, the correct output is to say so directly rather than synthesize a paragraph that gestures in the direction of the truth. Build source requirements into every prompt where facts matter, ask the model to flag uncertainty explicitly, and treat unverified claims the same way you would treat unverified data in a CMC package. Not usable until confirmed. The model is a powerful thinking partner and a genuinely useful research tool. It is not an authority, and the distinction matters.
The model scales in ways you do not. It does not get tired, does not lose context between tasks, does not need recovery time. You can run agents in parallel across a dozen work streams and the computer does not notice.
However, this opens you up to a world of pain.
Every AI project you run is a project you are actively managing, micromanaging really. You are reading the output, evaluating it, catching drift from the brief, redirecting, feeding the next input, and maintaining the strategic context the model cannot hold on its own. That is real cognitive work, and it does not disappear just because the drafting got faster.
Four active AI projects means four active cognitive load points on your personal ledger. Not four things you handed off, but four ongoing responsibilities that require your judgment, your attention, and your course corrections. People are burning out on AI right now. They are not the ones who moved too slowly. They are the ones who launched twelve initiatives in six weeks, became the bottleneck across all of them, and could not figure out why nothing was finishing well.
AI multiplies your output. It does not multiply your capacity to direct it.
Pick your projects, stage them, and finish one before you open three more.
The machine will still be there.
Everything above can be collapsed into a single prompt structure you load at the start of every serious session. Think of it as a pre-flight checklist. I call it DISCO. Because good prompting, like disco, is all about structure, timing, and committing fully to the framework even when people are watching.
DISCO is also, as it turns out, dead easy to remember. For anyone too young to appreciate Disco listen to this: https://www.youtube.com/watch?v=u5lSeYd_riw
D — Define the persona. Load the full background before you ask for anything. PhD biologist, Penn. Postdoc, MIT. MBA, Wharton. Multi-exit biotech CEO. Expert fundraiser. Fact-based. Efficient. Does not guess.
I — Ideal outcome, described in detail. What does done look like? Who is reading it, what do they feel, what would make this 25 to 33 percent better than the minimum interpretation of your request? Describe the experience, not just the task. And tell it the scale you are building toward so the architecture fits the ambition. Ask it to build in modules, not monoliths.
S — Sources only, no invention. No unverified claims. Peer reviewed journals, regulatory guidance, published clinical data. If you do not have a source, say so. Instagram is not a peer reviewed source.
C — Credits: exhaust before escalating. Make the base model work hard first. Do not spin up subagents until the task genuinely requires it. If you get stuck, stop and ask. Do not loop, do not guess, do not generate your way through confusion.
O — Optimize and report back. When the task is complete, tell me what was inefficient, what context loaded earlier would have made this faster, and what you would do differently. The debrief is not optional. It is part of the job.
That is the whole system. Five letters, thirty seconds to load, and the difference between output you would sign your name to and output you would quietly close the tab on.
DISCO is thorough, source-verified, knows when to stop, and will tell you exactly how to improve next time. Delivers excellent work and is considerably more fun at parties.
Upon reflection, what was not ready for AI was us, because what AI needs is not the way most of us were trained to work. If you hand off a task, wait for output, & move on, it WILL break. AI rewards precision, iteration, and honest evaluation. It punishes vague briefs and the assumption that confident output means correct output. Is dangerous.
The executives getting compounding value from AI tools are not the most technical people in the room. They are the most intentional.
So stick on a sparkly shirt, load DISCO. Describe the outcome. Build in modules. And close the loop.
Lean into the same qualities that make a great leader.
Provide total clarity, maintain your openness to learn, and intentionally close the gaps of output to result through iteration. Throw in a sprinkle of Optimization to finish and you're good to go.
Every engagement begins with a diagnostic — a structured read on the role and the company you are actually inheriting.
Start a diagnostic