Tell AI Why, Not How

In a blog post, software engineer Sean Goedecke argues that when you give frontier AI agents a task, you shouldn’t just play commander and dictate concrete steps; spell out your end goal, the reasons behind it, and how you trade off your priorities.

Core Shift: AI Is No Longer a “Dumb Kid”; What It Lacks Is the Big Picture

• Earlier AI (enthusiastic idiots): You had to explain what to do in extreme detail, such as “method A exists on class B, please add an equivalent method to classes C through F”; otherwise it would do entirely the wrong thing.
• Today’s top models: Going off track is usually not because they failed to understand, but because they made incorrect assumptions about your intent. For instance, when GPT-6-Astra thinks the code is only for its own eyes, it writes minified code with the whitespace and formatting stripped out. Flask author Armin Ronacher speculated that this is because the model learned to write as short as possible to save tokens during tool calls, and that habit leaked into code meant to be committed: by his measurement, unit tests written this way save about 10% of tokens compared to formatted code. He also found that the more a step looks like nobody is watching (such as subagent work or test code), the more often this style shows up, though he also said he isn’t sure whether the model genuinely thought nobody was watching. Conversely, just tell it that people will read the code and it writes code humans can follow: Sean used it to write Go and got several thousand lines of “acceptable” code (he only tried this on Go). In a human-written codebase you don’t even need to say that; it picks up the style of the surrounding code on its own.

Key Operating Principles: Tell It the “Why” and the Tradeoffs

• Clarify high-level goals rather than locking in implementation paths too early: Explain clearly what you ultimately want to solve first, rather than handing over a concrete technical specification right away. Once the approach is locked in, the model can only follow it and can’t use your goal to help you find a better solution. When Sean started the Deckard project, about half of his prompt was context: he wanted to build a local program or browser extension that automatically hides AI content on web pages, in the short term he needed a detection model that wouldn’t make his MacBook hot or run down the battery, and the tool was for his own use.
• Leave room for flexibility to avoid missing optimal solutions: You can write down your own technical ideas, but phrase them as a starting point for discussion rather than orders. In his prompt, Sean presented EditLens and RoBERTa only as “my guess”, and added a sentence at the end: if you see a better way to achieve my goals, let me know and we’ll talk about it. His assessment was that if he had written a rigid technical specification from the start, he would have missed out on native messaging and the Gradient model that were ultimately used. This project was built by Sean and Astra together: he made a series of big-picture calls and could pick languages he knew less well but that were better choices (C++ instead of Python for inference); the model, meanwhile, reminded him of approaches he hadn’t thought of himself, such as using native messaging instead of local HTTP.
• Spell out “relative priorities”: When specifying technical requirements at work, don’t list avoiding bugs, observability, fitting cleanly into the existing code, and performance and call them all important. Sean writes a dedicated paragraph that ranks them and says outright which ones he cares less about and is willing to trade away. That way, when goals conflict, the model knows which one to concede. Illustrative phrasing (example from this site): “The most important thing this time is not introducing bugs, followed by integrating naturally into existing code; keep observability at its current level; performance is not the focus, and some performance can be sacrificed for the first two.”
• Watch out for the “XY problem”: The XY problem refers to when you really want to solve X, but assume the answer is Y, so you only ask about Y. A classic example is someone asking “how do I print the last three characters of a filename?”, only for follow-up questions to reveal that they want the file extension, which is not necessarily three letters (such as .jpeg). Today’s models are already smart enough to offer useful feedback on your overall goals; giving them only concrete technical specifications without context is like seeing a doctor and only asking how to take a specific medicine—the doctor can’t help you find a better treatment.

Complete Example: The Prompt Sean Wrote for Deckard

Deckard is a Chrome extension built together by Sean and Astra that calls a small model running locally on a Mac to automatically highlight text on web pages suspected of being AI-written. Pangram, mentioned in the prompt, is currently about the only mature commercial AI text detection service, and EditLens is its model; Runpod is remote compute Sean gave the model access to via MCP to run experiments that were too hot, long, or slow to run locally. At the start of the project, he sent this prompt:

Hello. You should have Runpod access via MCP (if not, tell me and I’ll fix it).

I have the long-term goal of building a local program or browser extension to automatically scan pages I load for AI content and hide it. I have the short-term goal of figuring out the best AI detection model I can run on my macbook without killing my battery or making it hot, and (relatedly) figuring out how to run the model most efficiently. My guess is that Pangram’s EditLens 3B or the smaller Roberta model might be a good place to start, though they might require quantizing and will definitely require some work to make them run as efficiently as possible on my macbook.

I would like you to use my Runpod account to start answering these questions. Eventually we’ll move to doing things on this macbook pro, but my hope is that Runpod can help with some experiments that are too hot/long/slow to run locally. You are a smart model; if you can see a better way to achieve my goals, please let me know and we’ll talk about it. Good luck.

Look closely and about half of this prompt is context: the project’s overall goal, that it is for personal use rather than work, and that the laptop must not overheat or drain the battery.

This prompt asked two things: which model to choose, and how to run it on a MacBook without overheating or draining battery. The answers Deckard ultimately arrived at were:

• How to run it: Use native messaging, which the model suggested, so the Chrome extension calls the model program on the computer directly instead of running a separate local web service. It starts only when needed and shuts itself off after 5 minutes without use; while running it takes 400MB–1.2GB of memory, roughly equivalent to opening five or six extra browser tabs. Sean hasn’t noticed his MacBook Pro getting hot or losing battery life, though he says it may differ on other machines.
• Which model to choose: Not EditLens, the initial guess, but the MLX 4-bit build of Gradient (a compressed version that runs on Apple computers). It catches about 52% of AI text and misflags about 2.7% of human writing as AI; the commercial service Pangram claims to catch 99.66% with a false positive rate of only 0.004%—a significant gap. Sean felt it was good enough: you don’t need to catch every sentence in an article, since flagging a few spots is enough to make you suspicious; but with false positives around 2%, a single flag can’t be treated as proof.