Managing Technical Debt with DX and AI

Every company, big and small, worries about technical debt. Gartner estimates that about 40% of infrastructure systems have this problem. In a survey of CIOs by McKinsey, nearly a third felt that over 20% of their new product budget went to resolving issues related to technical debt. But contrary to what many believe, this isn’t just a coding problem; it’s also a developer experience (DX) problem. Because when developers have to work with inadequate architecture, outdated tooling, and subpar development workflows, productivity, performance and morale suffer.

Prioritizing technical debt with the developer in mind, focusing on how they approach work, what tools they use and career advancements they can gain, helps teams focus and ship faster. This is why the way companies manage technical debt is changing, driven by DX and an increased focus on AI-powered tooling.

Championing DX

The way developers are often onboarded leaves much to be desired. It may take a couple of weeks alone for someone to start contributing to a project. Once they’ve finally been able to add small features or patches, it’s not uncommon to see the continuous integration (CI) service failing due to something completely unrelated to the changes they’ve worked on. This is basically the test suite failing due to poor quality issues, and the developer didn’t submit changes to make the test suite break. It’s a flaky, poorly written test that only works 90% of the time. The existing team is probably okay with it – it just slows down processes – but the tooling may be obsolete and demoralizing for anyone outside the organization.

This is one example of many that impede the right DX. One way to prevent this is to have a designated champion on your software engineering and development team. Many small organizations don’t have a DX leader, but large, successful ones do. These pros keep track of things like how long it takes a new developer to set up an environment. And if two weeks is too long, they figure out how to cut that time in half.

There is tooling out there to help, like CircleCI, with native features that’ll track the flakiness of a test suite. What’s needed is someone to take the lead and stop after every sprint to address some of the changes that’ll make the code easier to maintain and work with in the future. It comes down to having a leader interested in making the DX better. To make that happen, look for a senior-level engineer, accompanied by a relatively new staff member who can provide feedback on possible gaps.

Also, IDC expects the AI-powered software test automation market to continue growing at a CAGR of 31.2% until 2027, so be sure you’re harnessing this technology to the fullest.

Metrics and warning signs

There are many metrics you can track when evaluating how technical debt is impacting your team. Some basic ones are “time to fix” or “time to feature.” Let’s say you notice a bug and know how to fix it. Some tools can track time spent from code writing through production. For example, you’d be able to see a very small patch took two business days to fix and ship, when your team needs to be able to do that in hours. You can also track ratios, like the number of bug fixes versus the features completed.

There are also ways to identify when morale issues impact your team’s performance. DX leaders can run surveys quarterly to determine how happy a developer is working on a project or a piece of it. They can drill down and ask about specific areas like the CI process. And you can always track churn or turnaround in your team. If you notice that people keep leaving, they could feel as if their concerns aren’t being heard.

Tooling around with AI

The rise of AI tooling is supposed to make developers and engineers more productive and products ship faster, but technical debt slows this down. Let’s say you use a tool like GitHub or Copilot to help with code changes, then submit the pull request, and CI takes a couple of hours to get back to you. In the meantime, does a developer work on something else? Check emails? It’s a context switch and a productivity killer.

Developers want to work on products where they can just focus on code. The tooling is there to help them get it to production, not be a constant roadblock. AI can save time, but it’s up to engineering teams to define their own standards for acceptable complexity. To do this, first make sure any code that is added to your main branch has an acceptable level of technical debt. Before that, have an open discussion and get buy-in from the engineering team on the acceptable threshold of technical debt and code quality. Make sure that everyone knows that going above that mark requires immediate remediation. Once you’ve defined those standards, AI comes into play.

There is a case for AI agents with engineers acting as the orchestrators. A Capgemini survey of 1,100 executives at large enterprises has revealed that 82% plan to integrate AI agents in the next three years, and they are already impacting the future of work. You might be looking at a bug report and see it’s small enough for an AI agent to handle from inception to code review, saving your team time and freeing them up to handle more complex work. However, sometimes when we blindly follow these tools, there are trade-offs that AI struggles to consider.

That’s when a human opinion becomes the deciding factor.

Aligning technical debt with goals

How do you align technical debt reduction with goals you’re trying to achieve or measurable outcomes? It goes back to acceptable technical debt, and sometimes in business, you must ship fast. You can do so knowing a product doesn’t scale, and there may be performance issues as time passes. Often, a developer will make a note to come back to this later, when there’s time to address these issues, but it rarely happens. And when this poor culture takes over, in which you’re constantly having to ship tomorrow, the impact of the debt becomes abundantly clear.

This is understandable for a startup, but not for a business that’s been running for a decade. You need to start shifting your culture early and actively to manage technical debt; otherwise, you’ll spend a ton of money fixing production bugs or worrying about security and compliance.

Finally, there are metrics to help communicate the value of refactoring or paying down technical debt to stakeholders. Time could be one, from inception to production, or from opening a pull request to merging and shipping it to production. Another one is mean time to repair (MTTR). In this case, you may have found a bug or a broken build, and you measure how long it takes your team to fix it. You could track the number of bugs you have in production, too. If you see that number go up, there could be a problem related to technical debt.

Technical debt with interest

Every organization can dedicate a few hours every week to improve its DX to help reduce technical debt. If not, you may pay for it later, likely by slow performance, a considerable slowdown in development velocity, or security problems. For instance, your team of engineers and developers could have been postponing upgrades to Ruby on Rails for a decade. Suddenly, a project cost is increased by half a million dollars because the version of Ruby is four generations behind, leaving you with a mass of code and outdated dependencies.

If you had upgraded gradually, you wouldn’t be in this situation. So, support your software development team and pay as you go. Otherwise, that technical debt will come back to haunt you, with interest.