Interaction Models Are the Next AI Developer Tool Interface

Thinking Machines' post on interaction models is one of the more useful AI interface pieces to land this week because it names a problem every developer-tool team is running into: chat is not the final shape.

Turn-based chat is great for asking a question. It is awkward for shared work.

Coding agents already proved that. A serious agent session is not one prompt and one answer. It is a loop of reading files, asking clarifying questions, editing code, running tests, showing diffs, getting corrected, opening browser checks, and leaving a receipt. That is why terminal agents are becoming runtime surfaces, why Codex loops matter, and why long-running agent harnesses keep showing up.

The next interface layer is not "better chat." It is better coordination.

What Interaction Models Mean

Thinking Machines describes interaction models as systems that handle multimodal, real-time collaboration across audio, video, and text. The important idea is not merely multimodality. The important idea is that the model participates in an ongoing interaction instead of waiting for a fully packaged prompt.

For developer tools, that maps cleanly to the work we already do:

• watch a test fail;
• inspect a diff;
• hear a spoken constraint;
• see a screenshot;
• follow a cursor;
• notice a console error;
• ask whether to continue;
• remember which file is the current focus;
• hand control back to the human at the right moment.

That is a different product shape from a chat box glued beside an editor.

Why Chat Feels Wrong for Coding Agents

Chat forces developers to serialize messy work into text.

You have to explain:

• which file matters;
• what changed;
• which visual bug you mean;
• which test output is relevant;
• which instruction still applies;
• which previous decision should be ignored.

A good coding agent can infer some of that from the repo, but the interface still makes the human do too much packaging.

This is why tools keep adding richer surfaces: IDE diffs, terminal execution, browser screenshots, task plans, subagents, worktrees, PR comments, and persisted instructions. They are not decorations. They are attempts to escape the limitations of pure chat.

The Developer Tool Version

In developer tools, an interaction model should treat the repo, terminal, browser, issue tracker, and human as parts of one workspace.

Imagine a coding agent interface where:

• the agent can see the current failing test and the diff beside it;
• your spoken correction is attached to the exact UI state;
• the browser screenshot becomes part of the task context;
• the agent knows whether it is in exploration, implementation, review, or deploy verification mode;
• every action lands in a receipt that another agent can resume.

That is not science fiction. Pieces of it already exist across Claude Code, Codex, Cursor, Zed, GitHub Copilot, and browser automation workflows. The problem is that the pieces are still fragmented.

Opposing View: Chat Is Enough

There is a fair counterargument: chat is simple, universal, and composable. A text box can drive anything. Developers already understand it. APIs are easier. Logs are easier. Automation is easier.

I agree with the first half. Chat should not disappear.

But chat should become one control among many, not the whole interface. The same way command lines did not disappear when IDEs improved, text prompts will remain useful. They just should not be responsible for carrying every bit of state.

The best developer tools will support text, but they will not force every interaction through text.

The Missing Primitive Is Shared State

The real prize is shared state.

Developer work has a lot of state:

• files;
• diffs;
• test results;
• logs;
• browser screenshots;
• issue comments;
• design constraints;
• deploy status;
• previous agent attempts;
• budget and time limits.

Chat transcripts are a poor database for that. They are verbose, ambiguous, and hard to resume. A better interaction model should store task state explicitly.

That is why agent context reduction matters. The goal is not to stuff more transcript into a context window. The goal is to keep the right state in the right structure.

What To Build Now

If you are building AI developer tools, do not wait for a perfect multimodal model to improve the interface. Start with the interaction contract.

Add these primitives:

• Mode: exploration, implementation, review, verification, deploy.
• Current artifact: file, PR, route, screenshot, test, issue.
• Authority level: read-only, edit, command execution, merge, deploy.
• Evidence: tests run, screenshots captured, source links checked.
• Resume state: what another agent needs to continue without replaying the whole chat.
• Escalation rule: when the agent must stop and ask.

Those primitives make any model better because they reduce ambiguity.

Why This Matters for Content and SEO Too

The same idea applies outside code. A content automation should not only say "write a post." It should know:

• the trend source;
• the existing posts to avoid duplicating;
• the internal links to include;
• the image style;
• the checks to run;
• the deployment verification step;
• the next self-improvement note.

That is exactly the loop behind skills as agent operating systems. A skill is a tiny interaction model: state, constraints, tools, and expected output.

The Takeaway

Interaction models are a useful frame because they push AI tools beyond prompt-response thinking.

For developer tools, the future interface is a shared workspace where the model can coordinate across code, tests, browser state, voice, screenshots, issues, and deployment receipts.

Chat will still be there. It just will not be the whole product.

The best agent tools will feel less like asking a chatbot to code and more like working inside a system that understands the work in progress.

FAQ

What is an interaction model in AI?

An interaction model is a system design for how a model collaborates with users across time, modalities, and shared state. Instead of treating every request as a standalone chat turn, it handles ongoing work.

Why does this matter for AI coding tools?

Coding work involves files, diffs, tests, terminals, screenshots, issue trackers, and deployment checks. A chat-only interface makes developers compress all of that state into text, which is inefficient and error-prone.

Does this mean chat interfaces are going away?

No. Text prompts remain useful. The shift is that chat becomes one input inside a richer workspace, not the entire interface.

Sources: Thinking Machines: Interaction Models, Hacker News discussion, Anthropic Claude Code overview, OpenAI Codex documentation, W3C Multimodal Interaction Architecture.