Why I use AI

For all this time I believed LLMs were pure evil, but once Fable 5 came out and I tested it, my view changed. I finally got code that needed only moderate corrections. I am not talking about bugs here, I am talking about code quality. My standards are high, I want code that follows good programming practices, is readable and optimal. The bigger a project grows, the harder it is to maintain, which is why I believe in clean code. It is easier to scale something written properly, without worrying about bugs that cost a business real money.

SeqPlanKit

As always with a new tool or library - and it was no different here - I researched how to use AI properly. I read far too many papers on it and went looking for skills and MCP servers that would help me work. None of them met my expectations on quality, so I built my own toolkit for Claude Code.

The premise is simple: you spend tokens and wait longer for code that is a smaller headache to review afterwards. It also buys the process more autonomy, with less manual project management to make sure it does what it was asked to do.

Here is how it works:

• One step at a time, one fresh agent each. Every step reads the code the previous step wrote, so no interface is ever guessed and the context never hallucinates its way around frozen contracts - contracts that should have looked different, which the run itself exposed, though the LLM will never admit it - invented only so the work could run in parallel.
• A gate after every step, a commit on green and a ledger on disk. Test only at the very end of a plan and the LLM starts guessing where the failure is, with a real risk it introduces a regression just to make the test pass.
• Better review. Two concurrent read-only lanes, one anchored in the plan and one blind to it. The ordinary review shows what went wrong against the plan. The blind review sees what went wrong with the code quality.
• Parallelism has to be earned. Sometimes work really can be sped up by running steps side by side, as long as they do not affect the rest of the plan. During /plan-work the user can choose whether the planner should look for parallel splits at all, but whether any actually happen still depends on fairly strict criteria.

A plan does not appear in a vacuum. First the /summary-codebase skill reads the code and writes a repository map into summary/, with file and line citations. That way the plan is written for the code that exists, not for the code an LLM imagined. It is not the same thing graphify does - my code summary is oriented around functionality.

Ahead of the plan sits the backlog. /todo records work in NextThingsToDo.md as numbered task blocks and, when a task needs clarification or has gaps or conflicts with others, it holds a dialogue with the user. A plan is only decomposed out of such a block, so the “what are we building” decision is made and written down before anyone starts laying out steps. That protects us from planning off a prompt the LLM did not understand, understood wrong, or one we simply got wrong ourselves.

A backlog with many tasks can hold them in the wrong order or in conflict with each other, and some can sometimes be merged into one. /todo-untangle walks it against the real tree: classifies the entries, re-anchors them to files that exist, fixes the order and renumbers. /brainstorm runs a few agents that find gaps and extensions. It looks for good ideas worth adding to a future plan. All of it is consulted with the user, of course.

Review and fix run in cycles. Both lanes report their findings, the fixer closes them in source and tests - never in the plan, so a problem cannot be “fixed” by rewriting the criterion - then the whole gate ladder runs again and review starts over on the fresh diff. The loop ends when nothing above the chosen severity (blocker/major/minor) is left, or when the cycle bound runs out (which should never happen, but LLMs are a black box); the run then stops and says plainly what is still wrong.

The kit uses three MCP servers. Serena gives navigation and editing by symbol over LSP, so an agent reads a single function instead of a whole file and swaps its body instead of rewriting the file. Graphify keeps the dependency graph and answers questions about architecture and about the blast radius of a change before anyone makes it. caveman saves tokens by writing in a terse but precise style, which also cuts down on context rot.

Not every task needs the whole chain. /ship is a one-shot loop around a single SPEC.md: it grills the idea with questions, then writes the spec (a mini-plan) and only then builds, task by task. The rest of the tools work on their own and anywhere: /audit - the post-build review run by an agent that did not build it, /revise - backpropagating a manual fix or a fresh bug into the spec layer, together with a regression test that has to fail first, /systematic-debugging - reproduce, isolate, prove the mechanism, and only then fix - the skill for fixing manually found bugs.

/test-hardening stands apart. Here the code is presumed correct and the artifact under audit is the test: it hunts for assertions that pass on anything, tests that check the implementation instead of the behaviour, and gaps in the edge cases. /test-hardening-execute lands those improvements one at a time, and each one has to prove itself - the test has to fail against deliberately broken code before it enters the repository. A green suite that catches nothing is worse than no suite at all, because it hands you a false sense of safety.

The whole chain - from the repository map, through the plan and gated execution, to the review and the run record - starts with one script, seqkit-run.sh. You end up with code you can read and a run log you can audit.