AI-powered development tools are no longer curiosities, they’ve become valuable tools in high-stakes software projects. But while the promise of velocity is real, without structure it can also magnify risks.
In this post, we share a real-world story of how we used AI to meet an impossible software migration deadline. It’s a case study in trade-offs: what happens when you prioritize velocity above all else, and how we later found a more sustainable balance.
Starting Point: Legacy Code, an Impossible Timeline
Picture this: a core business web application, used daily by thousands, built on outdated tech and riddled with security issues. That was our starting point.
This platform was massive: highly modular, deeply entangled, and heavily customized for each client. Migrating it to modern technologies wasn’t just a nice-to-have; it was a necessity as technical debt was increasing. Engineers initially estimated 18 months for the job, but leadership unilaterally slashed the deadline to 12 months. No justification. Just pressure.
Our team of four Kaizen developers, working alongside two third-party vendor engineers and our client’s internal product team, was asked to make it happen. From the start, it was clear: the numbers didn’t add up.
Growing Pressure and Shrinking Options
Progress was steady, but the gap between effort and scope was too big. As weeks passed, pressure grew. Everyone on the ground could see what was coming: we weren’t going to make it on time.
The challenge wasn’t just technical. Our client operates in a deeply hierarchical and bureaucratic environment. Technical realities that were obvious to us on the ground often had zero visibility to the top-level decision-makers.
So we started exploring every possible option: adding more developers to the team, or even shrinking the scope of the migration to launch an MVP faster.
It was clear something had to give, but getting that message through the layers of management was incredibly difficult. None were greenlit. We needed a new approach, and fast.
The AI Spark: From Skepticism to Experimentation
Around this time, new AI-powered code generation tools were gaining traction, like Windsurf, a fork of Visual Studio Code powered by an autonomous agent named Cascade. These tools could generate code using natural language prompts, and they could do it fast.
We saw an opportunity. Within Kaizen, our Innovation Hub—a dedicated group of engineers from various projects—had already begun experimenting with different code generation tools, including Windsurf. Their mission was to explore cutting-edge tech, drive innovation, and ultimately enhance the value we deliver to our clients.
So, we pitched it to the client. Their first reaction was a hard “no.” Security and privacy were their main concerns. They feared code exposure or leaks, and worried their data might be used to train public AI models.
To address this, our team proposed a controlled experiment using an internal, locally hosted AI model, like a “KaizenGPT.” This guaranteed no client data would ever leave our servers. It was slower than commercial models, but it built crucial trust.
After seeing positive early results (all on test projects, without using actual client code), our client began to soften. That’s when we introduced a more robust setup: Windsurf, paired with paid access to enterprise-grade models. These licensed models offered stronger privacy controls, encryption, and data usage guarantees (backed by certifications) that free versions simply don’t provide. That added layer of security and compliance made all the difference. We finally got the green light to start using AI responsibly.
The AI Boost Sprint: Speed at All Costs?
Once the use of AI in their codebase was approved, what followed was a direct, almost chaotic directive: “For two weeks, no meetings, no usual processes, just code! Use AI and push as hard as you can.”
At Kaizen, we knew cutting corners on processes wasn’t a sustainable approach. But we also saw the cold, hard truth: at that moment, velocity was the biggest threat to the entire project. We made a deliberate choice to dive into this experiment, fully aware of the risks, because we believed the potential gains were worth exploring.
This sprint became our real-world test: How much acceleration could AI truly bring to our workflow? Could those speed gains actually outweigh serious concerns about code quality, long-term maintainability, and even our team’s well-being?
And we did it. Two weeks of intense, AI-driven code generation. We saw incredible speed, yes, but it came at the cost of many things: our team’s processes, and code quality, which became poorly defined as everyone adopted AI in their own way, searching for the “optimal” method.
We made tremendous progress, but we also introduced inconsistencies in standards, code style, quality, and even team communication. Many aspects suffered in the race to move forward with AI.
But this wasn’t an AI problem; it was a project context problem. The directive was simple: speed, speed, and let’s see how far AI can take us to determine if it’s worth continuing.
The Search for Balance: Not Everything is Speed
The plan was never to keep running at unsustainable speed. Once the sprint ended, we reviewed the outcomes and pivoted back to our normal processes, with one key difference: AI was now part of them.
So the challenge shifted: how should we actually use AI in a sustainable way?
We started defining standards and best practices. Over time, we discovered how to optimize our approach, bring order to the chaos, and find the right balance between AI assistance and manual work.
