Stop Over-Engineering Prompts: An Engineer's Guide to Agent Thinking

Over the past two years, Prompt Engineering has been packaged as a "new discipline" that requires deep study—you have to phrase things precisely and layer on constraints to make an Agent obey. A tech blogger who has long built AI tools directly rejects this narrative in a video: the problem isn't that engineers aren't prompting in a sufficiently engineered way, but rather over-engineering—turning something that could be solved with a single sentence into an elaborate system.

The truly scarce skill isn't writing more intricate Prompts, but stepping back first to think clearly: what doesn't need to be "built" at all, and only needs to be "asked."

Starting from the XKCD Comic: Ordinary People Don't Understand Tech, Engineers Don't Understand Agents

The video cites a classic XKCD comic: a product manager asks an engineer, "When the user takes a photo, can the app tell whether they're in a national park and also whether there's a bird in the photo?" The engineer's answer is that a GPS lookup is "a few hours' work," while bird recognition "would take a research team five years"—because back then, that amounted to inventing AI from scratch.

The contemporary significance of this punchline is that it's now inverted. Ordinary people underestimate technical complexity, while today's engineers go to the opposite extreme: they habitually break everything down with a coder's mindset, to the point where it never occurs to them to just ask an Agent. The blogger says he recently talked with a founder fresh out of Y Combinator, who was stunned that "Agents can do this much"—many people haven't yet experienced that first cognitive unlock.

XKCD is a long-running webcomic created by Randall Munroe, centered on programmers, physicists, and geek culture, and often used to skewer the tech world's misjudgments about complexity. The comic referenced here (originally titled Tasks) dates from around 2010, when computer vision still required a dedicated research team to tackle, which is why "recognizing birds" was estimated by the engineer at five years of work. Today multimodal models can directly look at an image and answer such questions, so the punchline has flipped: what's truly outdated isn't the technology itself, but engineers' lagging awareness of "what can already be answered with a single question."

The Things You Think Are Features Are Actually Just Information

The blogger shares a firsthand case. He and a friend audited all the tool calls an Agent made on the local machine and found that the bash commands Claude wrote for the zsh environment were often incompatible, leading to a high error rate. The friend then suggested: I really wish there were a feature that tallies the time spent on each tool call and identifies the slowest commands so we can optimize the environment.

His answer was: "We've had that for ages, and it's on mobile too." In the demo, he created a new thread and simply told the model—break down all the tool calls on this machine, find the slowest ones, and give optimization suggestions. A few minutes later, a detailed report was generated, showing that one search of the home directory had run for 41.7 minutes.

His conclusion is worth writing down: many things treated as "features" are essentially just information. If the information can be obtained another way, it shouldn't be turned into a button—it should be exposed as an interface that can be queried.

Context Visualization: A Hidden Button

Likewise, he had the Agent generate a visualization of the context window usage for the current thread. It revealed that the proxy configuration had been making every request carry 70,000 tokens of redundant context—unnoticed for two whole months. And the team actually had a context usage button; it was just buried among legacy features. This反过来 demonstrates: with models as capable as they are now, manually managing context is a very low priority.

A tool call is a protocol-layer mechanism by which an Agent interacts with a large model: the model outputs a structured function name and parameters, the runtime executes them, and then feeds the results back to the model to continue reasoning. When models like Claude and GPT connect to environments such as a shell, file system, or browser, they perform actual operations through this layer. The so-called "tallying the time spent on each tool call" is already a piece of metadata sitting right there in the runtime logs, and the model can aggregate it with a script—this is exactly the technical basis for the article's claim that "the information already exists; all that's missing is an interface for asking."

A Counterexample: I Once Turned a Simple Problem into a Complex System

The blogger admits he's fallen into this trap. He had long been envisioning a "run dashboard" feature for T3 Code: list all tasks, show their status, let the Agent batch-rename threads, close threads, and merge PRs. He kept adding buttons until he realized—all of this could be done as a single meta conversation thread where the user just says, "Merge whatever should be merged."

He distilled this lesson into a criterion: if you find yourself needing to support "every path the user might need," that means you're building a complex feature with too many branches and too many holes. You can't possibly know how the system will fail—if you did, you'd have fixed it already.

T3 Triage: From Thousands of Lines of Code Down to 5 Lines of Code + 30 Lines of Markdown

The most telling example is the troubleshooting tool he built, npx t3 triage. The initial idea was an elaborate branching flow: ask a question, wait for the user's answer, trigger a hook to move to the next stage. Halfway through writing it, he stopped, wrote the entire flow as one very long Prompt and shoved it straight into Claude Code or Codex—letting the model itself ask in sequence about the symptoms, request screenshots, read machine information, clone the open-source code to locate the bug, check whether upstream has already fixed it, and finally, after scrubbing sensitive information, submit or reuse a GitHub issue.

Result: the complex feature became 5 lines of code plus 30 lines of Markdown, and it worked even better. He even abandoned the engineering implementation of "support pasting images"—just let the model ask the user to paste an image directly.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024 for exposing external applications, data sources, and tools to AI clients in a standardized way—think of it as the "USB interface of the Agent world." What the article means by "exposing an application's interfaces through MCP" is that an app no longer needs to build a separate UI button for every operation; instead, it registers its capabilities as primitives, letting any Agent invoke and combine them through conversation. This is in line with the "feature vs. information" argument: what gets exposed is a composable surface of capabilities, not a set of pre-defined fixed paths.

Bringing "Asking Thinking" Back into Engineering Practice

The blogger stresses that this isn't an argument for laziness or burning tokens—quite the opposite: once you realize that some things "aren't worth doing" in general yet hold unique value for you right now, you'll start doing more of them—generating deep visualizations to investigate a bug, merging your music listening history with Last.fm data into a personal platform.

Going a level deeper is building infrastructure for Agents: exposing an application's interfaces through MCP so other Agents can access and control it; building data pipelines so prompts can do more. He describes his state over the past year: he wrote five Rust applications and understands modern memory management more deeply than ever, because he needs to prepare for a future where an Agent runs on nearly free compute; he's even building his own JavaScript runtime and his own compiler.

"I feel more like an engineer now than ever before." This sentence is the core of the whole argument—it's not that AI makes people dumber, but that the center of value has shifted from "writing code" to "designing systems, exposing primitives, and building pipelines."

The Most Practical Advice: Connect Your Email to AI

The video ends with advice that sounds counterintuitive: connect your email to tools like ChatGPT. The blogger has five inboxes, four of which he needs to actively watch, and he nearly built his own email client. After injuring his hand, he was forced to try connecting multiple accounts, and as a result, the frequency of checking his inbox dropped from about ten times a day to about once—most of the time he just asks the Agent. Combined with tools that can monitor specific emails, he can do this: see an email about a high AWS bill, ask why the cost went up, then have the Agent spin up multiple threads to change the code and cut costs.

Behind this is a complete chain: email triggers → analysis → dispatch Agents → produce changes. He says that after connecting these pipelines, he has never felt more like an engineer.

On the Pain of "Skill Depreciation"

The blogger doesn't dodge the negative emotions. He admits there was a low period: the things you cared about most in your career—languages, frameworks, details—suddenly seemed to matter less, making you feel like you're regressing. He calls this the "valley of despair," but he also offers a way out: once you hit the boundary of what AI can't do, you'll find there's more to build than ever, deeper and more requiring ingenuity.

For engineers still in the throes of it, his judgment is: most people are at the tail end of the curve, not the endpoint. The problems worth building have grown more complex, and the complexity one can build independently has also increased—both the total amount of engineering and the density of thought are rising, only the form has changed.

His last sentence is for the skeptics: you can say I've been bought by OpenAI, and that would indeed be easier. But for those who truly love building, there has never been so much to build.

One-line Summary

Engineers' common failing is over-engineering prompts and features, turning information that could be obtained with a single question into complex systems.

Paragraph Summary

Opening with the inversion of an XKCD comic, the article points out that engineers habitually break everything down with a coder's mindset, and as a result never think to just ask an Agent. The author uses firsthand cases to show that needs treated as "features"—such as tallying tool call durations or visualizing context window usage—are essentially just information, obtainable with a single prompt; his own run dashboard and T3 Triage troubleshooting tool also shrank from thousands of lines of multi-stage flow to 5 lines of code plus 30 lines of Markdown, and worked even better. From this he derives a criterion: if you need to support every path the user might need, the feature has too many branches and is bound to be full of holes. The real investment should go into building infrastructure for Agents—exposing interfaces via MCP, building data pipelines, providing primitives, and connecting systems like email to AI to form a chain from event trigger to multi-threaded execution. The author also confronts the pain of skill depreciation, arguing that after passing through the valley of despair, the problems worth building are deeper and larger, and the density of engineering thought rises rather than falls.