Anand Naidu is a seasoned veteran of the data infrastructure world, having spent over a decade navigating the volatile waters of backend engineering and complex database architecture. Known for his ability to translate high-level business logic into resilient code, Naidu has seen the industry move from manual scripting to the brink of full autonomy. His perspective is deeply rooted in the practical realities of the “3:00 AM stack trace,” and he currently focuses on how large language models are fundamentally restructuring the way we interact with data warehouses. In this conversation, we explore the recent leap in machine-generated SQL, the mechanical nature of data maintenance, and the looming infrastructure shifts required to support the next generation of agentic intelligence.
In this discussion, we delve into the evolving role of agents within the data stack, highlighting how the recent surge in SQL proficiency is shifting the focus from manual querying to strategic oversight. We examine the critical distinction between “boring” mechanical maintenance—such as patching schema drifts and fixing broken joins—and the more complex, human-centric task of defining business context that cannot be inferred by code alone. Furthermore, we address the technical hurdles of automated insights, the necessity of low-latency infrastructure, and the specific steps data teams must take to prepare for an environment where agents fan out into a flood of parallel queries.
Large language models have only recently reached a high level of proficiency in writing SQL. How does this shift the daily responsibilities of a data engineer who is used to manual query construction?
It is quite remarkable to realize that LLMs only became reliably good at writing SQL about six or nine months ago, which in the grand timeline of data engineering feels like a sudden, seismic shift. For years, the engineer was the bottleneck, the person who had to meticulously hand-craft every join and ensure every syntax detail was perfect to avoid a total system failure. Now, the role is evolving into something closer to an architect or an editor who manages the “vibe” and the governance of the code rather than the keystrokes. You’re no longer just a builder; you’re the one setting the guardrails so that the agent doesn’t accidentally trigger a Cartesian explosion that eats up your entire cloud budget. It allows us to move away from the repetitive, syntax-heavy labor and focus on the structural integrity of the entire data lakehouse.
You’ve mentioned that data engineering is often a struggle against systems we don’t control. How can agents alleviate the stress of unpredictable schema changes or API updates?
Data engineering is fundamentally hard because you are constantly at the mercy of external systems that change without a moment’s notice. It’s a stomach-dropping feeling when a column that always held integers suddenly starts returning decimals, or when an API ships a new version and your entire pipeline goes offline. An agent thrives in this unglamorous maintenance work because it can read the underlying assumptions of your code—like “this field is unique” or “these tables join cleanly”—and turn them into active tests. Instead of a human waking up to a 3:00 AM stack trace, the agent can do the legwork of tracing what changed and proposing a fix before the problem cascades. It turns a reactive, high-stress environment into a more mechanical, manageable process where the “boring” work is handled autonomously.
There is a lot of talk about “context” in data modeling. Why is it so difficult for an agent to figure out business logic, like how to calculate revenue, on its own?
The context landscape is honestly a bit of a mess right now, with different vendors trying to convince us that their specific semantic modeling language, whether it’s MetricFlow or Malloy, is the only solution. The reality is that an agent is fantastic at mechanical inference—it can see which tables join to which and what values a column usually holds—but it cannot “discover” a business decision. Decisions like when the fiscal year starts or exactly what qualifies a user as a “customer” aren’t hidden facts waiting to be found in a warehouse; they are human choices. If those choices aren’t explicitly documented in a way the agent can use, the agent will eventually drift away from the business reality. The challenge for us is to keep that hand-written documentation from drifting while using agents to flag the exact moment our data starts contradicting our business logic.
Automated insights are often pitched as the “holy grail” of data agents. Why do you believe we are still in the “fantasy” stage for this specific application?
The idea that an agent will just watch your data and drop a perfectly tailored dashboard in your lap whenever something interesting happens is a beautiful vision, but the bar for relevance is incredibly high. We’ve seen this problem before with deterministic alerting systems where people end up turning off the alarms because they are just too hard to tune and produce too much noise. If a human, who understands the company’s nuances, has a hard time writing a trigger that doesn’t result in a false positive, an agent will struggle even more until we reach a much higher level of intelligence. Right now, automated insights are more of a research prototype because a single irrelevant “insight” can cause a human user to lose complete confidence in the system. We need to focus on the plumbing and the reliability of the data before we can trust an agent to tell us what matters.
How does the behavior of an agent differ from a human user when it comes to the load it places on a database infrastructure?
A human user is predictable; they think, they type, they wait for a result, and then they think some more, which gives the system plenty of breathing room. An agent, however, can go from zero to a massive flood of queries in a heartbeat, fanning out to chase several different threads of logic simultaneously. This requires infrastructure that can scale up and back down with incredible speed, as well as strict tenant isolation to ensure one agent’s “curiosity” doesn’t take down the entire system for everyone else. We have to build engines that aren’t just tuned for human patience but are capable of absorbing these sudden, massive bursts of parallel agent activity. If your infrastructure isn’t ready for that kind of throughput, the arrival of agents will feel less like a productivity boost and more like a distributed denial-of-service attack.
You emphasize that latency is a bigger deal than most people realize. Can you explain why the difference between 10 milliseconds and 100 milliseconds is so critical for an agentic workflow?
When a person is using a tool, the difference between 10 milliseconds and 100 milliseconds is almost imperceptible because both feel nearly instantaneous to our slow human brains. But for an agent, which doesn’t need to stop and think, that 10x gap in response time compounds directly into the agent being ten times less productive. If an agent is running a complex chain of tasks where each step depends on the result of the previous query, those tiny delays add up until the entire process feels sluggish and inefficient. As LLMs themselves get faster through smaller models or better GPUs, the database tools they use will become the primary bottleneck. We are moving toward a world where the speed of the underlying engine determines the actual “intelligence” and utility of the agent.
What is your forecast for the role of the data engineer over the next three years as these agents become more integrated into the stack?
I forecast that the next three years will see the “agentic wave” move from experimental curiosity to the standard operating procedure for any high-performing data team. We will see a massive shift where the “forward-deployed engineer” spends less time fixing broken pipelines and more time designing the “evals” and semantic layers that keep agents on track. The teams that start preparing now by cleaning up their context and moving to low-latency, scalable infrastructure will be the ones who define the patterns the rest of the industry eventually copies. We are essentially moving toward a state of “governed autonomy,” where the heavy lifting of data plumbing is invisible, and the human’s primary job is to ensure the agent’s logic remains aligned with the shifting goals of the business. It will be an era where the speed of insight is limited only by the speed of our infrastructure, not the speed of our typing.
