AI can generate code faster than ever, but it can also scale technical debt faster than ever! Learn the practical strategies to optimize the AI-generated output.
The technical debt scaling is the part that catches teams off guard. People see fast output and assume quality. But slop compounds the same way good code does, just in the wrong direction.
100%. This is why there's a huge variance in teams' performances with AI adoption. For higher quality results, we need better guardrails. Unfortunately our guardrails infra as a software engineering industry hasn't scaled the same way AI-coding has.
In my opinion, of your five guardrails, the slop register is the one that compounds. The other four are disciplines, the team has to keep doing them. The register gets better the longer the team uses it. After six months it catches things no spec would have, because nobody thought to spec them.
The piece that's missing is who owns it. Without a named owner, the register dies the first time the team is under pressure. It's the smallest thing in your framework and it's the easiest one to lose.
Who owns it is a great question, I don't have the right answers for it. One challenge we see commonly is – platform teams commonly become the "fallback" that own everything because no one else would. We need better ownership mechanism
Definitely. Most folks don't understand that if we have to move beyond code reviews, it's not a binary switch. The sooner we start cataloging, the faster we can reduce the review load.
I see this as a shift-left strategy. This makes sense and it's a good way to think about the systemic problem.
I've been experimenting with Spec-kit and found its structured approach very useful. The key was in finding a balance between scoping a feature that's significant enough to warrant the time invested in a detailed spec, but at same time not too big that it overwhelms the context, that as you mentioned, ends up producing hard to review slop. I'll be sharing this approach with my team, and I'm curious to see how well this performs on brownfield projects.
The technical debt scaling is the part that catches teams off guard. People see fast output and assume quality. But slop compounds the same way good code does, just in the wrong direction.
100%. This is why there's a huge variance in teams' performances with AI adoption. For higher quality results, we need better guardrails. Unfortunately our guardrails infra as a software engineering industry hasn't scaled the same way AI-coding has.
In my opinion, of your five guardrails, the slop register is the one that compounds. The other four are disciplines, the team has to keep doing them. The register gets better the longer the team uses it. After six months it catches things no spec would have, because nobody thought to spec them.
The piece that's missing is who owns it. Without a named owner, the register dies the first time the team is under pressure. It's the smallest thing in your framework and it's the easiest one to lose.
Who owns it is a great question, I don't have the right answers for it. One challenge we see commonly is – platform teams commonly become the "fallback" that own everything because no one else would. We need better ownership mechanism
Definitely. Most folks don't understand that if we have to move beyond code reviews, it's not a binary switch. The sooner we start cataloging, the faster we can reduce the review load.
I see this as a shift-left strategy. This makes sense and it's a good way to think about the systemic problem.
I've been experimenting with Spec-kit and found its structured approach very useful. The key was in finding a balance between scoping a feature that's significant enough to warrant the time invested in a detailed spec, but at same time not too big that it overwhelms the context, that as you mentioned, ends up producing hard to review slop. I'll be sharing this approach with my team, and I'm curious to see how well this performs on brownfield projects.