The open-source coding-agent ecosystem is growing rapidly. But copying the interface of an established product isn't the same as understanding why it works. And the best reason to build your own agent may have nothing to do with its interface.
I've been looking at quite a few coding agents lately.
Partly because I'm interested in the technology.
Partly because I like discovering interesting engineering decisions in open-source projects.
And partly because it's fascinating to see how different developers approach essentially the same problem.
Give an AI model access to files, tools and a development environment.
Allow it to inspect code, make changes, execute commands and verify its work.
Then build an interface that makes the whole thing useful without accidentally allowing it to destroy your project.
A relatively straightforward concept.
At least until you try implementing it.
What's particularly entertaining is how many projects seem determined to reproduce the experience of established products such as Codex, Claude Code or Claude's desktop applications.
The familiar chat.
The familiar sidebar.
The familiar session history.
The familiar tool-call display.
The familiar approval prompts.
Sometimes even the same interaction patterns, including the ones that weren't particularly good in the original.
And that raises a question I've been thinking about.
If you're building your own coding agent, why would you want it to be a worse version of something that already exists?
Copying the interface is easier than understanding the decisions
There's nothing inherently wrong with borrowing good ideas.
Software development has always worked that way.
Nobody needs to reinvent a text editor's basic interaction model every time they create a new development tool.
Familiar conventions help users understand new products.
But there's a difference between adopting a useful convention and copying a complete product without understanding the trade-offs behind its design.
Large AI products have histories.
Some interface decisions exist because of technical constraints.
Others because of business considerations.
Some are compromises between incompatible requirements.
Some were sensible when introduced and have become less convincing as the technology evolved.
And occasionally, a questionable design survives simply because changing it would disrupt millions of existing users.
If you reproduce all those decisions in a new project, you inherit the compromises without necessarily inheriting the reasons they were made.
Consider a few projects in the current agent ecosystem.
bb offers an agentic development environment with desktop, web, CLI and API surfaces.
DeepSeek Harness offers an open-source agent runtime built around an everything-is-a-plugin architecture.
Open Cowork aims to make agent-powered desktop work accessible through a graphical application, supporting multiple models, tools and integrations.
These projects aren't identical, and it would be unfair to dismiss all of them as superficial clones.
They have different architectural choices and intended audiences.
But they illustrate a larger question facing anyone building an AI agent.
Which parts of an established interface are genuinely necessary, and which are simply familiar?
It's a question worth answering before creating another sidebar.
Is a coding agent actually different from a chat?
Here's one design decision I find particularly debatable.
The separation between chat and coding-agent experiences.
In some products, the distinction is very visible.
There's a conversation interface.
And then there's an agent interface.
Different modes.
Different navigation.
Different expectations.
Sometimes different histories.
But conceptually, the boundary is becoming increasingly blurry.
What is an agent, after all?
In many practical implementations, it's a conversational system with access to tools, state and an execution loop.
It receives an objective.
Reasons about the next action.
Calls a tool.
Observes the result.
Continues until the task is complete, interrupted or escalated.
Remove the tools and execution capabilities, and you're back to something resembling ordinary chat.
Add those capabilities, and the conversation becomes operational.
So why should the interface necessarily treat them as separate worlds?
There are valid answers.
Coding tasks involve persistent workspaces, file changes, permissions and long-running processes.
A general conversation may not.
Separating the experiences can help communicate risk, clarify expectations and keep different workflows understandable.
But I don't think that automatically justifies duplicating the entire interaction model.
Perhaps the more useful question is whether the same conversation can gradually acquire different capabilities.
Read-only assistance.
Planning.
File editing.
Command execution.
Delegation.
Autonomous operation.
With permissions and interface elements that reflect what's currently happening.
One conversational foundation.
Different tools and levels of responsibility.
Not necessarily two separate products pretending to be unrelated.
Sessions are useful. But their limitations are becoming obvious.
Then there's the matter of sessions.
Every serious agent has them.
Start a task.
Create a conversation.
Accumulate context.
Eventually, the conversation gets too large.
So the system compresses it.
Summarises what happened.
Discards or archives older material.
And continues.
Context compaction is a remarkable engineering compromise.
It allows long tasks to continue without sending an ever-growing history to the model.
But it also introduces problems.
Details disappear.
Important decisions may be compressed into inaccurate summaries.
An agent can forget why a particular approach was rejected.
Or repeatedly investigate a question that was settled several hours earlier.
Compaction doesn't eliminate these issues.
It postpones or manages them.
However, sessions aren't merely an unfortunate consequence of limited context windows.
They're also useful units of work.
They provide boundaries.
Audit histories.
Permission scopes.
Recoverable execution state.
And ways to separate tasks that shouldn't interfere with one another.
Even with substantially larger context windows, many of those functions would remain valuable.
So I wouldn't argue that sessions should disappear entirely.
I'd argue that conversation history, task state and durable knowledge deserve to be treated as different things.
A task may span several conversations.
A project may retain knowledge beyond any individual task.
And an agent should be able to recover relevant decisions without pretending that every previous interaction belongs in the current prompt.
That's a much more interesting design challenge than inventing another way to summarise a long chat.
How many protocols does one agent actually need?
Here's another area where complexity can grow rather quickly.
Model providers.
Tool protocols.
Editor integrations.
Remote agents.
Messaging systems.
Automation environments.
A project announces support for another twelve protocols and seventeen backends.
Wonderful.
A truly impressive compatibility matrix.
But what does the user actually gain?
It's tempting to argue that everything should simply use an OpenAI-compatible API.
And there is a strong argument for standardisation at the model-provider layer.
If several model services expose sufficiently compatible interfaces, a developer can switch providers without rewriting the entire application.
That's useful.
But an OpenAI-compatible model API isn't the same thing as an agent-client protocol.
Take ACP, the Agent Client Protocol.
It standardises communication between coding agents and editing environments.
An IDE needs more than a request for text completion.
It needs to display tool activity.
Manage sessions.
Show file changes.
Handle permission requests.
And coordinate interactive agent workflows.
Then there's MCP, the Model Context Protocol, which addresses a different integration problem: connecting AI applications to external tools and sources of context.
These standards solve different problems.
They aren't perfect substitutes for one another.
And insisting that one API replace every layer may merely move complexity into undocumented extensions.
Still, the criticism of excessive compatibility work is worth taking seriously.
Every additional integration costs development time.
Testing.
Maintenance.
Documentation.
Error handling.
And support.
If you're maintaining a small open-source project, supporting every possible ecosystem can easily consume the resources that should have gone into your actual differentiating feature.
Interoperability is valuable when it expands what users can accomplish.
It's considerably less valuable when it becomes an engineering hobby of its own.
Coddy offers a more interesting example of differentiation
This brings us to a project worth examining.
Its developers have chosen an architectural direction that differs from the conventional desktop-agent approach.
The central idea is relatively straightforward.
One statically linked Go binary.
A common agent core.
Multiple ways to interact with it.
And an emphasis on deployment in minimal container environments and across collections of agent nodes.
Coddy can run as a terminal application.
It can provide a web interface.
It can communicate with editors through ACP.
It exposes an OpenAI-compatible HTTP interface.
It can connect to messaging systems and scheduled tasks.
And it includes facilities for coordinating multiple nodes through a swarm relay.
That doesn't automatically make it a better coding agent than the established commercial products.
Nor does a single binary magically solve the difficult problems of reliable tool execution, memory or verification.
But it does provide a coherent answer to the question:
Why build another agent?
Because the objective isn't simply to recreate Claude Code's interface.
It's to make an agent runtime that can be packaged, deployed, controlled and connected in a particular way.
That architectural premise gives the other design decisions something to organise around.
The interfaces aren't necessarily the product's main identity.
They're different surfaces through which the same underlying system can be used.
And that is a much stronger starting point than deciding that what the world really needs is another nearly identical chat window.
A good agent should be able to help develop itself
There's another principle I find particularly important.
Dogfooding.
Using your own product for the work involved in creating and maintaining that product.
If you're building a coding agent, can you actually use it to work on its own codebase?
Can it investigate its own bugs?
Run its tests?
Read its documentation?
Change its configuration?
Inspect the results?
And help improve the parts of the project that aren't working properly?
This isn't simply a nice marketing story.
It creates a feedback loop that external testing rarely reproduces.
When you use your own product every day, you discover small problems.
Uncomfortable navigation.
Unhelpful error messages.
Lost context.
Confusing permissions.
A setting that technically works but is unnecessarily difficult to find.
A background task that completes correctly but leaves the user wondering what happened.
These issues may never receive a GitHub ticket.
They're often too small.
Too annoying to describe.
Or the user simply returns to a tool that already works better.
Which means a development team relying exclusively on external reports may never encounter some of the most persistent sources of friction.
I would be careful, however, about trying to infer whether a project is dogfooding its agent solely from commit histories.
A commit authored with help from Codex or Claude Code doesn't prove the project's own agent wasn't used elsewhere.
Nor does the absence of obvious self-authored commits establish that maintainers avoid their own product.
That requires better evidence.
But the underlying design test remains valuable.
If an agent is intended to perform real development work, its maintainers should be among the people most motivated to use it.
And if they consistently cannot, that's worth investigating.
Self-configuration is more than a convenient party trick
Coddy has another feature I find relevant to this discussion.
It provides tools for inspecting and modifying its own configuration.
Changes can be staged.
Validated.
Reviewed.
And applied through an explicit commit mechanism.
It also supports configuration checks and dry-run diagnostics.
This is a useful approach because settings are often one of the least pleasant parts of developer tools.
Open a complicated configuration screen.
Find an obscure option.
Change it.
Restart the application.
Discover that something else has stopped working.
Then spend twenty minutes trying to remember what the original value was.
An agent capable of understanding its own configuration can offer a different experience.
You can describe the result you want.
The agent can inspect the relevant settings.
Propose changes.
Validate them.
And explain what will happen before applying them.
But this is only useful if the process is controlled.
An agent that can freely modify its own permissions and runtime without meaningful safeguards is not particularly reassuring.
Self-configuration needs boundaries.
Validation.
Approval.
And recovery.
In other words, the most useful version isn't:
Let the AI change anything it wants.
It's:
Let the AI help manage the system while making the changes inspectable and reversible.
That's a practical feature with consequences for real usability.
And it follows naturally from the idea of an agent that understands and operates its own environment.
A swarm is not just several chat windows
The emphasis on distributed operation is another distinctive choice.
When people discuss agent swarms, they sometimes mean nothing more than opening several agent sessions simultaneously.
One writes code.
One reviews it.
One investigates the documentation.
And perhaps another produces a remarkably confident summary of the others' activities.
That's useful in some circumstances.
But a real distributed agent system introduces additional problems.
Where does each task execute?
Which machine has access to which resources?
How are permissions scoped?
How does an agent recover after a network interruption?
What happens when two agents modify the same repository?
Who coordinates the work?
Where are the results stored?
And how can a human understand the state of the entire operation?
These questions are particularly important if agents are running across containers, servers and local machines.
Coddy's swarm-oriented design attempts to address part of that operating environment.
Again, this is an architectural direction, not proof that every aspect of the implementation is already ideal.
But it illustrates the difference between a feature and a premise.
Adding a multi-agent button to a desktop interface is a feature.
Designing a runtime around distributed agent operation is a premise.
The latter changes which problems the product must solve.
And which compromises become acceptable.
Your clever idea should survive contact with actual use
There's a danger on the other side, too.
Developers can become so attached to their differentiating idea that they stop noticing whether anyone actually wants the result.
A beautiful architecture isn't automatically a useful product.
Neither is a static binary.
Neither is perfect protocol compatibility.
Neither is an agent that can modify its own configuration.
These things matter only when they make something meaningfully better.
Easier deployment.
More predictable operation.
Lower resource usage.
Better isolation.
Greater flexibility.
Less user friction.
Or access to workflows that were previously difficult or impossible.
And that's why dogfooding matters so much.
A unique idea must be exposed to reality.
Repeatedly.
Not just demonstrated in a polished video.
Not just described in a README.
Actually used.
For unpleasant tasks.
For complicated tasks.
For debugging.
For maintenance.
For the kind of ordinary work that makes up most of software development.
If the tool is excellent only in its own promotional examples, it isn't ready.
And if the developers are constantly returning to another product to accomplish the actual work, they should probably ask why.
Before building your own agent, answer one question
I think the coding-agent ecosystem would benefit from more projects that begin with a specific, defensible problem.
Not:
I want to make an open-source Claude Code.
Or:
I want a Codex alternative with a nicer sidebar.
Or even:
I want one application that supports absolutely everything.
Those can be starting motivations.
But they're not necessarily compelling product strategies.
A more useful question is:
What important thing will my agent do better, or differently, than the tools people already have?
Perhaps the answer is extreme portability.
Perhaps it's reliable execution on low-resource hardware.
Perhaps it's integration with a specialised engineering environment.
Perhaps it's distributed operation.
Or unusually strong verification.
Better control over data.
A genuinely different interaction model.
Or a workflow that existing products make unnecessarily difficult.
The answer doesn't have to be spectacular.
It doesn't even have to appeal to millions of users.
A small, focused tool that solves an actual problem can be much more valuable than an ambitious clone that solves no new problem particularly well.
But the answer should exist.
And it should influence the architecture from the beginning.
Not appear later as a feature added to justify another interface.
Build the thing you actually want to use
There's an amusing contradiction in the current AI-development ecosystem.
Tools that make software easier to create have also made it easier to produce software that didn't particularly need to exist.
You can generate an interface.
Build a backend.
Add model support.
Create documentation.
Package an application.
And publish it before the end of the weekend.
Which is remarkable.
But the fact that software is easier to build doesn't make product judgment less important.
It makes it more important.
Because now the hard part isn't necessarily getting something to run.
It's deciding what deserves to be built.
I don't think the world needs fewer experiments with coding agents.
Quite the opposite.
The technology is young, and there's still enormous room for different approaches.
But I'd like to see more experimentation with fundamental assumptions.
How agents manage durable knowledge.
How they verify their work.
How they coordinate across environments.
How autonomy and permissions interact.
How interfaces can become simpler rather than more elaborate.
And how a development tool can participate meaningfully in its own improvement.
Projects like Coddy are interesting when they approach these questions through a distinctive architectural premise.
Other projects may find better answers through entirely different designs.
That's healthy competition.
The point isn't to build one universally correct agent.
It's to stop confusing familiarity with innovation.
If you're considering building your own coding agent, I'd begin with two requirements.
Find a reason for the project to exist beyond copying the tools you admire.
Then use it enough that its weaknesses become impossible for you to ignore.
Everything else can follow.
Including, if you absolutely insist, another sidebar.
Projects and references
Editorial note: This is an independent reflection on coding-agent product design, informed by a developer's discussion of building Coddy. It does not imply that I created Coddy, independently benchmarked the named products, or audited their maintainers' development workflows.