Sitemap

Beyond the Hype: The Struggle for System Clarity

11 min readApr 28, 2026

--

I am lucky that I have had a chance to visit Google Cloud Next for a few years now. This year’s event, as always, was bigger than before. At the end of every event, I prefer to sit down quietly and assess what just happened at the three days and what the current scene is with developers.

What credentials do I have? No fancy titles or viral threads. Just 30 years of building systems and surviving enough tech cycles to know when the new is just old problems in a fancy suit.

Let’s start with a summary and what I felt speaking with 10s of developers (the statisticians among you might mock the sample size) and it is this … “there was a palpable sense of unease and confusion among developers/engineers , who actually have to keep systems running.” These are folks who are currently busy running systems at scale, have been told to adopt all the new agentic ways of doing things and are just struggling to keep up and get a clear sense of direction. The #1 thing in my book that they are concerned about what can be classified as “human comprehension” of where things are going.

Let’s dive in.

Press enter or click to view image in full size

The Good Parts

We are entering an era, some might even say that it is in the past, where the barrier to generating code has dropped to zero. I simply love the fact that more of us (not just developers) are now having access to tools that translate their thoughts into impressive looking applications. As they say, “Its an amazing time to be alive”. I subscribe to that fully. Yes, there will be folks arguing that these are just use and throw applications, no one really takes this to production and many other reasons. Fair enough, we all understand that.

If You Didn’t Build It, You Can’t Fix It

What is more of interest to me is that the cost of understanding that code is higher than ever. As the pace of new frameworks and AI-driven tools accelerates, what is being sacrificed or which we are not able to devote enough time and which is the single most thing that makes a system resilient: human comprehension.

Let’s step back. I think the agents will win the game anyways. With the kind of models, compute and corpus available, its going to be a no contest here. I also feel that even if you didn’t build the system, the agents will get so good that they might be able to autonomously fix/maintain and keep the systems running for you too. A bug appears, the agent swoops down upon it, they mitigate and fix it eventually. What more can we ask for? I meant that with all sincerity.

But here is the real question: How much of that system do you actually understand?

You are staring at thousands of lines of logic that you didn’t architect, trying to understand trade-offs you never made. If we outsource our thinking to agents, we lose the mental model required to do something when things go wrong. That’s a reality we have to accept.

As we go along this path, vendors will comfort us that Human in the Loop is important and that they have enough guardrails to ensure that human intervention is needed to move forward. They have built that into their systems. Wonderful … but I am a bit skeptical towards this view point, even from my own company, because if I don’t understand the system properly, I will have serious limitations in trying to confirm anything. This might be manageable at the moment because we are in early days but as thousands and thousands of lines of code are generated, you are in for a solid struggle.

I have had folks argue with me over the fact that for years, we have had applications built on top of Operating Systems that we knew nothing about , except for a fact that they worked. That’s a false equivalence. We might not have understood every line of the Linux kernel, but the kernel never decided to hallucinate a new file system because it was popular in its training data. One is a black box of logic, the other is a black box of probability.

You Must Question “It works”

What did we notice across all the demos? They are “Happy Path” demos usually and why not. You’ve got 2–3 minutes to show a demo and you want me to show you an edge case? However, as developers, we know that it is where the work really starts.

Let’s take one simple example that you would have come across in recent times.

  • An agent might solve a simple UI requirement by pulling in a massive, complex state-management library because it’s popular in its training data. It works, but now your simple internal tool has a dependency graph 10s of layers deep. When a security vulnerability (CVE) is announced in one of those sub-dependencies, you have to untangle this mess. Maybe you outsource that cleanup to an Agent too?

In these cases, the agent did its job. It produced code that passed a test. But because the human in the loop was rushing to keep pace with the next big thing, they didn’t have the time to ask: Is this the simplest way to solve this?

Let me stress on that last part a bit. I am too old now to get excited with a new design pattern, a new Agent skill, multi-agents doing their work autonomously, a new framework, etc. Every single time, when I look at what the vendor is proposing (and that includes my employer, Google Cloud), I always ask myself is this the simplest way to solve this? In my 30+ years, systems kept simple from all its requirements and interfaces, have performed the best, both commercially and technically.

A file processing CRON Job that ran regularly in a sequential fashion to clean up data that vendors submitted, was enough to meet the volume requirements and earned a company that I worked and designed this for, a few million $ of revenue per year, almost 20+ years back. Sure, this is a random stray case and you would violently react on seeing the Java code behind it but I am sure you get the point.

Influencers vs. Practitioners

We need to talk about the credentials of the people leading this charge. It’s an easy group to bash, but let’s be pragmatic: right now, the loudest voices in the room are often marketers and influencers. That is their job, to sell a vision. But we have to remember that building a viral demo is not the same as maintaining a system.

A demo is a controlled environment. It doesn’t have to answer for multiple things like:

  • Backwards Compatibility: Will this agentic layer break the legacy APIs holding your company together?
  • Data Integrity: What happens when an agent hallucinates a database write across distributed nodes?
  • Long-term Maintainability: Who owns the code when the vibe that created it disappears?
  • The 3 AM On-Call: When the reasoning loop fails at midnight, can a human actually untangle the logic in time to fix it?

I’d love to see the scars on the people throwing these new Agent Skills at us daily. If you get a chance, ask them how they handled a race condition in code their agent generated. Ask them how they audited the security of the fifteen new sub-libraries the agent imported just to solve a UI ticket. If they can’t answer, they are selling you a map to a place they’ve never actually visited.

I won’t even start on the fiction writing happening on popular networking sites. 50,000 stars and 1,000 emojis are impressive but what do they really mean? Does it mean production grade quality? I’m happy to let the marketing forces have their reach, but I refuse to let them run away with the narrative of what is real work and most importantly, within in my context. You often hear them saying “Context is King”. It is, but you need to tell them your unique context and ask for solutions vis-a-vis that.

This gets me back to my theme. Prefer to pause, to evaluate, to wait and then lead with a bit of circumspection, especially when a lot of things are at stake, including your career.

The Overlap and Understanding Dilemma

At Google Cloud Next, in several conversations, the message that I got was clear. Forget the major providers, each one of us is struggling to define where one tool ends and another begins. We are being pelted with frameworks that have several % of overlap in functionality.

Because we are told we must move fast or risk being obsolete, we don’t take the time to evaluate these factors. We just add another layer to the stack. We use Framework A for the frontend, Agent B to bridge it to Framework C, and Cloud Service D to wrap it all up.

Each layer of this convenience is a layer of obfuscation. The more layers we add without understanding them, the more risk we are inviting or in other words, we are ensuring the less comprehension we will have of how everything works.

Another favourite of mine is trying to gauge our common understanding of common technical terms. This has always been a favourite over the years. Ask two people the definition of a popular term and you get different answers. I used to get amused at this when I was younger but I now look at this with a different lens that is of some concern to me.

Let’s take the most popular thing on this planet “What is an Agent?” What I am concerned about is not the differences in what technical folks know about what constitutes an Agent but the wide spectrum of answers, given in all seriousness. It was almost as if the word “Agent” has become a catch-all that means everything and nothing. Forget your specific Cloud and services that it provides. People haven’t even reached there.

Let’s come back to this Agent definition. It’s a structural problem. When a vendor tells you to build an agentic workflow, they might mean a simple chatbot, while your boss thinks it means a system that can independently refactor your database schema. I am completely fine with things built on specifications but if we start building them on a foundation of what I think it is (or vibes), we are in for an interesting ride.

The Rise of the Explainer

Enough rambling. Let’s talk about the reality of the job ahead.

First up, our ability to comprehend, generate code and develop applications is limited and agents are best poised to take up that activity. Don’t try to fight that.

What I felt was the need of the hour was for all of us to take things slowly and understand the basics. This is true even for large providers like Google and others, to stress on giving a structured path to everyone, to understand the systems of the future, how to spend them evaluating them, how to run them in production, all in conjunction with agents. We need a reset of how this information is given and explained to us.

We have reached a point where we cannot understand it all, we are becoming slower, we are going to become obsolete in our own systems and hence how do we address it bit by bit? This is not going to be addressed by throwing the next set of Agent skills at us, and telling us to just use that, just because it does it all.

A few ways that I hope we can address this:

  • Forget the folks who can generate vibe coded apps at 10x the speed. Most of us need folks, who can take a mess of AI-generated slop and break it down into first principles for their team. The person who can open up this black box for us, explain what is needed in a structured and phased fashion is the one with real power, in my opinion. Be that person. And don’t be afraid to use AI tools to help you understand, document and present the workings to a wider audience. You have a wonderful assistant in AI.
  • We need to stop viewing learning time as a luxury. You absolutely need that. If your organization is asking you to deploy agentic frameworks without giving you the time to understand it, you are being set up for a production disaster. Education and foundational training in these new paradigms are as critical as the code itself. You cannot vibe your way into a resilient system; you have to engineer it. Especially in this area, we often have codelabs that are highlighted as a way to learn more. I think codelabs are wonderful if you take the time to dissect and understand what they are using with a deeper and wider lens. Without that, its a copy and paste exercise and you are damaging yourself. I absolutely hate the gamification and speed/time limits, being built into completing codelabs. Please don’t get sucked into that. Sure, you are someone’s metric but don’t let that happen at the expense of your learning and understanding.
  • There is a massive, high-value niche opening up for those who can bridge the gap between Hype and Ops. Can you explain why an agent’s reasoning loop failed? Can you be the quality check for 20,000 lines of code that has to be reviewed as part of the next sprint cycle? Can you build the tools that connect these agents to your real-world data? Can you just tell folks how the whole thing works? I personally am very bullish on anyone willing to put their hands up, understand something and then distill it for others. An AI as a companion tool can play a big role here too, but I still think, a human will do it better and we will learn better from a human being.

The Final Word: Driving The Engine

Slowing down is not a sign of weakness. I read a beautiful blog post recently that called out the rapid pace of agentic adoption creating brittleness in our software. The article highlights the need to use agents only for scoped, non-critical tasks while keeping humans as the primary architects and quality gates. I am not sure if we will stop there and whether the force of agents is unstoppable but the article gives us good points to slowing down, taking our time to understand and moving forward with care. I suggest you read it.

On a tangential note, I hope that everyone who is called to judge a Hackathon that was a single day of vibe coding apps, looks at the demos and says “This is impressive, but it’s a security and maintenance nightmare.” Be nice to them but most importantly, be fair to them with these comments.

I repeat, slowing down is not a sign of weakness, it’s a sign of professional maturity. Even at a place like Google Cloud, where we are building the very engines of this AI revolution, I would say that the same rule applies: A powerful engine is useless and potentially dangerous if the driver doesn’t know the map.

Our tools, like Vertex AI and Gemini, are incredibly capable, vast in scope and complex at times, but they are still tools. They require architects who understand first principles, not just practitioners who can prompt a “Happy Path.” Are both needed? Yes to that too.

The software industry has always eventually returned to its core values: stability, security, and maintainability. If you take the time to ask “Why?” and “Is this the simplest way to solve this?”, you aren’t being a bottleneck. You are being a professional. In our current era of infinite, automated “slop,” the person who can actually explain the system is the one who will be left standing.

Slow down now, so you don’t have to stop later.

--

--

Romin Irani
Romin Irani

Written by Romin Irani

Developer Advocate @ Google. My passion is to help developers succeed. ¯\_(ツ)_/¯