Writing production-quality code isn’t perfectly solved by today’s agents, but we’re getting pretty damn close. With a frontier model to hand, rigorous upfront planning, and plenty of tests and verification checks, swathes of senior developers have laid down their text editors and stopped meticulously reading code diffs.
We no longer need to care about syntax and variable names, or how to construct a for loop. The agents are more than capable of making these kinds of simple decisions at warp speed. This means we’re spending way less time on implementation.
The important work is now everything that happens before and after code gets written: planning and review. These are not solved problems.
Planning is the more critical piece because everything else is downstream of it. It’s what will make or break your feature. And it’s also where having a seasoned developer driving the plan makes a big difference. Handing a coding agent a poorly specified, rough idea of a feature with no clear validation requirements is how you end up with vibe-coded slop.
All of today’s AI agents have a well-established “plan mode.” It was one of the early, immensely popular breakout features of Claude Code back in ye olde June 2025. Claude was not the first to do this; improving agent results by getting them to think and plan before acting was first proposed by the 2022 ReAct paper and implemented by lesser known agent harnesses like Cline.
Combining plan mode with skills like Matt Pocock’s infamous grill-me, which exhaustively quizzes you on what you want to make, helps you develop a thorough understanding of the task at hand and explore possible directions first, before jumping into building anything. You and the agent discuss the problem space and come to clear, opinionated solutions together.
The plan then becomes a clear touchpoint in the development process; both an artifact that you can hand off to a coding agent to implement, and record of the original intention to compare against during the review phase.
This planning part isn’t drastically different to how we used to plan in the pre-agentic era. Developers, product managers, designers, and other stakeholders spent plenty of time and effort writing up design specs, PRDs, RFCs, and other acronym-laden documents in order to guide and drive the work of engineering teams. The difference now is that humans are not involved in the implementation process. We can’t adjust and redirect decisions once the work begins, making planning well up front much more critical.
The Problem with our Planning Tools
Our current planning tools have plenty of limitations, but four major ones stick out to us: interactivity, team collaboration, decision ownership, and visual explanations.
1. Lack of Interactivity
If you’re using a CLI tool in the terminal, the plan is, at best, a wall of uneditable, static text. Even when it displays inline Markdown syntax, it still renders as a flat, unstyled, hard-to-read document.
If you’re part of the more enlightened crowd who have upgraded to a desktop app GUI, you get a much richer view of plans and documents with nice markdown formatting. But you still can’t directly edit the plan. Some interfaces make it hard to read the plan in full, partially hiding it in a preview. And most offer a binary option: would you like to accept or reject this plan?
This does not offer us a way to engage with the details of the plan and understand what we’re agreeing it. Making small changes and progressively iterating on a large, long, 3000 word plan is difficult. In most of our current tools it is hard or impossible to point at a section and say “Can you expand on this point?” or “Please delete this suggestion” or “I don’t agree with this approach, why are you recommending it?”
You have to instead hold many, complex threads and separate ideas in your head as you read the plan and then dump all of your feedback into one chat box. Then hope the agent remembers to address all of your points.
Answering 37 different questions during the grilling session does not guarantee all of your decisions will be reflected in the final plan. This is a very primitive interface compared to what is possible.
It makes the final plan feel detached from the process of creating it. “Writing” a plan with an agent does not feel like an interactive experience. The plan appears fully formed, rather than being co-written. What would it take for a human to feel they have fully understood, digested, and been part of every key decision in that plan?
We could, for example, have separate conversation threads for each question or uncertain detail in the plan. Some threads might ask for more research. Others could give you a space to debate with coworkers. Another may allows you to prototype multiple design directions. Plans should be branching entry points into many debates and explorations, not dead ends.
2. Lack of Team Collaboration
The second giant, glaring problem is that all the tools on the market are designed as single-player experiences. You are planning all alone in your tiny terminal or desktop app, away from the people who you need to build with.
Building software is not a single-player game. Software development, at its core, is a collaborative problem-solving activity. We all work on teams because we need people with different skill sets to make software good: company leaders, product managers, designers, engineers, and researchers. Having a wide array of skillsets and perspectives to hand helps you find the right shaped solution, not just whatever you personally think is correct. No single developer has all the context and knowledge about a given problem or product.
We believe it should be easy and frictionless to write plans in a way that includes your whole team, in real time (or async, if that’s your preference), and gives you native access to helpful agents.
3. Lack of Decision Ownership
Finally, there is the issue of who owns each decision stated in a plan and how they arrived at it. Did the agent make this decision in a plan or did a human? Did any humans discuss this plan before shipping it to an agent? Did anyone from the design team review this? Why did we pick approach A over approach B?
There is currently no way to see how a final plan came to be. There is no audit trail or log of who decided what. We lose so much of the critical, up-front thinking that goes into planning a feature to fleeting chat logs within private sessions. We make it impossible to trace back conversations that led to key decisions. Or to reveal that no such conversation was had, and an agent silently decided something without a human realising it.
For serious software, we need serious audit trails and attribution. Not to lay blame, but to help everyone else on our team contextualise decisions, so they know when to question them and when to accept someone else already did the legwork of thinking it through.
4. Lack of Visual Explanations
All our plans are currently text-heavy artefacts. In fact, everything agents make is text-heavy. They love text. And they are happy to spit out thousands of words per second at us, far faster than we could ever hope to read and understand it.
Humans are slow readers. The average pace is 238 words per minute for reading silently in our heads. Frontier models can produce ~50–150 tokens per second, or an average of 4,500 tokens (~words) per minute. Which makes the ratio of human reading pace to agent writing pace 1:15. And it does not help that current frontier models are notoriously verbose and speak in convoluted cliches rather than concisely getting to the point.
This imbalance is one reason to move beyond pure text, but a much better one is that text is not always the ideal medium for comprehension. Especially for understanding complex concepts, intertwined relationships, events over time, and architectural systems. Much like the kind you find in programming.
Humans have a far easier time understanding diagrams and visual explanations thanks to our massive visual cortex and spatial reasoning systems, which pre-date writing by over 500 million years and spoken language by 200 million years. We can process lots of information in an image in parallel, seeing patterns, relationships, and objects all at once. While comprehending text is a sequential process, and therefore slower.
Programming has a rich history of using diagrams, maps, and visuals to help teams think, plan, and communicate about complex systems. Visuals like data flow diagrams, state machines, UML, and architecture maps help developers comprehend information far more effectively than writing the equivalent in text. We think there is a high, largely unexplored ceiling in using agents to create bespoke, interactive visuals within every plan to escape text overwhelm.
Introducing Chopin
Chopin is an exploration into how we can make collaborative planning with agents much better. By “collaborative” we mean collaborating with other real, flesh-and-blood humans, not with fleets of agents (though it will also involve agent fleets).
It is a real-time, multiplayer planning environment. You can write plans with your coworkers and agents in a beautiful, MDX-based editor. These plans are organised around GitHub repos and shared with anyone who has repo access.
You also have a little chat room with everyone to discuss ideas outside of the plan. The agent is in this chat too. You can ask them to make edits, integrate comments, do research, and much more.
Here is a tour of us writing a collaborative plan together, in sync, in Chopin:
We can add comment threads anywhere in the document and have the agent update the plan to resolve them:
While rough at the moment, we’ve also built in a research block type where you can ask the agent to go research a specific question or topic and get a report placed inline in your plan:
Here are all the headline features we’ve built into Chopin so far:
- A WYSIWYG editor with rich, visual components like tabs, charts, diagrams, math formulas, and more.
- Real-time, multiplayer collaboration, including user presence and real-time updates.
- Natural AI agent presence: agents editing the plan should behave like other users editing the plan.
- A commenting system that you can use to create threads and steer agents.
- A persistent log of decisions you’ve made. The results of comment threads and answers to the questions agent has made are linked to parts of the plan. These are always kept up to date even when the plan changes.
- An MCP server which lets you use any agent with Chopin. You can have an initial chat your agent, pass the plan off to Chopin and work with your teammates in it, then move back into your agent of choice for implementation.
- A delightful user experience 😊 (in progress)
Right now, Chopin is a very small, early research prototype. It is not particularly impressive, but we believe it is an entry point into a rich and relatively untapped research space.
Chopin is the spiritual child of Ace, a much more ambitious, but complex and hard-to-ship product focused on real-time, multiplayer agentic engineering. Ace is currently paused until further notice. But in its wake, we are taking its most promising ideas and exploring them in a simpler environment: the multiplayer planner.
And more importantly, we’re doing it in the open. We’re open sourcing Chopin today.
What to Expect from Chopin
Chopin is neither a product nor a finished prototype. We don’t recommend you attempt to use it today. But within a month or so, we will have ironed out enough creases to seriously entertain some alpha users.
Open sourcing it now is our way of committing to building in public and sharing what we learn from our investigations. Both for the benefit of GitHub and anyone else interested in this problem. There is a team inside GitHub working on bringing real-time collaborative planning documents to github.com, and we hope our project will influence and contribute to that effort.
If you’re interested in this space, please check out the repo. Let us know what you think and maybe open an issue. Our agents are always happy to vet new ideas and squash bugs on our behalf.