Vijay Raina has spent more than 20 years shipping software, witnessing firsthand the rise and fall of countless technical trends. As an expert in enterprise SaaS technology and software architecture, he has transitioned from manual coding to a role where he spends much of his time overseeing AI coding agents as they generate complex applications. His perspective is rooted in a deep understanding of how predictability serves both human developers and modern machine learning models. We discuss the shifting landscape of development, the hidden costs of flexible stacks, and why “boring” technology is becoming the ultimate competitive advantage in the age of artificial intelligence.
The conversation explores how the traditional desire for flexibility in software engineering often conflicts with the needs of AI agents that rely on pattern matching and context windows. We examine the specific advantages of convention-driven frameworks like Laravel and Rails, contrast them with bespoke Node.js services, and debunk common myths regarding the performance and relevance of PHP in today’s ecosystem. Furthermore, we address the strategic dangers of resume-driven development and the “rewrite reflex” that often leads to stalled roadmaps and technical debt.
Many modern engineering teams favor flexible stacks like Node where structure is a per-team decision, but you suggest this flexibility is actually detrimental to AI-assisted development. Why does a “bespoke” approach hinder the tools we are now relying on for speed?
A coding agent is essentially a high-speed pattern matcher operating within a specific context window, and its efficiency depends entirely on how well your codebase aligns with the millions of examples it was trained on. When you use a bespoke Node service, you are essentially asking the AI to learn a private language that exists only within your company. One team might decide to put routes in a dedicated folder, while another co-locates them with handlers or invents a unique domain-layout from a random blog post. This lack of a canonical structure means the agent burns its computational effort trying to infer your project’s private conventions rather than actually writing the feature. It has to guess where controllers, services, and middleware live, which often leads to different outputs for the same prompt across two different runs. By prioritizing total flexibility, you are poisoning the very environment the AI needs to be productive, forcing it to rebuild context that a more standardized layout would have provided for free.
You’ve highlighted “Convention over Configuration” as a hidden AI strategy. How does a framework like Laravel or Rails specifically improve the quality of code generated by an AI agent compared to more “modern” alternatives?
If you open any Laravel project anywhere in the world, you already know the exact directory structure: models are in app/Models, controllers are in app/Http/Controllers, and migrations always follow a predictable, timestamped naming convention. Because these frameworks have spent two decades enforcing global standards, a language model has effectively seen your specific project layout a million times before it ever touches your repo. The code it generates is idiomatic and lands in the correct directory because the structure it is predicting is a universal standard, not a local invention. This predictability means that the AI doesn’t have to “improvise” or guess where a new controller should go; it simply follows the pattern it was trained on. Laravel has even leaned into this by shipping official AI-assisted development docs and a tool called Boost that feeds the framework’s own conventions directly to the agent, drastically raising the payoff for being predictable.
When you built your latest product, ProductWave, you chose PHP and Laravel over more “fashionable” stacks. How did that decision play out once you integrated AI agents into the development workflow?
The bet on Laravel for ProductWave was driven by a desire to escape the “JavaScript churn” and the constant re-platforming that comes with a new framework appearing every nine months. We wanted a stack that was opinionated in the right places, providing authentication, queues, an ORM, and scheduling on day one so we could stop arguing about tooling and start shipping. The real surprise was how much harder this bet paid off when we started using AI agents. Because the conventions are so consistent, the agents we use write noticeably better code in our Laravel apps than they do in any hand-rolled Node service. In the Node services, every team has invented their own layout, but in our Laravel apps, the same file goes in the same place every single time. This consistency results in output that holds up across multiple runs and feels like it was written by a senior developer who knows the framework inside and out, rather than a machine trying to figure out a puzzle.
PHP is often dismissed as a “dead” or “slow” language from a previous era of the web. What technical advancements have changed that reality, and what do the actual performance numbers look like for a modern enterprise?
The common critique that PHP is stuck in 2010 is usually based on experiences with version 5.6, which is more than a decade out of date. Modern PHP 8 is a completely different beast, featuring a JIT compiler, a robust type system with union types, readonly properties, enums, and even Fibers for asynchronous programming. When companies like Tumblr migrated their massive fleets from PHP 5 to PHP 7, they documented their latency dropping by half and their CPU load falling by at least 50 percent, and the performance has only continued to climb with PHP 8. Today, PHP still powers roughly three-quarters of all websites with a known server-side language and handles production traffic at the massive scale of companies like Etsy and Slack. It is a language that is “unfashionable” on certain social media platforms, but it is incredibly effective and performant in the real world where businesses need to scale.
We often see engineers pushing for a full rewrite of working systems because the current stack feels “outdated.” Why do you believe this “rewrite reflex” is so dangerous for a company’s roadmap?
The argument for a rewrite is almost always framed as a technical necessity, but in reality, it is often a symptom of resume-driven development where engineers want to work with the trendiest stack to improve their future job prospects. This is rational for the individual but can be a complete disaster for the company’s roadmap and bottom line. Every time I have seen a team approve a massive rewrite, they spend the better part of two years rebuilding functionality that already worked, shipping absolutely nothing new to customers in the meantime. While they are busy changing the syntax of their backend, their competitors are eating their lunch by actually releasing features that solve customer problems. In the AI era, this is even more costly because you are trading a legible, convention-driven app for a bespoke service that is actually harder for AI tooling to understand, effectively spending years of your life to make your own agents worse at their jobs.
If a leadership team is currently managing a “bespoke” stack and wants to improve their AI-assisted velocity without a full rewrite, what practical steps should they take to modernize their approach?
The core principle here is about convention, not just a specific language, so the first step is to stop treating “boring” as an insult and start seeing it as a competitive advantage. If you are stuck in a flexible stack like Node, you must impose convention manually: pick a canonical layout, document it thoroughly, and use linting tools to ensure it remains identical across every service you build. Most of the gap in AI quality closes the moment the directory layout stops being a per-team decision and becomes a company-wide standard. For those on older versions of frameworks like PHP or Rails, the smartest move is to modernize the app you have by upgrading it and adopting its conventions fully. You will get significantly more out of your AI agents by working within a current, consistent codebase than you will by jumping to a brand-new language that carries massive transition risks and high costs.
What is your forecast for the future of software development frameworks as AI agents become the primary authors of our codebases?
I believe we are entering an era where the most successful frameworks will be those that prioritize machine legibility over human flexibility. For the last fifteen years, people complained that frameworks like Laravel made too many decisions for the developer, but that very trait is now their greatest strength because it provides a predictable surface for AI to generate against. In the near future, the “assembly” style of building software—where you manually stitch together twenty different libraries to make a bespoke stack—will become a luxury that teams simply can’t afford. We will see a massive shift back toward highly opinionated, “all-in-one” frameworks because they allow AI agents to work at peak efficiency from day one. Predictable code means staffable projects and legible systems, and in an AI-driven market, the teams that embrace these “boring” conventions will be the ones that outpace their competitors by orders of magnitude.
