With a career spanning the evolution from monolithic applications to microservices and now to AI-driven development, Anand Naidu has seen the very definition of his profession change. We sat down with him to explore the shifting identity of the software maker. Our conversation delves into the historical journey from the physical “operators” of early computers to the abstract logic of modern “developers.” We’ll touch on the crucial non-coding skills that define today’s professionals, debate whether development is more of an art than an engineering discipline, and look ahead to a future where humans orchestrate AI agents, redefining our roles and, inevitably, our titles once again.
The very first people we might retroactively call programmers were known as “operators,” and their work involved physically manipulating sockets and switches. Could you paint a picture of that transition from direct physical interaction to the abstract logic we use today? Beyond the invention of programming languages, what was the most critical catalyst in creating the distinct role of “programmer”?
It’s a massive conceptual leap that’s hard to fully appreciate now. You have to imagine the hum and heat of a room-sized machine, where the logic wasn’t something you typed, but something you physically built. Being an “operator” was a tactile, mechanical job. You weren’t just writing instructions; you were re-wiring the machine’s brain for every single task. The separation between the logic and the machine simply didn’t exist. The critical catalyst, aside from language itself, was the advent of the general-purpose computer. When a machine was no longer built for a single purpose, like calculating ballistic tables, but could perform any task you described to it, the role of the describer—the programmer—became essential. The focus shifted from physically configuring a machine to crafting a set of universal instructions that could make a single, versatile machine do a thousand different things.
You’ve drawn a line between the classic “programmer,” who might have written linear, task-oriented code, and the modern “developer,” who contends with a much more complex ecosystem of boundaries, modules, and versioning. Drawing from your own experiences, what are some of those non-coding skills, like those discussed in the book Coder to Developer, that truly distinguish the two?
That distinction is everything. Early programming, even when I was starting in high school, was often a solitary act. You got an assignment, you wrote a program that started at Point A and ended at Point B, you turned it in, and you were done. The modern “developer” role was born out of the chaos that ensues when dozens of those “programmers” have to make their code work together. The most critical non-coding skill is system-level thinking—the ability to zoom out from a single function and see the entire interconnected architecture. It’s about defining clean interfaces and boundaries so that your module doesn’t break someone else’s. It’s about disciplined versioning so the whole project doesn’t collapse. These aren’t coding skills; they are communication and design skills. It’s the difference between being a bricklayer and being an architect who understands how all the bricks, plumbing, and electrical systems have to fit together to make a functional building.
In the provided text, you express a personal dislike for the term “software engineering,” suggesting that development is more akin to an art. Could you elaborate on this perspective? What parts of your work feel more like sculpting than bridge-building, and how does that artistic mindset shape your approach to a project?
I’ve always felt “engineering” implies a level of scientific predictability and repetition that just doesn’t exist in creating novel software. An engineer can use established formulas to know exactly how a certain steel beam will behave under stress. I can’t tell you with that same certainty how a user will interact with an interface or how a new library will behave in a complex system. For me, the artistry is in the elegance and clarity of the solution. You can have two pieces of code that achieve the exact same function, but one is a tangled, unreadable mess, and the other is clean, intuitive, and beautiful to read. That’s art. It’s about taste, empathy for the next person who has to read your code, and a sense of balance. This mindset makes me prioritize simplicity. Instead of just asking “Does it work?” I’m constantly asking, “Is this the simplest, most elegant way to make it work?” It feels less like following a blueprint and more like shaping a raw block of stone into a finished sculpture.
You make a compelling argument that agentic AI is taking over the “clerical” aspect of writing code, much like programming languages once abstracted away the physical hardware. Looking forward, what new layers of abstraction or new responsibilities will define the next generation of software creators, and could you walk us through what their workflow might look like?
We are absolutely at the dawn of the next great abstraction. We went from manipulating the machine, to instructing the machine, to developing complex systems for the machine. The next step is to direct the intent of an intelligent system. The new responsibility isn’t writing code; it’s defining business goals with extreme clarity and orchestrating AI agents to achieve them. A future workflow might look like this: First, the human, let’s call them a “System Orchestrator,” defines a high-level goal: “Create an e-commerce platform for handmade goods that handles inventory, payments, and international shipping.” Second, they don’t write a line of code. Instead, they direct specialized AI agents: “Agent 1, design a scalable database schema for user and product data. Agent 2, build a set of secure API endpoints based on that schema. Agent 3, generate a responsive front-end that adheres to our brand’s design principles.” The Orchestrator’s core job, the third step, is integration and validation—not of the code, but of the outcome. They ensure the agents’ outputs connect seamlessly and that the final product perfectly matches the initial business intent. It’s a shift from being a builder to being a director.
What is your forecast for the future of developer titles?
Given that our titles have always evolved to reflect what we actually do—from operating a machine to programming it, to developing whole systems—it’s inevitable that a new title will emerge. The terms “developer” and “engineer” are tied to the act of building, of crafting the code itself. As AI takes over that layer, the titles will have to reflect our new role as strategists and directors. I suspect we’ll see titles like “System Architect,” “AI Orchestrator,” or maybe something more direct like “Solution Designer.” Whatever the specific word becomes, it will move away from the “how” of writing code and firmly toward the “what” and “why” of solving a problem. The title will signify a person who wields intelligent agents to achieve a vision, not someone who types out the instructions by hand.
