How much of your codebase exists just to babysit your AI tools?
I finally asked myself that question and did an honest audit. The results were uncomfortable.
What the Audit Found
I found 57 files and 7,102 lines that weren’t product code. They weren’t business logic. They were orchestration — agents, skills, prompt templates, instruction files, context loaders — all built to keep the AI on the rails.
To be specific, this scaffolding included:
- Custom agent wrappers to handle context window limits
- Prompt templates for every recurring task pattern
- Instruction files to compensate for tools forgetting project conventions
- Context loaders to re-inject state the tool had dropped
- Compaction scripts to compress session history before it got too long
All of it existed because the tool couldn’t hold context, couldn’t remember what it had agreed to, and couldn’t be trusted to run without supervision.
The Replace
I removed it. Replaced the entire layer with 12 lean skill definitions in approximately 750 lines.
Same functionality. Same guardrails. Same outputs.
~90% less overhead.
The skills I kept are focused and specific: deploy to staging, run the test suite, generate a changelog, review a diff. Each one is a single markdown file with a clear scope. Nothing needs to chain skills together manually because the tool handles orchestration natively.
The Uncomfortable Question
The question this surfaces isn’t “which AI tool is best.”
It’s: how much of what you’re building is the product, and how much is life support for the tool that’s supposed to help you build it?
If your AI tooling requires significant ongoing maintenance — prompt tuning, context management, compaction routines, custom handoff logic — you’re not getting leverage, you’re adding a second system to maintain.
The metric I use now: if my AI scaffolding takes more than a day to maintain per month, something is wrong. The tool should absorb that overhead, not delegate it back to me.
Less scaffolding. More building.
This was post 1 of the “AI Minus the Friction” series. Follow along on GitHub or LinkedIn.