Vijay Raina stands at the intersection of enterprise SaaS architecture and strategic thought leadership. With over two decades of experience founding and selling three successful companies, he has witnessed the evolution of agile methodologies from their infancy to the current AI-dominated era. His perspective is rooted in the practical realities of shipping software that actually moves the needle for users, rather than just filling a repository with clean, yet useless, code. As a specialist in software design and architecture, Raina challenges the industry to look past the “checklist” culture and embrace a more holistic view of product success.
This conversation explores the erosion of traditional software metrics in the wake of generative AI. We delve into why the “Definition of Done” must evolve from a simple checklist of code reviews and tests into a commitment to verified customer outcomes. Raina discusses the structural failures of the assembly-line model, the staggering statistics regarding unused features, and the urgent need for engineers to reclaim ownership of the problem-solving process. By rethinking what it means to complete a task, Raina provides a roadmap for teams to survive an era where code is cheap but true value is harder than ever to deliver.
Standard definitions of “done” focus on code being reviewed, tested, and deployed, yet you argue this is failing modern products. Why has the finish line shifted so drastically?
I have spent more than 20 years shipping software across three different companies that I founded and eventually sold, and I can tell you that the traditional finish line is quietly wrecking products. We have been taught that if the code is peer-reviewed, the unit tests pass, and the feature is merged, we are successful, but this is a dangerous illusion. Pendo studied feature usage across hundreds of products and discovered that a staggering 80% of features are rarely or never used, which means the majority of our “done” work delivers zero value. I remember this vividly from my time at VinSolutions, where we built features for car dealers that we were incredibly proud of, only to find the usage data showed they were never even opened. The technical debt of an unused feature isn’t free; it is a heavy weight that creates more surface area for bugs and requires ongoing maintenance for something that doesn’t even have the decency to help a human being.
You often speak about the “assembly line” structure in software teams. How does this division of labor contribute to the current crisis in product quality?
The way we have structured modern software teams has turned them into a cold assembly line where ownership is split into pieces so small that no one sees the big picture anymore. You have a project manager scheduling, a product owner writing the ticket, a front-end dev building the screen, and a QA engineer testing it, each passing the ball to the next station like a factory worker. On this line, “done” simply means you finished your specific task and handed it off, which allows a product to fail even if every single person on the team hits their individual goals. We have created a system of order-takers where the only thing measured is movement—did the work get to the next station—rather than whether the customer’s problem actually went away. To fix this, we have to tear down these stations and put product, design, and engineering in the same room where they are forced to care about how the work actually lands with the user.
With AI now generating a massive portion of new code, how has the role of the software engineer transformed in your view?
The landscape has changed overnight; Google’s CEO recently noted that 75% of the company’s new code is AI-generated, a massive jump from just 25% two years ago. We are seeing a shift toward agentic work where the Stack Overflow 2025 survey shows 84% of developers are already using or planning to use AI tools, turning the role from a writer into a supervisor. When a machine can produce the boilerplate and the glue between systems in seconds, the part of the job we used to measure with our “definition of done” has become the cheapest part of the process. However, this cheap code isn’t necessarily correct, as Veracode found that 45% of AI-generated code contains known security flaws. This means the value of a human engineer has moved entirely to the two ends of the spectrum: deciding what is actually worth building and verifying that the final product truly solved the problem.
Transitioning from “output” to “outcome” is a significant cultural shift. What practical steps should an organization take to redefine “done” in their daily workflows?
You cannot change this culture with a simple memo; you have to physically rewrite your definition of done so the final line isn’t “deployed to production” but rather “confirmed the customer outcome.” This requires getting engineers out of their silos and putting them near the customer through support tickets, live calls, or session recordings where they can watch a real human struggle with their work. We also have to stop the sprint-to-sprint madness and build actual follow-through into the schedule, leaving room after a launch to check the dashboard and see if the fix moved a real number. Most importantly, we must stop celebrating the team that shipped 40 tickets this sprint and instead reward the one that dropped support volume or solved a persistent user pain point. In an AI-assisted world, ticket throughput is just a measure of how fast your tools can autocomplete, whereas true success is measured by the problems you’ve actually solved.
What is your forecast for the evolution of the software engineering role?
I believe we are entering an era where the distinction between a “coder” and a “product engineer” will become a matter of professional survival. Most teams will likely cling to their old definitions of done because it is comfortable to go home the moment the code merges, but those teams will continue to produce that 80% of features that nobody ever touches. The engineers who thrive will be those who embrace the “hidden work” of reading support logs and analyzing usage data to verify that their code actually changed something for the better. AI has stopped letting us pretend that writing the code was the hard part of the job; the hard part has always been understanding the human problem, and the future belongs to those who own the entire arc from the first spark of an idea to the final confirmation of a user’s success. AI will inflate the volume of things that look finished, but only human intuition and empathy can ensure that the work is truly done.
