Prioritizing technical debt is a hard problem as modern systems might have millions of lines of code and multiple development teams — no one has a holistic overview. In addition, there's always a trade-off between improving existing code versus adding new features so we need to use our time wisely. What if we could mine the collective intelligence of all contributing programmers and start making decisions based on information from how the organization actually works with the code?

As AI accelerates the pace of coding, organizations will have a hard time keeping up; acceleration isn't useful if it's driving our projects straight into a brick wall of technical debt. This presentation explores the consequences of AI-assisted coding, weighing its potential to improve productivity against the risks of deteriorating code quality. Adam delivers a fact-based examination of the short and long-term implications of using AI assistants in software development. Drawing from extensive research analyzing over 100,000 AI-driven refactorings in real-world codebases, we scrutinize the claims made by contemporary AI tools, demonstrating that increased coding speed does not necessarily equate to true productivity. Additionally, we also look at the correctness of AI generated code, a concern for many organizations today due to the error-prone nature of current AI tools. Finally, the talk offers strategies for succeeding with AI-assisted coding. This includes introducing a set of automated guardrails that act as feedback loops, ensuring your codebase remains maintainable even after adopting AI-assisted coding.

Code quality fails to gain traction at the business level, leading software companies to prioritize new features over maintaining a healthy codebase. This trade-off results in technical debt that consumes up to 40% of developers' time, causing stress, frustration, and costly delays in product delivery. Despite its importance, it's hard to build a business case for code quality: how do we quantify and communicate the benefits to non-technical stakeholders? Or even inside our own engineering team?