Cleaning up AI-generated code

What the signal means

A member asked a question many technical leads now face: how do you clean up a codebase written largely by AI? The thread that followed was one of the most practical of the week.

Some answers pointed to classic material: clean-code principles, SOLID design, test-driven development and the standard text on working with legacy code. One member joked that the field needs a sequel about working with code that was vibe-coded rather than inherited. The joke landed because the problem is genuinely similar. AI-written code often works but has no clear structure, little test coverage and no author who can explain it.

The concrete advice converged on a sequence. First, write end-to-end tests that capture what the app does today, and treat the running app as the source of truth. Second, fix the data model, because most downstream mess comes from it. Third, make business logic pure and repeatable so it can be tested in isolation. A different approach was also suggested: have an agent read the existing code and write a specification, clean up that specification by hand, and then rebuild from it.

Members disagreed about rewriting versus refactoring. Rewriting is tempting when generation is cheap, but others warned that a rewrite quietly drops behaviour nobody wrote down. A side discussion about "vibe coding consultant" as a job title showed that cleanup work is becoming a service of its own.

Practical implications

- Faster generation shifts effort to verification. The tests you write before touching the code decide whether cleanup is safe. - The data model is the right first target. Fixing it pays off across the whole codebase. - Specification-first rebuilds can work, but only if the specification is reviewed by someone who understands the business. - Teams adopting coding agents should budget for later cleanup, not assume it away.

Content and community opportunities

- A step-by-step playbook for stabilising an AI-generated prototype: characterisation tests, data model, pure logic, then refactor. - A workshop exercise where learners have an agent write a specification from existing code, critique it, then regenerate. - Guidance for non-technical founders on recognising when a prototype needs engineering cleanup before it scales.

Risks and open questions

- Rewrites can lose undocumented behaviour that customers rely on. - Agent-written specifications can be confidently wrong. Human review is not optional. - Classic engineering texts help, but their examples predate agents. Teams still need to adapt them. - This was one group's discussion, not a community consensus.

Watch next

- Whether cleanup and stabilisation become a recognised service line for consultancies. - Tools that generate characterisation tests from running applications. - Shared patterns for specification-first rebuilds.