The Chatbot Is the Worst Interface for AI

I think the chatbot is the worst long-term interface for AI, even though it has been the right short-term one. If AI remains primarily a box where we type requests and wait for prose, we will have spent an extraordinary technological breakthrough recreating customer support chat.

That position is intentionally sharper than “chat will coexist with other interfaces.” Of course it will. Command lines survived graphical interfaces, and forms survived both. But the interface that defines what AI is for should not be a blank prompt. It should be software that notices context, prepares work, takes bounded action, and asks for approval only where approval genuinely matters.

Chat made AI legible. It also made it passive.

The chat interface won because it solved a real adoption problem: natural language let people use a model without learning a query language, an API, or a new application. It also exposed the model’s strange strengths. You could ask for an explanation, a draft, a plan, a translation, or code, then revise it conversationally. For a new capability whose boundaries were unclear, that flexibility was a feature.

But chat pushes every task through the same ritual. I must remember that a task exists, collect the necessary context, describe the desired outcome, paste in artifacts, inspect the response, convert it into actions, and repeat when reality changes. The model may be intelligent enough to read a repository, watch a failing build, compare two contracts, or reconcile a calendar conflict. Yet the chatbot makes me serve as its scheduler, clipboard, integration layer, and permission system.

That is not automation. It is assisted authorship. Assisted authorship is valuable, especially for writing and programming, but it does not justify the claim that we are building agents. An agent that cannot observe the world without being manually fed a prompt is closer to a very capable function call than a colleague.

The real successor is not one super-agent

I do not expect a single omniscient personal agent with access to my bank account, production cluster, inbox, home, and codebase. That is science-fiction product design, and it is terrible security design. The useful post-chat future is a collection of specialized systems embedded in the places where work already happens.

A development environment should have an agent that continuously maintains a model of the codebase: dependencies, test health, recent changes, ownership, incident history, and unresolved risk. It should open a small pull request when a routine dependency patch is safe, prepare a migration plan when it is not, and tell me precisely why it needs a decision. A finance system should flag a renewal that exceeds its historical range, assemble the relevant usage data, and draft the cancellation or approval path. A calendar should not merely find a meeting time when asked; it should protect focus blocks, identify recurring meetings with no outcomes, and propose changes based on policies I control.

Notice what changes here. The AI is not replacing the application with a general conversation. It is becoming an operational layer inside the application. The visible interface may be a diff, an alert, a recommendation, a queue of decisions, or nothing at all because the action was pre-authorized. The user should encounter language when language is the clearest way to resolve ambiguity—not because every task must begin with a theatrical prompt.

Continuous context is more valuable than eloquent answers

Software engineers should care about this distinction because we know where the hard part lives. The impressive demo is the model producing a plausible answer. The useful system is the one that has the right state, calls the right tools, respects invariants, survives retries, logs its decisions, and fails safely. In other words, the differentiator is increasingly systems engineering, not chat quality.

A coding agent that receives a ticket, opens the repository, runs tests, traces the affected service, checks deployment constraints, proposes a minimal patch, and waits at a protected approval gate is useful because it has context and a harness. The same model asked, “Can you fix this bug?” in a generic chat window is mostly a burden-transfer device. It transfers the work of reconstructing context back onto the engineer.

This is also why personalized software matters more than generic assistants. A useful agent needs durable knowledge of how I work: which services I own, what changes require review, how much risk I tolerate, which customers matter, what “done” means for this team, and what it is never allowed to do. That knowledge should be explicit, inspectable, and portable—not hidden in a vendor’s opaque memory feature. Personalization is not a model remembering my favorite coffee. It is software adapting to my real constraints.

The strongest objection: autonomous systems will make mistakes at scale

The strongest counterargument is not that people enjoy chat. It is that continuous agents create a dangerous new failure mode. A chatbot can give bad advice, but a system with permissions can send money, merge insecure code, leak data, delete records, or quietly optimize the wrong metric thousands of times before anyone notices. Giving probabilistic models persistent access and autonomy is an invitation to automate catastrophe.

That argument is correct as far as it goes. We should reject the fantasy that a better prompt or a higher benchmark score turns a language model into trustworthy infrastructure. The answer, however, is not to keep AI trapped in a chat window. We do not ban deployment pipelines because code can be wrong; we build tests, permissions, staging environments, rollbacks, audit logs, rate limits, and ownership. Agents need the equivalent, designed as a first-class product concern rather than bolted on after an impressive demo.

A good agentic system should have narrow scopes, explicit budgets, reversible actions by default, dry-run modes, policy checks outside the model, immutable logs, anomaly detection, and escalation paths. It should distinguish between preparing an action and executing it. It should make it easy to inspect why it believes an action is appropriate, including the source data and tool calls that produced the recommendation. And it should lose privileges when its behavior cannot be evaluated.

This will make agents feel less magical. Good. Software that moves from suggestion to action ought to become more constrained, not more mystical. The product teams that treat “autonomy” as a permission architecture problem will build something durable. The teams that treat it as a branding adjective will ship a chatbot with a credit card.

What should change

We should stop measuring AI products primarily by how pleasant they are to converse with. Engineers should ask harder questions: What does this system observe without being prompted? What durable context does it maintain? Which actions can it take? Which constraints are enforced outside the model? How does it explain, reverse, and audit its work?

Build fewer blank prompt boxes. Build agents around concrete workflows, owned data, narrow authority, and visible decision queues. Treat chat as the escape hatch for ambiguity and exploration, not as the operating system for intelligence. The post-chat interface will not look like a more charming assistant waiting for instructions. It will look like software that has finally learned to do its share of the work.