Ask AI to summarise a document and it will produce something — complete, confident, reasonably structured. But a summary for who? How long? Focused on what? Without those decisions made upfront, any answer can feel good enough in one reading and slightly off in the next, because you’re not checking it against a fixed bar. You’re checking it against your mood.

Now try: “write a three-sentence summary of this document for a non-technical executive, covering only the business impact, not the technical steps.” That’s a standard. Three sentences — countable. Non-technical — checkable sentence by sentence. Business impact only — you know exactly what to cut if it wanders. The answer either meets it or it doesn’t.

This matters more for outputs that don’t have obvious right answers — summaries, drafts, analysis, strategy — where the model will always produce something that sounds finished. A finished-sounding answer and a correct one look identical on the surface. The only way to tell them apart is to have decided in advance what correct means for this specific ask.

Defining good first also changes the question itself. The act of writing “three sentences, non-technical executive, business impact only” forces you to commit to decisions you might have left vague — and those decisions often reveal what you actually needed, before any answer arrives. Sometimes it turns out the real task was different from the one you’d started typing.

“A problem well stated is a problem half solved.” — Charles Kettering, Head of Research, General Motors

That’s what defining good does — it finishes half the work before the model writes a word.

The practical habit: before sending any AI request where the output requires judgment to evaluate, write one line that describes what a correct answer would look like. Not the question — the answer. Length, tone, audience, what’s in scope, what isn’t. This takes thirty seconds and gives you something you don’t have otherwise: a way to stop.

For an individual, this is the difference between editing an answer and just reacting to it. Editing requires a target. Reacting is infinite. For a business, this is where AI-assisted work either holds a quality bar or doesn’t — and the gap between teams that produce clean, consistent output and teams that produce variable, re-worked output almost always traces back to whether someone decided what good looked like before the first draft was generated.

— Arvind, Rationale One short issue a week. No jargon, no hype — just the reasoning behind what’s changing.

“Can you help with this function, it’s not working right” isn’t vague because of weak prompt-writing — it’s vague because “not working” hasn’t been decided yet. Error? Wrong output? Slow? Each is a different task. The model can’t untangle what the person hasn’t, so it guesses, and the real question gets sorted out a few exchanges later, after a couple of misses that felt like normal back-and-forth.

Compare: “this function should return null for negative input, and it’s returning zero — find why.” Not faster to write. Slower, actually — the time went into deciding, not phrasing.

The test before you type: what, specifically, am I asking — not the general area, the actual question. If that doesn’t fit in one sentence, you’re not ready to ask, and any answer you get will be guessing at the same thing you are.

For an individual, this comes before format or context — they only matter once the question is decided. For a business, this is usually the real story behind “the AI gave a useless answer”: the question was never decided before the conversation started doing both jobs at once.

— Arvind, Rationale One short issue a week. No jargon, no hype — just the reasoning behind what’s changing.

Ask AI to write a discount calculation, and it writes something like this:

def apply_discount(price, discount_percent):
    return price - (price * discount_percent / 100)

This compiles. It passes the obvious test — apply_discount(100, 10) returns 90, exactly as expected. It ships, because nothing about it looks wrong. The syntax is clean, the logic reads correctly, and that’s exactly why nobody questions it.

The problem only shows up with real prices. apply_discount(19.99, 15) doesn’t return a clean number — it returns something like 16.991499999999998, because computers store fractional amounts like this imprecisely. No single test catches it, because no single transaction looks broken enough to flag. The function is wrong for currency specifically, while being syntactically perfect in every other way.

That gap doesn’t cost anything on day one. It costs something a few thousand transactions later, when fractions of a cent have quietly compounded into a real reconciliation mismatch, the books don’t tie out at month end, and someone loses a day tracing it back to one confidently written, fully-passing line of code. Compiling and passing tests were never proof the logic was right — only proof it resembled working code closely enough that nobody checked further.

That’s the same failure as a confidently wrong answer in plain language, just wearing different clothes: a plausible pattern standing in for verification that never actually happened, at every stage — the model that wrote it, the test that passed it, the reviewer who approved it.

For a business, the fix isn’t trusting AI-written code less. It’s recognizing that “it compiled, it passed, it shipped” was never a substitute for checking the actual logic — and that the real cost of skipping that check rarely shows up at launch. It shows up months later, in a discrepancy nobody can trace back to the one confident line that caused it.

— Arvind, Rationale One short issue a week. No jargon, no hype — just the reasoning behind what’s changing.

An AI model reads your entire message before it answers — every line, with equal seriousness, because it has no way to know in advance which parts matter. It isn’t skimming for the important bit; it’s working from all of it at once. That’s fine when everything you’ve included is relevant. It becomes a problem the moment it isn’t.

Here’s what that looks like in practice. An engineer trying to be thorough writes:

Incident notes: Reports started around 2pm. Checkout errors. On-call paged, checked dashboards, saw elevated error rates.
Related: March's outage had the same error code — caused by a stale DNS cache.
Also: Last week's deploy added a new fraud-check step to checkout.
Background: This quarter's goal is a 20% cut in checkout latency.
Problem: Checkout is failing for some customers.

Five facts, one of them real. Here’s what’s actually happening underneath: the model isn’t investigating this like a detective weighing clues one by one. It’s predicting the most natural-sounding continuation of everything in front of it — the same way it finishes a sentence, just at the scale of a whole answer. An exact, specific match, like the identical error code from March’s outage, is exactly the kind of strong, recognizable pattern that pulls a prediction toward it. So the model follows that thread: check DNS resolution, check the cache. The deploy note that’s actually relevant has no such pull — nothing marks it as different from the OKR line sitting right next to it, so it doesn’t stand out in the pattern being completed. The model isn’t being careless. It’s doing what it always does, finishing the most probable pattern in the text — and the prompt handed it a very convincing wrong one to finish.

Now the same problem, with only what’s load-bearing:

Problem: Checkout failures hit 8% during yesterday's flash sale — roughly $40,000/hour in lost orders.
Pattern: Failures cluster at the payment step once concurrent users pass 5,000.
Already checked: Payment gateway status (green), retried failed requests (still fail).

Three facts, and only one pattern available to complete: load rising alongside failures. There’s nothing else in the text pulling the prediction toward a different thread, so it follows the one that’s actually there instead of competing against a half-dozen others for which detail looks most like an answer.

The test for what belongs in a prompt isn’t length, it’s whether removing a line would change the answer. The March outage wouldn’t have changed it — it would have actively misled it. The deploy note might have, if it had been flagged instead of buried. Most people don’t run this test; they just add more, because more felt like the lesson last time.

For an individual, this is a single habit: before sending, ask what you’d lose by deleting each line. If nothing, cut it.

For someone leading a team, this failure is easy to miss, because it doesn’t look like a context problem — it looks like “the AI got something wrong,” and people quietly stop trusting it instead of fixing what they fed it. The fix isn’t less context. It’s teaching people to spot the one fact that’s actually doing work, and leave the rest out.

Format earns the model’s attention. Context gives it the facts. Knowing which facts to leave out is what makes the other two worth anything.

— Arvind, Rationale One short issue a week. No jargon, no hype — just the reasoning behind what’s changing.

Here’s what that gap looks like in practice.

An engineer asks:

Problem: Checkout is failing for some customers.
What I need: Ways to fix it.

Clean format, clear ask. But the model still has to guess everything that actually matters — how often this happens, when it started, what’s already been ruled out. So it returns a checklist: check the payment gateway, check for timeouts, check error logs. None of it wrong. None of it pointed at this problem.

Now add context:

Problem: Checkout failures hit 8% during yesterday's flash sale — roughly $40,000/hour in lost orders.
Pattern: Failures cluster at the payment step once concurrent users pass 5,000.
Already checked: Payment gateway status (green), retried failed requests (still fail).
What I need: Most likely cause, given failures only appear under high concurrency.

Same format. Same problem, even. But now the model has enough to actually reason instead of guess, and lands on one specific diagnosis: the payment service is almost certainly running out of available connections under load, not failing because of the gateway itself — which means the fix is raising the connection pool limit or queuing requests past the threshold, not retrying or restarting anything. That’s not a smarter model. It’s the same model, given enough to reason with instead of guess from.

This is the part worth sitting with: rich context doesn’t just produce one better answer — it produces the same good answer every time you ask. A vague prompt gets a different generic response on every attempt, because nothing anchors it; the model invents its own framing from scratch each time. Specific context works like a fixed reference point. Feed in the same numbers and constraints, and the model reasons from your actual situation instead of re-guessing it. That consistency is the real value — not detail for its own sake, but an answer you can trust will hold up the next time you ask something similar.

Some of what belongs in that context isn’t written down anywhere — it’s the instinct that made you suspect concurrency before anything else, built from having watched systems buckle under load before. Naming that instinct in the prompt is what lets the model reason the way you would, instead of the way a generic checklist would.

For an individual, the habit is small: before asking, spend ten seconds listing what’s actually specific about this situation — the numbers, what’s already been ruled out. For someone running a team or a company, this is the gap behind why AI adoption looks inconsistent even when everyone has the same tools: it’s not a tooling problem, it’s a context problem, and it stays invisible until you go looking for it.

Format gets the model’s attention. Context is what it actually has to reason with.

— Arvind, Rationale One short issue a week. No jargon, no hype — just the reasoning behind what’s changing.

Most people miss this. They treat the prompt box like a search bar: type, press enter, hope. But AI models don’t read like a search engine. They look for structure — headings, lists, sections, code blocks — because that’s what they were trained on. Almost every project on GitHub, every technical documentation site, every engineering wiki is written in Markdown. That’s the format the model’s understanding of “well-organized information” was built on.

When you write in clean Markdown, you’re not being pedantic. You’re meeting the model in the language it learned to read.

Here’s the difference in practice.

A typical messy request:

can you figure out why my login API keeps returning errors on mobile but not desktop and what should I check first I already looked at logs

The model has to guess what you actually want — a diagnosis, a checklist, a code review — and usually returns a long hedged answer covering all of it.

The same request, structured:

**Problem:** Login API returns errors on mobile, works on desktop.
**Already checked:** Server logs (clean), database connection (fine).
**What I need:** Top 3 things to investigate next, ranked by likelihood.

That reliably returns three concrete suggestions in priority order. Same information. Different structure. Different output.

The same pattern works for code reviews, design feedback, project summaries. State the input. State what you want back. Let structure do the rest.

This isn’t a clever trick. The model reads structure as meaning. Headings signal what’s coming. Bullet points signal parallel items. Code blocks signal raw input. Each piece of Markdown narrows what the model thinks you want.

The cost of getting this wrong is invisible. You don’t see the better answer you didn’t get. You get a mediocre one and move on, while engineers who structure their requests well quietly extract more value from the same tools.

For an individual engineer, spend the extra fifteen seconds to write the request as a short structured block. The output gets sharper. The habit becomes automatic within a week.

For someone leading a team, name it out loud. Engineers who treat AI interaction as a written skill will outpace those who treat it as casual chat. The gap won’t show up in any dashboard — it’ll show up in who ships faster and debugs cleaner. Train for it like you’d train for code review.

Markdown was never just a documentation format. It’s the shared grammar between engineers and the tools they spend half their day talking to. Treating it as a core skill — not a footnote — is what separates the engineers who’ll lead this era from the ones who’ll be confused by it.

— Arvind, Rationale One short issue a week. No jargon, no hype — just the reasoning behind what’s changing.

Claude, ChatGPT, Gemini, GitHub, Notion, Obsidian. Different companies, different purposes, all built on the same quiet format underneath: Markdown. That’s not a coincidence, and the reason behind it tells you something useful — whether you write code for a living or run a team that doesn’t.

Start with what AI tools actually need. When an AI writes you an answer, that answer has to be readable by you immediately, and it also has to be processable by other software without anyone translating it first. Most formats fail one side of that. A Word document looks fine to a person but is messy for software to read. A spreadsheet is easy for software but unreadable to a person at a glance. Markdown is just plain text with a few light symbols added — a # for a heading, a dash for a bullet — and both a person and a machine can read it the same way, instantly. That’s the whole reason every major AI assistant defaults to it. It’s the one format that doesn’t force a choice between the two audiences reading it.

It also helps that Markdown takes about ten minutes to fully learn. Most tools that add structure to writing — page layout software, complex publishing platforms — take real time to master. Markdown’s entire rule set fits on one page. And low effort to learn is not a small detail — it’s the actual mechanism behind why something spreads. The easier a tool is to pick up, the more people use it. The more people use it, the more other tools get built to support it. The more tools support it, the easier it becomes to keep using. That loop is the entire reason a niche blogging format from 2004 is now the default output of every serious AI system in 2025.

There’s one more thing worth knowing: a Markdown file never expires. It’s just text. No special software is required to open it, no subscription, no risk that the company behind some proprietary format shuts down and takes your files with it. A Markdown file written today will open exactly the same way in twenty years. Anything you write in it, you actually keep — not in a legal sense, just in the practical sense that nothing can lock you out of your own writing.

None of this requires you to know how to code. If you ever write instructions for an AI — a prompt, a brief, a set of guidelines you want it to follow closely — structuring it with simple headings and bullet points measurably helps the AI follow it more reliably. You’re not coding. You’re organizing your thoughts the way a clear-headed person already would, and that happens to be exactly the structure the machine understands best too.

And if you lead a team rather than write the instructions yourself, the pattern matters even more than the format. The tools winning this moment in AI aren’t always the most powerful or the most complex. Often they’re the simplest ones a person and a machine can both use without friction. That’s worth carrying into how you evaluate any new AI tool for your team — not “how powerful is it,” but “does it add complexity or remove it.” The tools that quietly remove complexity are the ones still standing in five years.

— Arvind, Rationale One short issue a week. No jargon, no hype — just the reasoning behind what’s changing.