Eighteen months ago I would have written this post about speed. About how an agent drafts in a minute what used to take me an hour. Today I'm writing it about discipline — and that shift is the whole story of the past year and a half.
I've been living in a mode where a coding agent writes a significant portion of my code for about eighteen months now. First came exhilaration, then fatigue, then a sober realization: an agent without a harness is not an engineer. It is a very fast, very forgetful junior. It can draft in a minute what would take me an hour, but in that same minute it will cheerfully take out a neighboring module, skip the tests, invent a library method that doesn't exist, and forget what we agreed on five messages ago. As a technical manager, I look at this plainly: the problem is not code generation speed. The problem is the absence of process around that generation.
I had been using GitHub Speckit. So when ECC (affaan-m/ECC) crossed my radar, I didn't bite on the headline numbers — "71 agents and 311 skills" tends to make me more wary than enthusiastic. I bit on a single line in their description: plan, test, implement, review, verify, remember, improve. That is not a feature. That is the normal engineering cycle we have spent decades trying to drill into live teams. And here was someone proposing to hardwire it directly into agent behavior — once, so you don't rewrite it in every prompt. I wanted to know how well that works in practice, not on a landing page.
What ECC Actually Is
ECC is not another model and not a replacement for Claude Code. It is a harness — a layer that sits on top of a coding agent and imposes a workflow on it. Think of it as an operating system for the agent: a set of specialized sub-agents, a set of skills, hooks, rules, memory, and a security scanner. It installs as a plugin, MIT-licensed, so the source is open and free. The project makes money from cloud hosting for private repositories and from sponsors.
Their philosophy is stated with almost engineering-dry brevity: optimize the context window, persist everything else. Translated from developer-speak into plain terms: the agent has limited memory and physically cannot hold the entire project in its head. So everything that can be moved out of its working memory into files, rules, and structure should be moved out. What stays in its head is only what the current step needs right now. As someone who spends a lot of time thinking about systems architecture, this idea is familiar and close. It is exactly what we do when we design a stateless service and push state into a database.
Installation
Installing it was almost embarrassingly simple, and that is the first point in its favor. No cloning repositories, no manually placing configs. There is a single installer — you run it through npx, it finds all the locations where the plugin can go, asks you for the installation scope (global per user, per project, or local), asks for a hook profile, and installs. Done. I deliberately installed it globally on my own user with the standard profile first, to observe the default behavior rather than a polished configuration tuned for a specific repository.
One detail worth noting: the installer runs an inventory first. It shows what you already have installed, where it plans to write, and only then asks for final confirmation. For a manager who is responsible for several machines and for making sure colleagues don't turn their environments into a mess, this is an important signal. The tool does not barrel in blindly.
The Real Task I Ran It On
I don't like synthetic demos, so I pulled a real task from our backlog — one I had been postponing precisely because it was simultaneously boring and risky. The job was to refactor the data access layer in one of our services: extract bloated business logic out of controllers, introduce a proper repository layer, and not break a dozen existing endpoints that already had clients sitting on top of them. Classic refactoring where the price of a mistake is production and the satisfaction is roughly zero. A good test of whether ECC handles discipline, not just generation.
The first thing — and exactly what I expected — was that the agent did not jump into writing code. It built a plan first. Not an abstract "let's refactor this," but a concrete breakdown: here is the current structure, here are the affected endpoints, here is the step order, here is what we check after each step. As a technical manager, I spend half my life trying to get people to think before they act. Here it happened by default. I could read the plan, adjust something, and only then give the go-ahead. Naturally, no one actually reads the plan in practice.
The second thing: tests came before implementation, not after. On a refactoring step where it would have been easy to break everything, the agent first pinned down current behavior with tests, then changed the code, then ran the tests again. This is a safety net before refactoring — and what live developers under deadlines almost never do. Here it was part of the process, not a heroic effort on my part.
The third, and the most interesting to me: review from a fresh context. ECC can run a check on its own work as if a different agent were doing it — one that did not see how the code was written and sees only the result. This is a fundamentally different mode. When you write code yourself, you look at it with loving eyes and see what you intended to write, not what you actually wrote. A separate reviewer without that attachment found a couple of real spots where behavior had shifted slightly from the original. Caught before the merge. Good.
What Worked Well
Discipline. That is the key word. ECC turns the agent from a sprinter into an engineer who moves in steps. For tasks where the cost of error is high, this is invaluable. I stopped feeling like I was sitting over the agent with a ruler, slapping its hands.
Cross-session memory. The agent remembered architectural decisions we made at the start and did not try to revisit them at step five. We agreed once, and it held to that. For long tasks that don't fit in a single session, this eliminates an enormous class of headaches.
Security by default. The built-in scanner watches what the agent and its environment are doing: prompts, hooks, configs, secrets. For someone who is partly responsible for making sure a key doesn't accidentally end up in a repository and that agent automation doesn't become a security hole, this is not a marketing checkbox — it is real risk reduction.
Process as code. The valuable piece. Previously, our entire agent process lived in the heads of the two or three people who knew how to prompt well. That does not scale, and it walks out the door with the person. ECC turns the process into an artifact that you can install identically for the whole team. This is exactly what I, as a manager, am willing to pay for.
What Concerned Me
Volume. 71 agents, 311 skills, nearly a hundred commands. I honestly don't believe a person can hold all of this in their head and apply it meaningfully. Most of this richness sat idle for me, and for a newcomer that quantity of entities is more likely to intimidate than help. I would prefer fewer, with a clearer map of when to use what.
Decision opacity. When the agent chooses on its own which skill or sub-agent to invoke, it is not always obvious why it picked that one. In most cases the choice is reasonable, but when it gets it wrong, untangling why it went down that path is harder than with a bare agent where you hold everything yourself. This is the price of automation, and it should be accepted consciously.
Dependence on model maturity. The entire process is only as good as the model underneath it. On a strong model, ECC works better: the plan is meaningful, the review is useful. I suspect that on a weaker engine, all this orchestration will start producing a polished process on top of mediocre decisions — and that is more dangerous than an obviously weak agent, because it creates a false sense of reliability.
Single maintainer. The project is primarily maintained by one person. For MIT-licensed open source, that is normal — you can always fork. But if I am embedding this into a team process, I have to keep in mind the risk that development pace depends on one person, and I need a plan in case they burn out or walk away.
Where I Will Keep It and Where I Won't
ECC solves the right problem. That matters. Most tools around coding agents try to make generation faster or smarter. ECC does something different and, in my view, more valuable: it handles the process around generation. And process, not typing speed, is what separates engineering from chaos.
For me as an architect, the core insight is this: an agent without a process is a lever without a fulcrum. You apply force, but it is unclear where it lands. ECC provides that process. It does not make the agent smarter — it makes it more disciplined, and in engineering, discipline almost always outweighs raw intelligence.
Will I deploy it? As one tool alongside GitHub Speckit — yes. On risky tasks with a high cost of error, on refactors, on legacy work — likely yes, and specifically in project scope with rules tuned to the repository, not in a global default configuration. On small one-off tasks where I hold everything in my head already, all this machinery is excess weight — a bare agent is faster there.
The value of an engineer is shifting from writing code by hand to designing the process by which code gets written. ECC is one of the first serious attempts to package such a process into an installable artifact. It is not perfect, it is bloated in places, but the direction is correct. That is why these tools are worth testing, even if today you only take half of what they offer.
Eighteen months from now, the engineer who still measures their worth by how fast they can type code by hand will be measuring the wrong thing.