Anand Naidu brings a wealth of seasoned experience to the table, having navigated the turbulent waters of software development through multiple eras of transformation. From the early days of procedural logic to the complex, AI-driven workflows of today, he has witnessed how tools change while the underlying craftsmanship remains remarkably consistent. With over 40 years of coding experience and 26 years as a professional in the field, Naidu has seen everything from the rise of Java in the late 90s to the current explosion of low-code platforms. Today, we explore how these decades of evolution inform his perspective on the rise of Large Language Models and why the fundamentals of engineering are more critical now than they have ever been.
The conversation covers the historical transition of programming paradigms, the reality of AI as an amplifier of existing habits, and the essential technical skills that artificial intelligence cannot replicate. We delve into the necessity of maintaining rigorous feedback loops, the importance of precision in technical communication, and the hidden dangers of “outsourcing” the learning process to automated agents.
Programming paradigms have evolved significantly over the decades, moving from basic procedural logic to complex AI-assisted environments. How have you seen the core responsibilities of a developer shift as we’ve moved from BASIC and GOTO statements to this new era of augmentation?
In my 40 years of coding, I have seen a few major paradigm shifts, starting in the wild world of BASIC where GOTO statements were everywhere, before moving into the more structured, Dijkstra-inspired world of Pascal and C. When I reached university, the shift moved toward object-oriented programming with C++, and by the late 90s, Java was the dominant language for my honors degree year. Throughout my professional career, I have watched the rise and eventual death of rapid application development tools like VB6, Delphi, and Oracle Forms, as well as the explosion of web and mobile tech. Despite these massive shifts, the central skills a developer needs to be effective have not changed; if anything, the fundamentals have only become more important as we build ever-more complex software. AI is arguably the biggest shift since third-generation languages, but it remains a tool in the belt—a petrol-powered chainsaw compared to the hand-axes of the past—while the core activity of managing complexity and making design trade-offs remains the human’s primary burden.
There is a common belief that AI will automatically make every developer more productive, but you’ve often described it as an amplifier rather than a cure-all. What actually happens when a team that is already struggling with quality starts relying heavily on LLMs?
The reality is that AI is an amplifier, which means it accentuates what you are already capable of doing rather than fixing your underlying flaws. If your team is currently producing buggy code, giving them AI tooling without proper training will simply result in them producing a higher volume of buggy code at a faster rate. We see this in studies of 150 developers using AI: if a team has too much work in progress (WIP) and nothing is actually reaching the production stage, AI is likely to increase the amount of unfinished work, and as we know, a multiple of nothing is still nothing. However, for an effective team that is already producing high-quality output and deploying continuously, AI can multiply that success and streamline the tedious parts of the workflow. You have to be careful, because if you don’t wield these tools with a critical eye, they can drive you toward more dangerous practices that feel efficient in the moment but create long-term technical debt.
In an era where we can describe what we want in plain English to an AI, why is it still essential for developers to master technical jargon and specific architectural patterns?
Precision in communication is the bridge between a vague idea and a working feature, and this becomes even more essential when you are interacting with an LLM. You need to know the visceral difference between parameters and arguments, or the specific nuances between spies, mocks, and fakes, to guide the AI toward the correct technical outcome. If you can’t articulate whether you need a strategy pattern, a decorator, or a builder pattern, the AI might hallucinate a solution that looks elegant on the surface but fails to handle the actual real-world constraints of the project. These technical terms are part of the “tool-belt” that allows us to give and receive feedback to and from stakeholders, ensuring the mental model of the domain remains accurate. Without that precision, you are essentially speaking a different language than the tool you are trying to use, which leads to a frustrating loop of trial and error that burns through both time and tokens.
How does the integration of Large Language Models change the way we handle feedback loops and the traditional practice of checking our work during the development process?
One of the most fundamental practices in software development is checking your work end-to-end as often as possible, but LLMs have a tendency to apply giant change-sets and “hope for the best.” This can feel like a win when it works, but when it goes wrong, it burns an incredible amount of time and mental energy to backtrack and find the error. To counter this, techniques like automated tests, tiny commits, and continuous integration/continuous deployment (CI/CD) have become even more essential than they were 20 years ago. You have to develop a muscle for critical thinking, looking at AI-generated output and smelling the subtle issues that suggest it is on the wrong track. The LLM doesn’t have a curious mind and it doesn’t love learning; it is just responding to your questions, so the burden of creating a tight “read-evaluate-print” loop falls entirely on the human engineer to prevent the system from spiraling out of control.
You’ve cautioned that “outsourcing the doing” can be detrimental to a developer’s long-term career growth. What impact does a heavy reliance on AI have on the interview process and the way we evaluate experience?
There is a real danger that AI use in the day-to-day coding work can limit learning because, ultimately, doing the thing is how we internalize knowledge. I have conducted far too many interviews recently where an “experienced” developer cannot explain a single line of code they submitted as their own, which is a massive red flag for any employer. While companies certainly want high output, they also need to know that you conceptually understand what you are producing so you can fix it when things break at 3:00 AM. If you outsource the “doing” entirely, you lose the ability to parse and evaluate the code, which is a coder’s true superpower since code is read much more often than it is written. If you aren’t careful, your next job interview will be a challenge because you’ve lost the “muscle” required to think through a problem without a prompt box to guide you.
Beyond the code editor, you mentioned that the command line and deep reading skills are often overlooked. Why are these specific areas becoming more relevant in an AI-driven environment?
It is a bit of a tragedy that the command line is still ignored in many modern tech curricula, because shells are the fundamental way we harness compute power and are at the core of what every coding agent is doing. When you use an AI extensively in your workflow, you actually end up writing code a little less and spending more time reading, critiquing, and evaluating trade-offs. This requires a high level of “code parsing,” which is the ability to conceptually understand the logic you are looking at almost instantly. Because LLMs often produce more complex code than a human might write naturally, your reading skills have to be sharper than ever just to keep up with the volume of output. If you can’t navigate a shell or quickly digest a 50-line logic block, you will find yourself falling behind, not because you lack AI tools, but because you lack the fundamental literacy to manage them.
What is your forecast for the future of the software engineering role as AI becomes standard in every development house?
I believe we are entering an era where the “coder” role will split into those who simply prompt and those who truly engineer, with the latter becoming more valuable than ever. We will see a shift where developers spend 80% of their time on trade-off evaluation and architectural critiquing rather than syntax, but this will only be possible for those who have mastered the basics. My forecast is that the industry will eventually see a “correction” where the ability to work without AI—to hand-code and understand the underlying compute power—will be the primary differentiator in high-stakes engineering roles. We might be able to prompt a solution into existence, but if we cannot parse, understand, and evaluate what comes out of the machine, we aren’t really developing software anymore; we are just supervising it. The most successful developers of the next decade will be those who use AI to amplify their high-quality standards rather than those who use it as a crutch to bypass the hard work of learning.
