Theo’s Case for Promptable Features

Executive Summary

Some feature requests are really requests for answers—and that changes what deserves permanent engineering work. In “Make Your Prompts Dumber”, published October 18, Theo argues that agents can provide one-off analyses, visualizations, and investigations without developers first building a dedicated interface for each request.

The useful distinction is not prompting versus engineering. It is temporary outcomes versus reusable capabilities: ask for the former, engineer the data access and tools that make them possible. This is a concrete practitioner argument illustrated through his own T3 Code workflows, not independent evidence that conversational interfaces outperform conventional products across the board.

What Happened

Theo’s clearest example starts with a request for a feature that breaks down tool-call durations. Instead of adding a performance dashboard, he asks an agent to analyze the history already available on his machine. The resulting report identifies unusually long searches, giving him something actionable without a purpose-built reporting screen.

He repeats the pattern with a context-window visualization: request the view, let the agent generate it, then change it through follow-up instructions. The point is not that dashboards are obsolete. It is that a bespoke answer can be valuable even when demand would never justify maintaining another product feature.

The more substantial example is support triage. Theo describes initially designing an elaborate diagnostic flow, then replacing much of that orchestration with a command that gathers machine context and launches an existing coding assistant with a support playbook. The assistant asks what went wrong, investigates, checks upstream fixes, and prepares an issue when appropriate.

Crucially, this is not an absence of engineering or instructions. The workflow still needs accessible diagnostics, a reliable entry point, and explicit guidance—including removing secrets before filing issues. The simplification comes from delegating a branching conversation rather than encoding every conversational branch in application code.

Why It Matters

The title’s provocation understates the actual design lesson. Users can make simpler requests because someone has done the harder work of making useful information and actions available underneath them.

Theo identifies the remaining engineering work directly: expose missing diagnostic data, connect systems, provide tools agents can invoke, and create better surfaces for generated outputs. His example of rendering problems is especially revealing. An agent cannot investigate past application behavior if the relevant events were never recorded. A better prompt cannot recover nonexistent telemetry.

There is also a practical boundary between improvisation and reuse. When the same request recurs, he recommends turning it into a reusable skill or standing instruction. That is a more discriminating position than “everything should be chat”: explore cheaply, then formalize what repeatedly proves useful.

These examples remain demonstrations and self-reported experience. They do not establish comparative accuracy, maintenance savings, or support-resolution rates. The strongest supported conclusion is narrower: some requests that look like missing software features can already be satisfied by combining existing capabilities differently.

The Bigger Story

Theo also addresses the anxiety that prompting makes engineers less like engineers. His answer is that the work moves: away from implementing every individual interaction and toward building the systems that let many interactions become possible. That is an account of his experience, not a prediction that every developer will find the transition rewarding.

The distinction between capability and authority still matters. Making information readable does not automatically justify making every associated action executable. A generated diagnostic view and permission to change a production system are different design decisions.

The durable idea is therefore bounded: build reusable access and controls; avoid hard-coding every occasional question into the interface. The engineering has not disappeared. It sits beneath a wider range of requests.