"Anatomy of an AI input: the humble textbox that became a product's front door"

When ChatGPT launched in November 2022, its input field was almost primitive: a textbox and a send button. Three years later, the input area of an AI product is arguably its most important surface. Julien Thibeaut — who builds under the name "ibelick" — has spent months assembling these components for prompt-kit, his open-source library of AI interface blocks, and he recently wrote a field guide called "Anatomy of AI Input" that walks through the whole thing layer by layer. It's a useful read not just for people building AI apps, but for anyone who wants to understand why today's chat interfaces feel the way they do.

Thibeaut's central principle is stated up front and simple: keep the input usable in almost every state. That sounds obvious, but it cuts against how most software has historically handled waiting. The traditional pattern — disable the button, show a spinner, lock the field until the operation finishes — assumes the operation is short and the user's only job is to wait. AI responses are neither short nor passive; they stream for many seconds, and the user often wants to type a follow-up, correct a mistake, or simply stop the response midway. So the input must never be read-only while the model is streaming, and sending must always be interruptible.

That first principle explains the single most recognizable detail in the modern AI input: the send button that morphs into a stop button the moment you press it. It's a tiny change with an outsized effect on feel. The product stops being a fire-and-forget form and becomes a conversation you can steer at any moment, including the ability to interrupt yourself. "Don't disable the controls," Thibeaut writes, "even if you don't allow sending multiple messages."

The field itself follows a now-familiar choreography. It starts as a single-line textbox and grows to multiple lines, but only up to a defined maximum height, and it grows without pushing the rest of the layout around or making the scroll position jump. Shift+Enter inserts a newline while Enter sends — a convention inherited from chat apps, and quietly configurable. These are details that read as trivial in a spec and feel like quality in practice: a stable typing surface, no auto-capitalization on mobile, no cursor suddenly jumping to the end of the field.

Below the field sits what Thibeaut calls the context bar: the model selector, mode toggles (code, search, tools), and memory and context settings. His advice here is restraint. The context bar should stay more discreet than the field itself, expose only what users need often, and hide everything else behind a menu. It should be fully keyboard-accessible, and on mobile, when space runs out, labels and icons can collapse to icons alone. The recurring theme is that every control competes for a fixed budget of attention, and the input field itself always wins.

When the context bar gets crowded, the answer is tool triggers — slash commands or dropdowns that surface actions without permanently occupying space. Thibeaut notes the choice between a slash command and a dropdown should be driven by how many tools you expose and how often people reach for them. Either way, triggers should be keyboard-first, appear instantly, and avoid the layout jumps that make an interface feel like it's shifting under your fingers.

The attachment zone is where an AI input most visibly becomes more than a chat box. Files, images, video, and audio all flow through it, and it's the fragile part: uploads can succeed, fail, or hang, and files carry constraints on size, type, and count. Thibeaut's prescriptions are practical — show a clear drag-and-drop highlight, render previews above the field or in the chat, surface errors next to the input rather than in a toast notification, and lean on optimistic updates so a dropped file appears instantly and syncs in the background.

The assist layer is the subtlest of the group, and arguably the easiest to get wrong. It can be ghost text inside the field, inline suggestions that appear as you type (the way Cursor suggests file paths), or preset prompts above or below the input. The goal is to guide without taking over — fast, non-intrusive, dismissible, and reachable from the keyboard. "Suggest when it makes sense," Thibeaut writes, "but don't over-suggest." It's a reminder that the line between helpful and annoying in AI interfaces is thin, and it usually comes down to whether the system respects the user's momentum.

The state layer is where the "usable in every state" rule gets its real test. An AI input passes through idle, loading, streaming, error, and success states, and the guidance stays consistent: don't lock the input during loading or streaming, and keep the field neutral during errors. Errors, Thibeaut argues, belong to the generation, not the typing — so a retry button lives in the chat container, never inside the input. This is a genuinely useful separation of concerns: the input is the one part of the product the user fully controls, and keeping it clean preserves a sense of agency even when the model fails.

The edge-case list rounds things out and reads like a manifesto for predictability. Typing must stay instant. The field must stay usable when the model or network is slow. Focus should never be stolen when a response starts or ends. Mobile keyboards must not cover the field. Clear the input immediately after sending, switch to the stop button without delay, and prefer optimistic updates over animation. The through-line is keyboard-first, never-jumping, always-available.

Stepping back, there's a larger story here. The AI input has become the front door of an entire product category in much the way the search box once was for the web, and it's quietly standardizing into a shared grammar. Details like the send-to-stop morph, Shift+Enter for newlines, and inline suggestions are converging across products built by entirely different companies — a telltale sign of a maturing platform. The pattern is the same one the mobile era produced with pull-to-refresh and the hamburger menu: a few conventions prove themselves, everyone adopts them, and users carry their expectations from one app to the next.

Another way to read Thibeaut's guide is as a statement about latency. The reason "keep the input usable while waiting" matters is that AI has made latency a first-class part of the interface. In older software, waiting was an exception to hide; in AI products, waiting is the normal condition, and the input has to be designed around it. The optimistic updates, the interruptible sends, the never-disabled controls — these are all techniques borrowed from collaborative and productivity apps, repurposed to make perceived latency feel like part of the experience rather than a failure of it.

There's also a quiet argument about accessibility hiding inside the details. The insistence on keyboard-first interactions and a minimum 16px font size (to prevent Safari's auto-zoom on mobile) isn't just polish; it's the difference between an input that a wide range of people can use and one that quietly excludes them. When a single component has to serve everyone from a power user juggling a dozen slash commands to someone on a small phone screen, the constraints of accessibility and the constraints of good design turn out to be the same list.

None of this is glamorous, which is exactly the point. A good AI input looks simple and hides a great deal of detail — and, as Thibeaut puts it, every layer matters. For anyone building or even just heavy-using these tools, understanding those layers turns the box you type into from a black box into a small piece of deliberate engineering. The guide itself is at ibelick.com, the source is in the prompt-kit repo, and the finished component is browsable on 21st.dev if you'd rather inspect the parts than read about them.