As a veteran of the software industry for several decades, Vijay Raina has witnessed the tectonic shifts from manual waterfall development to the agile revolution. Today, he stands at the forefront of the enterprise SaaS landscape, guiding organizations through the most disruptive phase yet: the era of AI-driven development. With a deep background in software architecture and design, Vijay provides a unique perspective on how the role of the engineering leader must evolve when the physical act of writing code is no longer the primary constraint. In this discussion, we explore the radical transformation of engineering culture, the merging of roles between product and engineering, and the critical importance of maintaining human judgment in an increasingly automated world where code production is becoming a commodity.
The conversation covers the shifting landscape of productivity metrics where experimentation counts more than lines of code, the practicalities of rolling out advanced AI tools like Claude Code across large organizations, and the evolving skill sets required for both senior and junior talent. We also delve into how leadership tasks—from managing overwhelming Slack notifications to drafting promotion documents—are being redefined by autonomous agents.
As the cost of producing code approaches zero, how do traditional productivity metrics like pull request counts and lines of code hold up, and what should we be measuring instead?
Traditional metrics like PR counts and lines of code are still technically relevant and interesting for high-level tracking, but they are rapidly losing their status as the primary heartbeat of engineering success. We are entering a phase where the most critical metric is whether the technology we build actually generates tangible customer value. In the past, we were often forced to choose a single path due to resource constraints, but now we have the optionality to run nine, or even 900 experiments simultaneously to see which version of an experience truly resonates with the user. The real value is found in the velocity of these experiments and the speed with which we can move an idea into a production environment. When a senior engineer tells me they feel 100 times more productive because they can move through code construction so quickly, measuring them by how many lines they wrote feels almost antiquated; we should be measuring the impact of the problems they solved.
With Product Managers now merging their own PRs and roles beginning to converge, how is this shifting the traditional engineering culture and the collaborative relationship between disciplines?
This shift is creating a much more empathetic and fluid culture where the “hand-off” between design, product, and engineering is becoming a thing of the past. At Intuit, for instance, we’ve seen PMs set up tools like Claude Code and actually contribute to the codebase to get experiments out the door, which unblocks the entire team. This doesn’t mean engineers are being replaced; rather, they are being freed to focus on wholesale features and complex architecture while PMs gain a deeper understanding of operational excellence and technical constraints. It’s like the two sides of a coin coming together, where product-minded engineers and technical PMs share a unified vision for the customer journey. This blurring of lines helps everyone understand why certain things are difficult to build, leading to faster, more collaborative decision-making and a shared sense of ownership over the final product.
If generating code is no longer the main bottleneck in software development, where are you seeing the new friction points emerge in the lifecycle of a project?
The bottleneck has shifted dramatically from the construction phase to the ideation and process phases. During a recent planning exercise for a Q4 roadmap, we realized that we were thinking too small because we were still operating under the old assumption that building the software was the hardest part. The real challenge now is moving from a high-level “cool idea” to a functional production state, which requires us to retool our working relationships and hand-offs. We are finding that we might not need massive, 50-page Product Requirement Documents (PRDs) anymore; instead, we need quick sketches and real-time co-development between PMs and engineers. The process itself—the way we define “design complete” or how we iterate on requirements—is often what slows us down now, and we are constantly experimenting to find a new, more agile way to manage this increased velocity.
You mentioned that senior engineers are seeing massive productivity gains, but what does this mean for the development of junior talent who may not have the same foundational “craftsman” experience?
This is an area where I feel the industry needs to pay much more attention, because the traditional “craftsman” approach of learning from the person sitting next to you is being disrupted. I remember the “aha” moment of being a teenager in my basement tinkering with visual C++ and finally making something move on the screen, which created a deep sense of ownership and curiosity. Today, a junior developer might just accept whatever an agent outputs, which can lead to a dismissal of responsibility for the code. We have to figure out how to teach the discipline of modularity and algorithmic thinking in this new environment so that these engineers don’t just become “prompters,” but true software architects. Senior engineers are flourishing because they already know how the system works, but we must ensure junior talent still learns to break problems into smaller component parts and understands the “non-happy path” scenarios like error handling and dependency management.
In an era where we can treat code like “cattle rather than children,” how do we balance the desire for rapid rewrites with the need for long-term system integrity and modularity?
The idea of treating code as cattle—meaning we are less precious about it and willing to rebuild it frequently—is a powerful thought experiment, but it comes with significant risks. If we aren’t careful, we could end up with 12,000-line PRs that are impossible to maintain because they lack proper structure or modular interfaces. Even if an AI can generate a solution in seconds, a human still needs to ensure that the code is structured in a way that is supportable, instrumented, and performant. We still evaluate engineers on their ability to understand algorithms and how to modularize complex systems because these foundations are what prevent a codebase from turning into unmanageable “garbage” generated by an agent. While the cost of the line of code might be zero, the cost of a system failure or a non-scalable architecture remains incredibly high, making human oversight and high-judgment decisions more critical than ever.
How are you personally leveraging AI to manage the high-ambiguity tasks of engineering leadership, such as synthesizing documentation or handling employee promotions?
I try to use AI for almost every task-oriented part of my day, from summarizing the 4 million Slack messages and emails I receive to synthesizing complex technical specs. One of the most effective uses I’ve found is creating dedicated projects in tools like Anthropic or OpenAI for specific tasks, such as drafting employee promotion documents. I can feed the agent an employee’s code, their documentation, and their project history, and have it help me summarize their impact, though I always maintain a “human in the loop” to ensure the final doc reflects my actual voice and judgment. I also use it for competitive research, essentially chatting with the model to understand how a new technology or customer use case relates to other offerings in the market. It’s a significantly better way to aggregate unstructured data and make sense of it quickly, allowing me to focus on the high-level strategy rather than the grunt work of data synthesis.
What is your forecast for the role of engineering managers as we move toward a future populated by autonomous coding agents?
My forecast is that engineering leadership will transition into a role that looks much more like “managing the manager” of various autonomous agents. We are already seeing the emergence of agents that can identify bugs, fix them, and run self-improving loops, but these agents can easily wander into “crazy land” if they aren’t properly guided. We will likely see the rise of adversarial agents whose entire job is to monitor and check the work of our coding agents to ensure they are still adhering to the desired fitness functions. Leaders will need to be adept at managing these complex agent relationships and identifying when an agent’s output is no longer helping the end goal. Ultimately, we are moving away from a world of predictable “spec-to-code” workflows and into a high-ambiguity environment where the ability to orchestrate these powerful tools will be the defining skill of a successful engineering manager.
Do you have any advice for our readers?
The most important thing to remember is that while the tools have become incredibly robust in the last four to five months, solving customer problems is still the heart of the job. Don’t be intimidated by the languages or the syntax, as those are often “hokey” and will continue to evolve; focus instead on being a strong owner and staying customer-obsessed. Be the person who dives deep into problems and unblocks themselves regardless of the toolset, because the “how” of your work—your empathy and judgment—is what will differentiate you in an AI-first industry. Stay curious and keep that experimental mindset, because the moment you feel unshackled from the constraints of how software “used to be built” is the moment you can start delivering truly massive value.
