Hermes Cut 375,000 Lines in 15 Hours. Coding Agents Are Starting to Lead Teams

I came across something pretty wild today.

Teknium, co-founder of Nous Research and creator of Hermes Agent, gave Hermes a goal: aggressively clean up its own codebase.

One /goal, one desktop computer, and roughly 15 hours of continuous work. According to Teknium, Hermes kept simplifying, consolidating, optimizing, and deleting code until the repository had shrunk by 375,000 lines.

At first glance, this looks like another story about AI pulling off a spectacular feat.

But after reading the post, one question stuck with me: who was managing all those sub-agents?

Over those 15 hours, the main agent sent wave after wave of sub-agents to inspect, modify, and consolidate the code. The interesting part was not that a model could write or delete code. It was that the system was trying to run a software team.

First, a reality check on those enormous numbers

Teknium described roughly 120 “waves” of sub-agents, plus three groups of 15. Those sub-agents could create sub-agents of their own, turning delegation into a recursive process.

A few minutes later, he added that 1,320 sub-agents had “lived and died” during the session that day.

That does not mean 1,320 agents were running at the same time. It is the cumulative number launched over 15 hours. The original post does not give a clear peak-concurrency figure, so there is no reason to invent an even more dramatic one.

The 375,000-line reduction is also Teknium’s reported result. We have not yet seen the complete diff, a breakdown of what was deleted, the model costs, or the final test report. This was clearly a large-scale experiment, but it is too early to call it a successful autonomous refactor.

What changed was the way the work was organized. A long-running objective went to a main agent, which broke the work down, delegated it, checked the results, and kept moving through successive rounds. Teknium did not spend those 15 hours opening a thousand terminals or telling every sub-agent what to do next.

Goal Mode is not new. The organization is the interesting part

Coding agents have been able to tidy legacy projects and remove duplicate logic for a while.

Hermes itself includes a simplify-code skill. Four reviewers examine recent changes from the perspectives of reuse, quality, efficiency, and abstraction, and the main agent decides which recommendations are worth applying.

Nor did Hermes invent /goal. Its own documentation says plainly that the implementation was directly inspired by Codex CLI’s Goal Mode.

Mechanisms like this give an agent both an objective and a definition of done. As long as the goal has not been met, it starts another round—until it finishes, pauses, or needs more information from a person.

What Hermes did here was connect a long-running goal, large-scale code cleanup, and recursive sub-agents, then keep the whole system running for 15 hours. Work that people used to do—breaking tasks down, assigning them, and chasing progress—started moving inside the agent system itself.

The future may need only one chat window

I have never thought Claude Code or Codex would be the final form of the coding agent.

They are already extremely useful. But most of the time, a person still sits at the computer and tells the agent what to do next. If it heads in the wrong direction, we correct it. If a test fails, we ask it to keep fixing things.

The agent does plenty of work, but we still act as project manager and dispatcher. We break down tasks, choose models, switch tools, decide when to start another agent, and stitch the results back together.

It reminds me of a factory I visited when I worked at Nokia. There was nobody on the production floor. It was filled with highly automated equipment, while the people stayed outside.

The logistics industry has moved in the same direction. JD has described fully automated warehouses that can process more than 1.3 million orders a day during peak periods. SF Express has also reported logistics scenarios in which unloading, induction, sorting, and loading can all be handled without people on the line.

The machines and systems keep working. People no longer have to stand at every operating station.

AI may go through the same transition. Computers, IDEs, code repositories, and specialized agents will all remain. What changes is that people no longer have to sit in front of them and watch every step.

Imagine I say: “We want to add a new membership feature to the product. Start by researching user needs and put together a proposal.”

The main agent could ask a product agent to structure the requirements, a research agent to study competitors, and a design agent to propose the interaction. Once the approach is settled, a coding agent builds it, a testing agent checks it, and a security agent reviews it. The system moves forward on its own and returns only when it reaches a product choice, a data risk, or a production release that needs my decision.

I would not need to open ChatGPT, Figma, Claude Code, Codex, and a pile of testing tools separately. I might need only one chat window.

There may be a single entry point on the surface, but behind it is still a system of agents with clearly divided roles. Development environments, browsers, design tools, test devices, cloud servers, and permission systems do not disappear. They simply move from being a person’s workstation to becoming execution nodes that agents call when needed.

The future coding agent may look more like a software company

Once tasks run for 15 hours—or for days at a time—the experience depends on much more than how well a model writes code.

Can the main agent plan? Can it break the work down clearly and route each task to the right specialist? What happens when several agents touch the same repository? Can the system roll back a mistake? Will it stop and ask a person before taking a high-risk action? All of these capabilities start to matter.

At that point, a coding agent begins to resemble a small software company. Models are the engineers. Skills are the working methods. Tools and sandboxes are the office environment. Tests and reviews provide quality control. The main agent understands the goal, assigns the work, and controls the pace.

Model capability still matters, of course. But when product, design, development, testing, and security roles are all running in the background, how the system organizes them directly affects both cost and outcome.

The more agents you add, the more visible the management problem becomes. More sub-agents can scan and execute faster, but they can also make changes that are locally correct and globally incompatible. Without a shared objective, permissions, and acceptance criteria, recursive delegation can amplify mistakes just as quickly as it amplifies work.

Permission isolation, audit trails, cost controls, data security, result validation, and clear accountability all become unavoidable. One chat window can hide the complexity from the user, but it cannot make that complexity disappear. It only moves it inside the agent system.

AI writes code so quickly that cleanup becomes a job of its own

The experiment carries another practical warning: the faster we can produce code, the easier it is for a project to become bloated.

A bug appears, so we ask an agent to add a check. An old approach still needs to work, so another wrapper goes in. The new implementation ships, but the old one stays in the repository. The same capability gets built several times, local patches pile up, and the tests, scripts, configuration, and documentation keep growing.

Human-written code creates technical debt. AI-written code does too, and may accumulate it faster. A future main agent will need to know not only how to assign more coding work, but when to stop, reorganize, and delete what no longer has value.

There is another very direct reason to clean up code: money.

This May, two researchers ran a controlled set of experiments with Claude Code: 33 tasks across six pairs of minimal repositories, for a total of 660 runs. Cleaner code did not significantly change the final pass rate, but it did change how the agent worked.

In the cleaner repositories, the agent used roughly 7%–8% fewer tokens and revisited files about 34% less often.

A clean codebase may not determine whether an agent eventually completes the task. It does determine how many detours it takes, how much context it has to read, and how much money it burns along the way.

We used to clean up code mainly so the next programmer could understand it more easily. Increasingly, we will also do it so the next agent has less to read, less to guess, and fewer tokens to spend.

For now, this is still an experiment

The Hermes cleanup still lacks a complete diff, cost breakdown, and acceptance results. Lines of code have never been a reliable measure of quality. Whether the original behavior survived, the tests passed, performance regressed, and the dependency graph actually became simpler matters far more than how many lines disappeared.

So I would not treat this as proof that large software projects can already run without people. Seen from where we are today, it looks more like a preview of a future product: a person defines the goal and the boundaries, while the main agent organizes the models, tools, machines, and other agents behind it.

In the near term, every developer may have a coding agent. After that, a company may have a single agent entry point. Employees describe what they want to accomplish; the system decides who should do it, where the work should run, and when to come back for a human decision. People remain responsible for the goal, the boundaries, and the critical judgment calls.

A mature agent system should let you stop watching most of the time—and know exactly when to come back and ask.