Enterprises today are balancing two major pressures: delivering business value faster and managing sprawling, aging codebases that constantly demand attention. Addressing technical debt is a critical part of ensuring high quality, secure, and maintainable code, but it often comes at the cost of shipping features.
At Code Remix Summit, Moderne VP Rooz Mohazzabi moderated a panel of engineering leaders, with voices from Airbnb, JPMorgan Chase, Moderne, Morgan Stanley, and SAP, as they opened up about how they’re approaching these challenges at scale, and where automation, AI, and cultural change are making the biggest difference.
Watch the full panel video here, and read on below to catch the highlights:
Developers are drowning in maintenance
Why is Apache Struts still alive!? For too many developers, there is just not enough time in the day. Research shared during the panel suggests only about 20% of developer time goes to writing new code. Roughly 40% is spent on maintenance, with 25% of that consumed by refactoring alone.
Szczepan Faber, Head of Developer Experience at Airbnb, pointed out that even with this level of investment in refactoring, it’s still not nearly enough: “Developers spend too much time on refactoring… and not enough of it is getting done.”
Panelists highlighted a long list of culprits behind this never-ending rework:
- Duplicate logic and low test coverage
- Manual processes ripe for automation
- Performance tuning and reliability gaps
- And most significantly, constant upgrades and dependency migrations
Jonathan Schneider, CEO and co-founder of Moderne, noted a shift in what teams consider “technical debt.” Originally, it referred to shortcuts teams took knowingly. Increasingly, though, developers are inheriting tech debt through aging dependencies and third-party libraries. This kind of work would more accurately be labeled as maintenance.
Whatever you call it, the result is the same: degraded velocity, lower developer productivity, and constant context switching that slows down everything. If this is you, you’re not alone.
AI can help, but it’s not hands-free
With stats from GitHub showing that 90% of developers now use AI tools, and Microsoft estimating that 30% of code is AI-generated, it’s natural to ask: is AI helping?
The answer so far: sort of. AI is clearly accelerating output, but the downstream costs are real. How much time are teams spending reviewing, rewriting, or debugging what AI produces?
Klaus Haeuptle, Distinguished Engineer at SAP, emphasized the need for clear accountability. AI might be doing more of the typing, but engineers are still responsible for the outcome—and the code still has to pass the same compliance gates as anything written by hand. It’s ultimately a human who is accountable and there must be the same rigor and controls applied.
“The most important thing you can do is invest in building up skilled software engineers who take ownership and have skin in the game.” –Klaus Haeuptle
For engineering organizations in financial institutions or other environments with regulatory requirements, this is absolutely vital for compliance. Dov Katz, Managing Director and Distinguished Engineer at Morgan Stanley, offered a fitting analogy: using AI for testing is more like riding an e-bike than a self-driving car. It helps you pedal faster, but you still have to steer. AI might accelerate test generation, but engineers still need to ensure testability and correctness.
Rather than turning AI loose to rewrite code, many leaders see greater promise in using it to guide modernization. Paired with deterministic refactoring tools like OpenRewrite, AI can:
- Identify potential modernization opportunities for refactoring
- Recommend vetted, safe transformations such as OpenRewrite recipes
- Execute the suggested recipes across a codebase
- Retrieve data from the run and summarize it for the developers
It’s a more effective and scalable approach: let AI leverage deterministic tools to gather insights about codebases and then guide the user through automated, accurate fixes using those tools.
The hardest part is organizational, not technical
Even the most effective automation faces friction, often from within. Developers can be hesitant to accept changes from outside their teams, even when those changes are clearly beneficial.
Robert Miles, Global CTO at JPMorgan Chase, emphasized the importance of ownership. Developers need to feel like they own the changes. For smaller, safer updates, leadership might push changes centrally. But for larger transformations, the most successful approach enables teams to pull in changes themselves, on their timeline and within their risk tolerance.
“Thinking about the kinds of changes differently, and grouping them into different scenarios is really powerful. [Updating a] shared library, version bumping, firmwide mandated changes—those are all different. There’s value for the individual development teams because they don’t have to figure out what to do to be compliant and they know there’s force behind it from the organization. But making sure that the developers own it is absolutely critical.” –Robert Miles
To support that, organizations are finding creative ways to motivate action. At Morgan Stanley, Katz described the use of a “technical fitness score,” which assigns a sort of dependency freshness to help teams visualize the risk that has accumulated by not addressing necessary remediations. When developers can see how their code stacks up and how inaction adds risk, they are more likely to prioritize the work.
Scaling software means scaling modernization
Keeping a large codebase healthy isn’t a side project, it’s a full-time investment. As organizations modernize, they’re learning that automation isn’t just helpful, it’s essential. But for it to succeed, it has to be adopted. That takes trust, clarity, and cultural support.
Panelists agreed on a few key themes:
- Technical debt is unavoidable, but it can be managed strategically
- AI works best at scale when paired with predictable, auditable refactoring tools
- Developer ownership and thoughtful incentives are critical to scaling change
In short: teams that treat modernization as core to their software strategy—not a background task—are in a better position to move fast while staying secure and resilient, even as their codebase grows.
Learn more about modernizing on your own terms with a Moderne demo.
