Transcript
In this episode
Agentic coding has outgrown the text box. Maggie Appleton, staff research engineer at GitHub Next, argues that walls of CLI output and AGENTS.md files serve coding agents far better than the humans steering them. She walks through Chopin, the GitHub Next prototype where background agents turn a team's planning chat into a structured plan, and makes the case for agents that prompt you instead of waiting to be prompted.
What we cover:
- Why text-heavy agentic coding tools favor agents over humans
- Boundary objects: what AGENTS.md, skill files and MCP servers get right and wrong
- Multiplayer planning with coding agents in GitHub Next's Chopin
- Human-to-agent handoffs, formal verification and spec-driven development
- Why software quality is rising, not falling, with coding agents
- Which roles still matter: PMs, designers and engineers
Build your software factory, one workflow at a time, with Tessl: https://tessl.co/j3d
Should coding agents be prompting you more? Tell us in the comments how your team plans agentic coding work today.
Most agentic coding tools today share a quiet assumption: that the right interface between a human and a coding agent is text. Plans live in markdown, context lives in AGENTS.md files, and progress arrives as long scrolls of CLI output. That works well for the agent. Whether it works for the human is a different question, and it is one GitHub Next has been testing prototype by prototype.
Maggie Appleton, a staff research engineer at GitHub Next, came to the lab from illustration, art direction and front-end development, and now works on Chopin, a prototype for planning software collaboratively with teammates and agents. On The AI Native Dev, she joined Simon Maple to explore where the human-agent handoff points sit, and why current interfaces may be optimized for the wrong participant.
Boundary objects and why text favors coding agents
Appleton borrows a concept from a 1989 sociology paper by Susan Leigh Star, which studied how academics, funders, biologists and trappers came together to found Berkeley's Museum of Vertebrate Zoology. These groups had different training and priorities, yet collaborated through shared specimens, labels and field maps.
Boundary objects are shared artifacts that let groups with different expertise and priorities collaborate without needing a perfect shared understanding. Each group reads the object in its own way, but the object still coordinates the work. In agentic coding, AGENTS.md files, skill files and MCP servers play this role between humans and agents.
The catch, in Appleton's view, is that today's boundary objects serve one side far better than the other. "We are much faster visual, spatial, social reasoners," she observed. Agents can happily process reams of text and nested skills, while humans are left reading huge outputs in the CLI. Planning a complex architecture is far more effective at a whiteboard, pointing and drawing in real time, than typing into a document. Her conclusion is that widening the keyhole between humans and agents is mostly the job of tool builders, who need to create environments where humans can think well and then hand off artifacts optimized for agents.
Planning with coding agents as active collaborators
To make sense of where agents fit in planning, it can be helpful to plot tools across two dimensions: who the interface is built for (the agent or the human) and how many people are in the room (single player or multiplayer). Most current tooling sits in the agent-optimized, single-player corner: one developer, one terminal, one plan mode asking dozens of multiple choice questions.
Appleton pointed out that each of those questions can hide a real research problem. Choosing between npm libraries deserves a comparative report, and a design question deserves visual options, not a radio button. Her answer is agents that work ahead of the human. "Don't wait for me to prompt you," she argued, describing agents that notice where a plan is heading, run the web research in advance, and have decisions ready with bespoke interfaces by the time the team gets there. She suggested agents prompting us more could relieve the cognitive load of juggling several sessions at once.
In Chopin, the multiplayer side looks like a chat and a document. Background agents classify each message as a question, proposal, opinion or constraint, and turn free-form human conversation into a structured plan ready for an implementation agent. Crucially, the agents stay in the background. Appleton has not yet found a way for them to interrupt a human conversation without feeling invasive, so their work is designed to be cheap and disposable.
The multiplayer framing also addresses a team problem. When every developer accelerates alone on their own branch, the result is merge conflicts and features nobody agreed to. "Nine women can't make a baby in one month," Appleton noted. Ambitious work still needs alignment up front, especially when an orchestrator run is expensive and a designer or infrastructure engineer could reject the result afterwards.
Handoffs, verification and spec-driven development
Handoffs are where things tend to break. Even a thorough plan meets edge cases during implementation, so Appleton asks agents to log every decision they make and deliver a visual report at the end. A new collaborator on Chopin is exploring formal verification: turning a plan into a formal spec that covers every case, so an implementation can be checked against it computationally.
She remains more skeptical of natural language specs, but sees the direction as inevitable. "How much is anyone really going to read the code again?" she asked, as long as tests verify the behavior. In practice, this suggests review moves up a level, to plans going in and high-level reports coming out, with layers of checker agents verifying that the report matches what actually happened. In this framing, spec-driven development is less about a document format and more about where human attention gets spent.
Quality, roles and what coding agents still cannot see
Appleton pushes back on the idea that agentic coding is degrading software quality. Beyond obvious slop, she sees bug reports going down at large companies, and agents being assigned to find, file and fix bugs on a loop. Execs demanding raw speed are, she believes, in a transition period before they redirect tokens toward quality.
She is equally firm that roles should not collapse. Engineers own architecture and scalability, PMs own user research and strategy, and designers still advocate for the user. When building becomes cheap, deciding what to build becomes the harder problem, and that decision depends on social context agents lack. "You need a human on the ground with social connections," she explained, to spot an unsolved problem for a particular group of people.
For anyone starting out, her advice is direct: find generous token budgets, build as many small prototypes as possible, and make every idea more ambitious than feels comfortable. The attempting is where the learning happens.
The full conversation goes further into Chopin, junior developers learning from open agent sessions, and why coding agents still struggle with visual design. It is worth a listen for anyone rethinking how their team plans with agents, and we would love to hear how your own planning workflow is changing.
CHAPTERS
