The Familiar Interface: Why Agentic Coding Looks Like a Chat App

Every technology transition wraps the new in the old. AI-assisted development is no different — and that's both why it works and why it won't stay this way.

2026-03-29

For the past week, I have been managing software projects through Discord channels where the "teammates" are AI coding agents.

Each project has a channel. Threads become workstreams. A PM agent analyzes requirements, hands off to an Engineer agent, and the Engineer works in an isolated Git branch before reporting back. From the outside, it looks like a small software team using Slack. The strange part is that most of the team is not human.

I do not think this is the final interface for agentic development. But I do think it explains why the current generation of tools works: every new technology first borrows the interface of the old one. I have been living inside one version of that transition.

The Old Shape of New Technology

When Karl Benz built the first automobile, it looked like a carriage without a horse. This wasn't a failure of imagination — it was a strategy for adoption. People knew carriages. They knew how to sit in them, how to steer them, where to put their luggage. The word "dashboard" literally survives from this era: it was the board at the front of a horse-drawn carriage that blocked mud kicked up by hooves. We still call it a dashboard.

When Xerox PARC and later Apple designed interfaces for personal computers, they chose office furniture: files, folders, a desktop, a trash can. The underlying technology — hierarchical filesystems, memory management, process scheduling — bore no resemblance to a desk. But you didn't need to understand any of that. You already knew how a desk worked. You already knew what putting something in the trash meant.

When Apple launched the iPhone, the apps used leather textures for calendars, green felt for game tables, page-turn animations for e-books. These weren't decorative choices — they were translation layers. They told users: you already know how this works. A few years later, once people had internalized touchscreens, iOS 7 stripped it all away. Flat design replaced skeuomorphism. The training wheels came off.

In every case, the familiar interface was a bridge — not a destination. It got people across the gap. Then the new medium found its own language.

Agentic Development Is in This Transitional Moment Now

AI coding agents are a genuinely new capability. Systems that can read codebases, write implementations, run tests, and modify files — not as autocomplete, but as task-executing systems that can carry out multi-step work under human direction. This is a fundamentally different relationship between a developer and their tools.

But look at the interfaces we're building for them. Chat apps. Discord channels that look like team conversations. GitHub issues that look like meeting notes. Dashboards that look like server monitoring. Planning tools that look like project management. We've taken a new technology — agent sessions that can coordinate around code — and wrapped it in the interface of a software team using Slack.

This isn't laziness. This is the pattern. And it's working.

What the Familiar Interface Looks Like in Practice

I've been running this workflow for the past week across five or six concurrent projects, using an open-source tool I built called mpg (multi-project-gateway) — a Discord/Slack gateway for routing messages to per-project Claude Code CLI sessions. Here's what it looks like when you map familiar metaphors to new capabilities — and what it actually gains you.

Discord channels as team workspace

Each project gets a Discord channel. Each channel can have multiple agent personas — a PM, an Engineer, a QA — each configured for a different phase of the workflow, working in threads. These are not independent employees, of course. They are role-configured agent sessions with different prompts, permissions, and workflows. But the interface borrows from the way software teams already coordinate work. When an agent is active, Discord shows the familiar "bot is typing..." indicator. When the PM finishes analyzing a requirement, it hands off to the Engineer using an explicit syntax. The Engineer works in an isolated git branch and reports back.

The metaphor is obvious: this is a Slack workspace where your teammates happen to be AI agents. Channels are projects. Threads are workstreams. The typing indicator means someone is working on it. You already know how to use this.

The practical gain is not just convenience. It is ambient control. I used to SSH into a Linux server, reconnect to tmux sessions, and navigate terminal panes to check on work. Now I open Discord — from my phone, my laptop, wherever — and I can monitor, interrupt, redirect, or resume any project from anywhere. The interface I already check twenty times a day became the interface for my entire development workflow.

There's even a constraint that turned into a feature. I don't have a Discord Nitro subscription, so I'm limited in how many characters I can enter in a single message. When I need to provide large context to an agent — error logs, analysis from another session, a long specification — I can't paste it into chat. So I put it in a GitHub issue and reference it. Which, it turns out, is a better practice anyway.

GitHub issues as decision records

That accidental practice — putting context into GitHub issues instead of chat — became central to the workflow. Error logs, design decisions, analysis done by one agent that another agent needs to reference, constraints discovered during implementation — all of it goes into issues.

The metaphor: meeting notes and ticket tracking. Every engineering team writes things down in Jira, Linear, or GitHub Issues. You already know how to create an issue, link it to a branch, and reference it in a conversation. None of this is new.

The gain is reduced cognitive load. The decision history lives outside my head. When I pick up a thread the next day, the context is in the issue — not buried in a chat log I have to scroll through. When an agent needs background on why we chose approach A over approach B, I can point it at an issue instead of re-explaining. The friction of Discord's character limit pushed me toward a documentation habit that I should have had all along.

Workflow discipline as the real interface

The third piece is less obvious. I use a set of Claude Code skills called Superpowers that impose structured workflows on agent sessions. A brainstorming skill forces the agent to explore requirements and constraints before writing code. A writing-plans skill produces a structured implementation plan with discrete tasks. A subagent-driven development skill dispatches those tasks to parallel workers and tracks progress.

The metaphor: a project manager who won't let you skip straight to coding. Anyone who has worked on a team with a good PM knows this pattern — you propose a feature, and before you touch a keyboard, someone makes you write a spec, break it into tasks, and identify dependencies. It feels like overhead until the third time it saves you from building the wrong thing.

The gain is parallel workstreams. Because the planning step produces a structured task list with clear boundaries, multiple agents across different projects can make progress simultaneously. I don't coordinate each step manually. The plan does the coordinating. This morning I had three projects advancing in parallel — two implementing features from plans written yesterday, one running a debugging workflow — and my involvement was checking in on threads and occasionally answering a question. That's not how I expected to spend my time as a developer, but it's effective.

In agentic coding, the interface is not only the chat window. The interface is the workflow: what the agent must clarify, what it must write down, when it is allowed to code, how it hands off work, and how progress is checked. The familiar interface here isn't a screen or an app — it's the management practice itself.

Chat Is for Humans. Agents Need Something Else.

The important distinction is that agents do not fundamentally need conversation. Humans do. Agents need goals, constraints, state, permissions, dependencies, and feedback signals. Chat is useful because it lets humans express those things in a familiar way. But once the workflow becomes more structured, the conversational wrapper starts to leak.

I can already feel the constraints.

Discord's 2000-character message limit is a real ceiling. Complex agent outputs — detailed analysis, multi-file diffs, structured plans — have to be truncated, split across messages, or pushed to external documents. The workaround (GitHub issues) is fine, but it's a workaround. A native interface wouldn't have this bottleneck.

Threading models designed for human conversation don't perfectly fit agent workflows. When an agent hands off work to another agent, the handoff creates a new thread. But the relationship between threads — this one depends on that one, these three can run in parallel — isn't visible in Discord's UI. I track it in my head or in a dashboard I built separately. A native interface would make these relationships first-class.

The feedback loop is slower than it needs to be. I check Discord, read a message, type a response, wait. This is the cadence of human conversation, but agents don't need conversational cadence. They need instructions and signals. A native interface might look more like a control panel than a chat window — or like something we haven't imagined yet.

None of this makes the current setup bad. It makes it transitional. The familiar interface is doing exactly what familiar interfaces do: it's getting me across the gap. I'm productive, I'm learning what matters, and I'm discovering the constraints that will shape whatever comes next.

What I Know So Far

I'm not claiming this is the optimal workflow for AI-assisted development. I'm claiming it's effective right now, and it's effective partly because it doesn't require learning a new paradigm. I already knew how to use Discord. I already knew how to write GitHub issues. I already knew what good project management looks like. The new capability — agent sessions that can coordinate around code — slotted into interfaces I already understood.

When the native interface for agentic development arrives, I suspect it won't look like a chat app at all. It might not look like anything we currently have a name for. But today, the chat app is getting the job done — and the constraints I'm hitting are exactly the kind of data points that will inform whatever comes next.

The horseless carriage eventually became the car. The desktop metaphor is still with us, but the filesystem it represents is increasingly invisible. Skeuomorphic iOS gave way to flat design in three years. The timeline varies, but the pattern doesn't.

For now, the practical question is not whether chat is the final interface. It is what the current interface teaches us about the one that comes next.

We're in the carriage phase. And the carriage is working.

For technical details on the tool itself, see From tmux to Discord and From Message Router to Agent Team. The source code is at github.com/yama-kei/multi-project-gateway.