The software industry isn't going back to the days of manual development. You know that, I know that, the AI industry knows that.
The problem with AI-gen'ed code isn't the actual code quality. It's the structure.
- scattered state - variables everywhere, no flow consistency
- nested functions - high (cyclomatic) complexity, sensitive to errors
- spaghetti ball - no overarching design, interwoven call-graphs, changes cause trouble
- god files - large growing code in a single file
The reason why Python is so popular is, that such effects are felt less. The effects of unreadable, hard to maintain code. If you have long-running AI-code projects, you will know these problems. AI agents behave different each time. Code becomes messy. Bugs come up. Models argue.
- with growing lines of codes / more features AI coding agents make more mistakes
- with more mistakes come more turns
- with more turns, higher token expenses
Then you complain: Fable 5.x isn't good enough. Kimi Kx is too stupid. I can't use Sonnet 5.x because it's not capable. It's not even a context window size problem. It's a problem of a lack of software design, which coding agents cannot easily be trained for in 2026. But that will happen.
For now... I have a different plan.
Understand the problem
I run projects with specification-driven programming (Kiro, cc-sdd, spec-kit). This is for long-running, clearly guided and high quality projects. When it matters. This isn't for a quick dashboard or a quick script. Although I found out that the requirements analysis phase helps there as well, because the documentation problem can be inherently solved. More on that later.
For Python, many code quality issues can be handled with Git pre-commit hooks. We have tools like mypy, ruff, black. These are mostly linters. They reformat code to follow a layout standard, pretty much like document templates in MS Word. These linters exist for many languages.
For C++ you have the problem, that god-files, multi-inheritance and other advanced language features make the complexity explosion to be felt. Not only token costs. It costs time (your's) and performance.
for Go it's like with Python. Everyone writes the same kind of Go code. Go is very friendly to AI driven coding. Same for Rust, with a few exceptions here and there, if you are interested in quality code.
For JavaScript or TypeSkript I see nightmares of refactoring sessions coming. And that's what our vibe-code crowd uses. To a massive extend. I see 15x growth.
Given that I am also a developer by heart ❤️ I decided to build up a toolstack. That untangles the mess. Here are some parts of it.
Refactor brownfield projects with tests
First thing to do is to extract the requirements from the code, or to analyze them in greenfield projects.
gotalab
CC SDD
code is easy, specs are not
This way boundaries, seams, and architecture patterns get modelled. For fresh and existing projects.
I have extended upon the EARS description (a engineering language convention) with a practical software verification idea:
I plan to extend this over to cc-sdd also focused on current specs to allow super-seeding of requirements. The idea to use model checkers on spec level helps to avoid that you either build the wrong thing, or that they thing you want to build doesn't get build.
Imho EARS and Test-Driven Development (TDD) are a key to unlock the potencial of AI coding agents for real-world projects. In combination with practical software and formal requirements verification, you will likely get the best possible results in 2026 - 2027. Until AI models become better.
Scitools hook (alpha)
Many developers will have to refactor vibe code. I had to refactor mine. I help others on occasion. One tool that pays off in commercial settings in SciTools Understand.
SciTools Hook
beyond static
That's the kind of tool to put on the budget for 2027 if you have to take over tools from managers (who vibe code) or from other people with domain expertise.
I use it (alpha) for a project with 914 Python files and 124.000 functions (cc-sdd, 50% of the code are tests).
DocuHarnessX for developer documentation
I don't write documentation, and neither do you. I developed a technical writing harness that produces an evolutionary documentation set. This docu is grounded in vocabularies (ontologies) to agree on a common language.
DocuHarnessX
evolutionary documentation
Then the harness produces docs, and you tell it to make XYZ better. It uses roles and a human centric docu structure. Primarily mkdocs. Refinements produce journals, which can be used for self-improvement of the harness.
Imho developer docu is unsolved for now, but the combi of spec-driven development + documentation harnesses makes it approachable without manual effort. Of course this isn't for customers of software. That is docu you can leave to a product manager. There are many AI projects for this already (example).
DocuHarnessX uses DeepSeek Flash models, because they are cheap. You can switch to any OpenAI compatible model using the Base URL.
License
These projects are under MIT license, and can be adopted by anyone. Ideally you send me a PR.
I use these tools, so they will get better over time.
