コーディングエージェント開発における技術的負債のリスクを警告

Everyone seems to be building an in-house coding agent platform. I understand the appeal. Coding agents make it cheap to get a prototype running. It’s fun to build a product that is redefining software engineering. However, consider the long term implications. This happens with lots of innovations, remember when every company planned to train its own GPT?

Maintenance and technical debt always come due. The team having fun building the agent today will be fielding bug reports from grumpy developers in six months. Another team may fork a different project and build something better. Then the organization has two platforms, two sets of users, and a new debate over which one deserves support.

Luckily, much of this work happens in public, so we can bring data into the discussion. I pulled twelve months of public activity from four coding agent products: OpenHands, where I work, OpenAI Codex, OpenCode, and Hermes. I looked at merged PRs, bug-fix share, lines changed, and current code size. I wanted to understand what it takes to build and maintain a coding agent after the demo works.

The big picture

OpenHands ships across four public repos: the app, Agent Canvas, the SDK, and the CLI. I summed those repos. The other products concentrate their work in one flagship repo, so I used that repo for each. Feel free to quibble with the comparison or run it yourself. I am confident the point will hold.

Every product merged thousands of PRs over the past year and carries more than a million lines of code. A large share of the work is bug fixes, from 16% at Codex to 40% at OpenCode, with OpenHands at 31%. Hermes comes in at 68%, although its labeling conventions may explain some of that difference.

Beyond bug fixes, there is non-stop innovation in coding agents. Every week brings new models, new ideas, and new features to build. This means your team is signing up to track every model release and agent design shift, indefinitely.

OpenHands and OpenCode are especially interesting. Different teams built them in different languages, with different architectures, yet the activity is very similar. 5,679 versus 5,700 merged PRs, and about 1.05 million lines of code each. That is a solid estimate of the work behind a production coding agent.

A coding agent is never one codebase

"A coding agent" sounds like one program. In practice, it is a platform.

OpenHands makes the split easy to see. The app contains the agent application and server. The Software Agent SDK provides the runtime underneath it. Agent Canvas gives developers a UI for working with agents, while the CLI brings the same work into the terminal. Each piece is a substantial codebase with its own stream of changes.

.png)

The other products have similar divisions. The Codex repo holds the CLI, dozens of core runtime crates, an app server, MCP support, and Python and TypeScript SDKs. OpenCode's packages/ directory includes core, server, cli, desktop, tui, web, two SDKs, and a plugin system.

The pace is also accelerating. Codex grew from about 124 merged PRs a month in mid-2025 to around 1,000 a month a year later. Hermes went from a nearly empty repo to roughly 2,000 merged PRs a month within months of getting serious.

Forking is a start, not an end

Your team might want to start with a fork of an existing product. A fork saves you from starting at zero. It also creates a gap between your code and everything upstream ships next.

Say you forked the OpenHands app twelve months ago and never merged from upstream. You would now be 2,600 merged PRs behind, including 866 bug fixes you do not have. Those fixes cover crashes, regressions, security patches, and model-compatibility repairs found by 179 contributors while your team worked on custom features.

That is only the app. The SDK underneath it moved another 2,036 PRs during the same period. The gap between your fork and current upstream would be more than 4,600 PRs, about thirteen a day, every day, for a year.

Your options at that point are all bad:

• Rebase onto upstream. Your team resolves conflicts against a year of changes to the same core files your customizations touch. That can take weeks, and the work returns with the next rebase.

• Cherry-pick the fixes you need. Someone reads a dozen-plus upstream PRs every day and decides which ones apply. That is a standing job.

• Go it alone. Your team now maintains a coding agent platform. The first table gives a rough price: 5,000 to 8,000 merged PRs a year across more than a million lines of code, with a substantial share devoted to fixes. Your internal version may need only a fraction of that surface area, but even then it’s still a lot of work.

Sometimes a fork with a few customizations is exactly what you need. But coding agents are moving fast. Keeping one current takes domain knowledge, ongoing work with new models, and continual upkeep.

Start by building on the existing coding agents

If you need to customize a coding agent, here are some options:

Start with configuration and system prompts. A surprising amount of "we need our own agent" turns out to mean "we need our own prompt, tools, and defaults." Most agents let you change all three without touching the core code.

Use MCP servers for internal systems. If the agent needs to talk to your internal tools, build a tool server. You can keep updating the agent without reapplying that integration to a fork.

Package repeatable work as skills or plugins. These give the agent your organization's expertise without creating a permanent fork delta.

Build on the SDK when you need a different agent. The OpenHands SDK and Claude Agent SDK exist for this case. Your team owns the product-specific layer while upstream keeps maintaining the runtime underneath it. For OpenHands, that means the 2,036 annual SDK PRs keep happening upstream instead of becoming your backlog.

If you still decide to maintain your own coding agent platform, assign several engineers to it and make upstream tracking part of their job. Treat it as a product, because that is what it becomes.

Method notes and caveats

• I pulled the data on 2026-07-08 through the GitHub GraphQL and REST APIs. Merged PRs are the unit of contribution. Contributor counts exclude bots.

• Contributor counts are per repo and cannot be summed across repos without double counting, so I quote them only at the repo level.

• I compare products at the product level. OpenHands is the sum of four public repos. Codex, OpenCode, and Hermes use their flagship repo, so their totals are understated when work happens in private or additional repos.

• Bug-fix classification is heuristic. I counted bug, regression, and defect-style labels, plus fix: and hotfix: titles. This misses unlabeled fixes and catches some false positives. Label hygiene also varies by project, so compare the shares directionally.

• Code size includes tracked code, config, and test lines from shallow clones. It excludes lockfiles, generated code, vendored dependencies, and binary assets.

• These products differ in scope, age, and private development. This is a sanity check, not a ranking. The point is that all of them move faster than a casual fork can track.

Sources

• OpenHands app: https://github.com/OpenHands/OpenHands

• OpenHands Software Agent SDK: https://github.com/OpenHands/software-agent-sdk

• OpenHands Agent Canvas: https://github.com/OpenHands/agent-canvas

• OpenHands CLI: https://github.com/OpenHands/OpenHands-CLI

• OpenAI Codex: https://github.com/openai/codex

• OpenCode: https://github.com/anomalyco/opencode

• Hermes: https://github.com/NousResearch/hermes-agent