How are you balancing tech debt vs. velocity with AI-assisted coding?
We're an AI-native startup shipping fast with augmented coding, but the debt it creates is different from anything I've seen before.
I remember in my old team we put aside around ~20% of engineering time to pay down debt that accumulated during feature releases.
We're deliberately using AI to go deeper, our test-coverage is through the roof but there are still things that slip through the cracks and they are hard to catch. At times parts of our codebase feel like a city where every building is fine on its own but nobody really planned the streets and too many windows are custom-built.
A few things we've landed on:
Set aside time each week to specifically work on paying down tech-debt and refactoring.
Leverage AI to go deeper when tech-debt surfaces. This starts usually with an audit for a specific topic and then branches into more thorough sub-plans.
Acceptance. I'm banking on the number of feature improvements to outweigh the problems a mountain of debt will create. I guess this is the closest to the honest trade-off great product and tech divisions have done for many years before the advent of coding agents.
Focus on reliability and observability. Not all tech-debt is equal but we are keeping a close eye on the most critical paths with additional infra to monitor for that.
What tradeoffs are you making, and what's working for you? Especially curious about teams that are heavily AI-assisted in their development workflow.
Replies
The speed is incredible, but AI-native tech debt hits differently. We've started forcing a 'no new features' rule for one day a week just to let our terminal agents refactor and clean up the spaghetti code.
@rileydawn299590 Love this: This type of rigor will go a long way.
memoiri
What I love about vibecoding or using AI in generall is to speed in everything. And because of that I don't hesitate to refactor a lot. Do you remmeber the times when you did't want to touch a feature because of technical debt? This, at least for me is something of the past. I Just rewrite it. Often it is faster to completly rewrite from scratch than to look for a bugfix
@mohammad_elzahaby Fair point and yes, I believe continuous refactoring tilts the equation here. Same can be said about error resolution. As long as instrumentation is in place to catch issues quickly one could say the trade-off of moving fast vs. maintaining edge-case free reliable systems changes.
memoiri
@andreas_rubin_schwarz What I also noticed is that sometimes you have to hint the AI to the right direction using quality Code, Documentation or even a simple blog post explaining the solution. This has helped me in a lot of cases where the AI didn't manage to come up with a meaningful solution
@mohammad_elzahaby Combined with a thorough recon step and a bit of agent-to-agent Q&A this appears to be the golden bullet that makes the difference
As a non-technical founder building an agency, this resonates heavily. AI lets us ship customer-facing features incredibly fast, but if the 'streets' connecting everything aren't mapped out right, the product feels disjointed. Treating the team as strict architecture reviewers rather than just writers has been our saving grace.
@evanholloway43 Nice! I feel like augmented coding enables also a new set of QAs. Product Managers, Marketing, customer success, ... the CEO. Transitioning an observation into natural language and by virtue of coding agents into code or a ticket, has never been easier. We're seeing quite a bit of gains through traditional non-technical team members getting their reps in with coding agents.
As a non-technical co-founder, I care less about “zero tech debt” and more about being explicit on where debt is allowed. Messy implementation behind experiments? Fine. Debt around onboarding, payments, permissions, data integrity, or core user flows? Not fine.
The key tradeoff for me is using AI for speed and audits, but keeping humans responsible for architecture, judgment, and deciding what must not break.