Generative ref-AI-ctoring

Generative AI is here to stay. Whether it’s completing functions, generating tests or acting as an autonomous coding agent, it has quickly become a permanent extension of the modern development environment.

With genAI, teams can produce code faster than ever before. But increased code production also introduces a new challenge. Every line of code carries maintenance costs, architectural decisions and future constraints. As delivery accelerates, technical debt can accumulate just as quickly if teams aren't equally effective at improving existing systems.

Technical debt is often described as the future cost of shortcuts, outdated assumptions or architectural decisions that no longer fit current requirements. Every team accumulates it. The challenge isn't eliminating technical debt entirely, but reducing it fast enough that it doesn't slow future delivery.

The most valuable AI use case I've found isn't generating new code. It's helping teams understand, modernize and refactor the code they already have.

By pairing AI with refactoring, we can find a way to bridge the gap between fast delivery and maintaining a healthy codebase. I think of this approach as "Ref-AI-ctoring": using AI to accelerate the investigation, planning and execution of refactoring work while engineers remain responsible for architectural decisions, validation and risk management.

And what better way to demonstrate the power of ref-AI-ctoring than with a real-world example?

AI refactoring in practice

My team recently hit a major roadblock when a critical third-party component we relied on suddenly stopped being supported by its creators. Within months, this non-maintained component began creating severe security vulnerabilities in our system. Because we couldn't easily replace or update it, our team was forced to spend hours every day manually reviewing threats, creating temporary patches and postponing our regular updates. 

We were essentially trapped in a vicious cycle of firefighting, losing time and putting our application at risk because a foundation we didn't own had cracked.

Instead of waiting for outside help that might never come, we decided to use AI as an intelligent sounding board to safely untangle ourselves. We used AI agents to analyze how our system interacted with the broken component, allowing us to validate ideas and plan a safe exit strategy in days rather than weeks. 

Specifically, the agents helped us trace dependency relationships across multiple micro frontends, identify which module federation contracts were actually being used and highlight areas where coupling was higher than expected. Tasks that would normally require days of manual code exploration were reduced to a much shorter investigation cycle.

Importantly, the agents didn't provide a complete migration plan. Instead, they accelerated our understanding of the system and helped us evaluate multiple approaches before we committed engineering effort.

By pairing human oversight with AI execution, we systematically decoupled our system from the problematic dependency without breaking existing features. In less than a month, we wiped out a year and a half of persisting risk, upgraded our systems to a completely secure state and reclaimed our time to focus on building new value.

What AI actually helped us to do:

• Trace dependency relationships faster.

• Identify hidden coupling between modules.

• Explore alternative migration approaches.

• Generate refactoring candidates.

• Validate assumptions against the codebase.

What AI didn't do:

• Define the architectural strategy.

• Understand business context.

• Assess organizational risk.

• Approve changes.

• Own the outcome.

AI as a hypothesis accelerator

AI drastically shortened the time required to investigate and test our hypothesis. What would normally have involved several days of manually tracing module federation dependencies became a much faster collaborative process between engineers and AI tools.

The hypothesis was validated through engineering judgment, testing and implementation, not because AI suggested it. AI simply reduced the cost of getting to that point.

But I would be lying if I said this took just one day of prompting with agents. Our success depended far more on domain expertise than on prompting skills. Months of experience working with micro frontends and module federation gave us the context to ask useful questions, recognize incorrect suggestions and evaluate trade-offs.

AI accelerated the process, but it didn't replace understanding. We still needed to define the problem, review proposed changes, assess risk and make architectural decisions. The responsibility remained ours throughout the entire process.

A few days ago, someone had the same problem and asked me, “Is this related?” Since we knew the cause and the solution, the response was quick: “Are you using this?” rather than “The AI did it.”

TDD as our guardrail for agents

I continuously see methods in generative AI development to provide guardrails so the AI doesn’t develop beyond what we need, and I must say, the only method we relied on was using test-driven development as our guardrail.

In many discussions about AI-assisted development, the focus is on prompt engineering, specifications or agent orchestration frameworks. Those approaches can be valuable, but we found that our existing engineering practices provided the strongest safeguards.

Tests gave us an executable definition of acceptable behaviour. As long as the test suite remained green, we could confidently allow AI to propose implementation changes while knowing that critical functionality remained intact.

In hindsight, AI worked particularly well because refactoring and TDD are naturally complementary. Refactoring changes implementation without changing behavior. We did not change the behavior the tests described, only how the code executes it.

Why refactoring is a natural fit for AI

Greenfield development requires making architectural decisions under uncertainty. Refactoring is different. In many cases, we already know the desired outcome: reduce coupling, improve readability, remove duplication, modernize dependencies or simplify a design.

Because the destination is often clearer than the path, AI can be particularly effective. Engineers define the target state while AI assists with the mechanical work required to get there.

Generative Ref-AI-ctoring

One of the hardest challenges in software engineering is balancing immediate delivery needs against long-term maintainability. Technical debt rarely appears as an urgent problem until it suddenly becomes one.

Ref-AI-ctoring changes that equation. By reducing the effort required to understand, plan and execute refactors, AI lowers the cost of paying down technical debt.

Most developers have looked at a piece of code and thought, "this could be better." Historically, that improvement was often postponed because the effort seemed difficult to justify. AI doesn't eliminate the need for engineering judgment, but it can make those improvements significantly cheaper to implement.

The result is not perfect code. The result is a codebase that evolves more continuously rather than waiting for large-scale rewrites or modernization projects.

The biggest lesson from our experience wasn't that AI could write code faster. It was that AI helped us understand existing systems faster.

For teams struggling with legacy dependencies, architectural complexity or growing technical debt, that may be the more valuable capability.

The future of AI-assisted development isn't only about generating new software. It may be equally about helping us improve, modernize and sustain the software we already have.

So the next time you encounter a piece of technical debt and think "we don't have time", consider pairing with AI. Not because it will solve the problem for you, but because it may reduce enough of the mechanical effort that solving the problem becomes worthwhile.