In Introducing Dap, Martín wrote about the tension between speed and quality—how AI can generate code fast, but speed without judgment creates debt. What that entry didn't cover is that building Dap has forced us to confront a different kind of debt. One that was always there, but is now impossible to ignore.
The inversion
For years, technical debt was the tax on moving fast. Messy code, missing tests, shortcuts that compound. We knew how to measure it, talk about it, pay it down.
AI changed the economics. Refactoring that used to take days now takes hours. Agents can clean up code, add tests, fix the obvious stuff. The cost of traditional technical debt is trending toward zero.
But that shift revealed something. As the old debt got cheaper, other kinds of debt became visible—higher up the stack, harder to name. They were always there. They just weren't the bottleneck. Now they are.
Product debt. We ship faster, but what are we shipping? When agents can implement features in minutes, the constraint shifts to knowing which features matter. Teams ship more and understand less. The backlog clears, but coherence erodes.
Cognitive debt. The codebase evolves faster than our understanding of it. Changes accumulate. Patterns shift. Six months later, you're reading code that technically came from your team but doesn't feel like yours. You know what the system does. You've lost track of why.
Development speed used to be the bottleneck. Now these debts are. And most teams don't have language for them yet.
What building Dap taught us
We didn't start with a theory about debt hierarchies. We started trying to make AI agents useful in real delivery work. The learning came from what broke.
Knowledge graphs exist because memory kept failing. Early on, agents would make decisions that were locally correct but globally wrong. A component would get refactored in a way that contradicted a decision made three months ago—a decision no one remembered except the person who made it, and they'd moved to another project.
We needed a way to capture not just what the codebase contains, but why it's shaped that way. When someone chooses Devcontainers for a project, Dap doesn't just record the fact. It captures the reasoning. The movie, not the picture.
This isn't about building a fancy system. It's about fighting cognitive debt at the source—preserving context that would otherwise evaporate.
Architecture choices came from feedback failures. Agents work well when they get clear signals about whether they succeeded. Most codebases aren't built for that. Tests exist, but they test the wrong things. CI passes, but the output misses the point.
We've been learning what structures help agents get accurate feedback. Tighter loops. Clearer contracts. Systems designed so that "it works" and "it's right" are harder to confuse. This isn't just about AI—it's about building systems that resist product debt by making intent explicit.
Running our own models came from a dependency problem. We use external providers. They're good. But building core capabilities on infrastructure you don't control carries risks that compound over time.
Pricing models change. What's affordable at experiment scale becomes a budget problem at production scale. Licensing terms get more restrictive—subscription models that worked last year may not work next year. Security and data policies shift in ways that affect what you can build and for whom. When your AI capabilities depend entirely on third-party decisions, your roadmap depends on them too.
So we've been learning to run models locally—vLLM, llama.cpp, the unglamorous work of understanding batch sizes and memory constraints and what happens when inference gets slow. Not because open models are better today. Because the gap is closing, and having options matters more than most teams realize.
What we don't know yet
We're not claiming to have solved the debt problem. We're claiming to have named it, and to be working on it.
Open questions we're still sitting with:
- How do you measure cognitive debt? We can feel when it's high. We don't have good metrics yet.
- What's the right granularity for knowledge capture? Too coarse and it's useless. Too fine and it's noise.
- How does a knowledge graph evolve over time? Adding facts is the easy part. The harder problem is relating them, updating them, making sure they reflect reality as the project changes—not a snapshot of how things were six months ago.
- Can these patterns transfer across teams, or are they too dependent on specific contexts?
Why we're building this
Crunchloop has spent four years as a software partner—working alongside companies, not just for them. That relationship is the foundation of what we do.
But being a software partner in this era means more than providing services. It means building technology. The AI shift is too fast and too fundamental to just observe from the sidelines, waiting for tools to mature. The teams that understand these systems deeply—how to run them, how to design around their limits, how to preserve coherence while moving fast—will be the ones who can actually help their partners navigate what's coming.
Dap is how we're doing that learning. Not in a lab. In real delivery, with real teams, on real problems.