The Compounding Software Factory: How to Make Engineering Teams Get Better Over Time
Published on 29.04.2026
The Compounding Software Factory
TLDR: Most engineering teams degrade over time by default. This article, the final in a three-part series, argues that AI-assisted development gives teams a real shot at inverting that trend through compound engineering: improving coding hygiene, capturing institutional knowledge, and building the right things incrementally.
Summary: Anyone who has worked on the same codebase for years knows the trajectory almost never improves on its own. Codebases become brittle, large teams ship less per engineer than small ones, and products accumulate technical debt faster than anyone wants to admit. Luca Rossi and CircleCI's Rob Zuber frame this honestly: roughly 90% of teams are on a downward slope by default. The surprising conclusion is that AI doesn't just offer a speed bump, it potentially offers an inversion of that slope entirely.
The piece builds on two prior articles in the series. The first established that teams winning with AI today are the same ones that had good developer experience three years ago. The second laid out a progression from specs to rules to modules, each step making AI-generated code more reliable and reusable. This third article asks what happens when you run that loop not just once, but continuously, over months and years.
The root causes of degradation are identified as three: poor coding hygiene (weak test coverage, tangled abstractions, high complexity), failure to capture knowledge (no decision records, no architectural summaries, no playbooks), and the resulting tendency to build the wrong things. What's interesting here is that AI makes addressing all three more tractable than before, but only if you deliberately instrument for it. AI can write code that passes hygiene gates automatically. CI pipelines and local hooks can enforce test coverage and code health metrics before anything reaches shared infrastructure. Automated agents can scan Sentry logs, file issues, and even draft fix PRs on an hourly cadence.
Knowledge capture gets particular attention. The argument is that everything should be captured now because processing and maintaining that information is cheap with AI. Raw meeting notes, architectural decision records, product direction documents, and per-feature specs can all be fed into an AI that assembles a living ARCHITECTURE.md or product overview from atomic pieces. The point is not that AI writes the knowledge, but that it handles the orchestration once humans provide the atomic units.
The closing section on managers is the most contrarian take in the piece. Engineering managers often struggle because their feedback loops are measured in weeks or months. Agent workflows operate on timelapse: mistakes are fast, course corrections are fast, and the signal-to-noise ratio on process experiments improves dramatically. If every engineer is now operating more like a manager, directing agents rather than writing every line, then experienced managers already have a head start because they know how to set direction and measure outcomes over time.
Key takeaways:
- The default trajectory of software teams is degradation; AI doesn't fix this automatically, but it does make fixing it tractable.
- Coding hygiene (tests, code health, abstractions) should be enforced via gates in CI and local hooks, not just hoped for.
- Automated agents doing KTLO work (dependency updates, Sentry scanning, bug triage) reduce cognitive load and can run on recurring schedules.
- Capturing knowledge aggressively, including decisions and architectural intent, is the single highest-leverage activity for compounding improvement.
- Managers may have a structural advantage in the AI era because orchestrating agents and measuring outcomes over time is what they already do.
Why do I care: The hygiene-first argument resonates deeply from a frontend architecture perspective. I've watched component libraries drift, design system rules get ignored, and bundle size creep up in codebases where no one enforced anything at the boundary. The idea of shifting validation left, running health checks locally before CI even sees the code, is sound. My reservation is around the knowledge capture workflow: the article makes it sound easier than it is to keep ADRs and recap docs accurate and actually consulted. The real test isn't whether you can generate an ARCHITECTURE.md, it's whether the next developer (or agent) trusts it enough to act on it. That trust is earned through process discipline, not just tooling.