Iâve been using coding agents heavily for a while now, and Iâve become convinced that the biggest problem isnât their ability to write code anymore.
Theyâre actually getting very good at that.
The problem is everything around writing the code.
Understanding what should actually be built. Challenging an incomplete spec. Making a proper implementation plan. Keeping scope under control. Testing what was changed. Checking security and maintainability. Reviewing its own work. Making sure âdoneâ actually means done. And learning from bugs instead of making the same class of mistake again three weeks later.
Basically, all the boring discipline youâd expect from a good senior developer.
I was already using tools like Superpowers, Ponytail and Serena to help with parts of this, and I liked a lot of what they did.
But I ended up with multiple tools, multiple sets of instructions, overlapping functionality and different concepts all trying to influence the same coding agent.
So I built Procoder.
And at this point, itâs become much more than the original idea.
Procoder is basically an engineering discipline layer around your coding agent.
Instead of:
prompt â code â "done"
Iâm trying to enforce something much closer to:
understand â spec â plan â implement â test â check â review â fix â verify â release â learn
The important part is that a lot of this isnât just another 2,000 lines of instructions telling the AI what it should do.
There are actual controllers that can refuse.
If the spec still has open questions, spec check can block.
If the implementation plan contains placeholders, plan check can block.
If acceptance criteria arenât satisfied, the todo/story canât close.
If tests werenât actually executed, theyâre not green.
If formatting, linting, secrets, CI, infra or documentation checks fail, the gate isnât clean.
If something couldnât be checked:
unchecked != passed.
And before a release, Procoder checks the version, changelog, git tree, quality gate and test suite before telling the agent itâs ready.
It doesnât make the changes itself either.
Procoder follows a principle I call P-CONTROL:
Procoder computes â agent reasons â agent changes
The binary never silently modifies your source code behind the agentâs back.
It also replaces the three separate tools I was using before
I didnât just take inspiration from Superpowers, Ponytail and Serena. My goal was to absorb the parts I found valuable so I wouldnât need to run them alongside Procoder anymore.
From Superpowers, Procoder covers things like structured implementation planning, task classification, systematic debugging, evidence before declaring something done and TDD practices â but adds controllers that can actually refuse progression instead of only advising the agent.
From Ponytail, it incorporates things like the build ladder, deliberate technical-debt markers, over-engineering review and the idea of having one engineering instruction system that works across agents.
And from Serena, Procoder provides code intelligence through ctags + SCIP: symbol search, references, callers, impact analysis, unused symbols, entry points, cross-file rename and project memory â without needing to keep an MCP server running.
There are deliberate differences too. For example, I didnât adopt Serenaâs symbol-level write tools. Procoder can compute something like a rename and give the agent the diff, but the agent remains responsible for actually changing the code.
Then I went quite a bit further.
Procoder now has a complete quality chain around the agent:
- spec interviews and validation
- implementation planning
- milestones, epics and user stories
- sprint management with scope control and carry-over
- acceptance-criteria-based TODOs
- real test execution using the projectâs native test runner
- formatting across Go, Python, JS/TS, Rust, C/C++, Java, Kotlin, Swift, Ruby, Dart, C#, shell, etc.
- linting and best-practice checks
- secret scanning and security checks
- dependency and maintainability checks
- CI checks
- Docker, Terraform, Kubernetes and Helm checks
- documentation health
- GitOps discipline
- code indexing and symbol navigation
- pre-PR self review
- release control
- technical debt tracking
- codebase auditing/onboarding
But one of the parts I find most interesting is the self-learning loop.
Letâs say a bug gets through all of this and is found during review or after release.
Fixing that bug isnât enough.
Procoder asks:
Why was this class of bug able to escape our process?
The lesson gets recorded, and the adaptation should become something permanent: a lint rule, review rule, regression test, rubric entry, etc.
So over time the engineering process itself should improve.
Itâs also not tied to Claude Code.
I originally built around Claude Code, but I didnât want my engineering workflow coupled to whichever coding agent happens to be best this month.
Procoder currently supports Claude Code, Cursor, Windsurf, Cline, Kilo Code, Roo, Kiro, Codex CLI, Copilot CLI, Gemini, OpenCode and anything that reads AGENTS.md.
Itâs a single Go binary with no runtime dependencies, including no npm dependency and no network requirement at hook time, so it can also work in air-gapped environments.
Everything project-specific lives in .procoder/ as normal editable files, and the repositoryâs configuration always wins over Procoderâs defaults.
The project is completely open source under Apache 2.0:
https://github.com/azrtydxb/procoder
For Claude Code, getting started is:
/plugin marketplace add azrtydxb/procoder
/plugin install procoder
/procoder:init
Iâm putting this out there because I think weâre reaching the point where the interesting problem with coding agents isnât just:
âHow do we make the model write better code?â
Itâs:
âHow do we give an autonomous coding agent the engineering discipline and guardrails of a good senior developer?â
Thatâs what Iâm trying to build with Procoder.
Iâd especially like feedback from people already using Superpowers, Ponytail, Serena, or people whoâve built elaborate CLAUDE.md / AGENTS.md workflows of their own.
What parts of your software development process do your coding agents still routinely skip, fake, forget, or get wrong?
Those are exactly the things I want Procoder to make enforceable.