Browse
Log in / Register
Share
May 10, 2026 — Zoho founder Sridhar Vembu has sharpened his warning to the software industry: AI coding tools are producing a dangerous illusion of competence. “Nobody knows anything here,” he said, describing engineering teams that merge machine-generated code they cannot fully explain or debug.
Vembu’s comment has resonated with engineering managers at a moment when AI-assisted development has moved from experiment to default. His point is not that developers should stop using AI. It is that many organizations are treating AI-generated code as a throughput tool instead of a liability that requires careful human supervision.
The phrase “nobody knows anything here” captures what happens when code review becomes a formality. AI tools can produce a pull request with dozens of files, synthetic tests, and a confident explanation of what every function does. The developer is supposed to verify that output. In practice, that verification is often a quick scan for formatting mistakes rather than a deep check of logic.
Vembu is not the first person to describe this problem. Security teams have spent the past two years finding AI-generated database requests with missing filters and cloud configurations with overly broad access. These are not ordinary freshman mistakes. They are the kind of mistakes that become expensive when they are hidden inside a large codebase.
The deeper issue is technical debt. Code that nobody understands behaves like a time bomb. It may pass all tests, survive review, and run fine for months. Then a dependency changes, or traffic grows, and the first thing the team needs is someone who can explain why the system behaves that way. If the honest answer is “nobody knows anything here,” the cost of fixing it multiplies.
Vembu’s warning also highlights a generational concern. Experienced engineers can use AI as a pair programmer because they already know what good code looks like. They can spot a hallucinated API call or an unnecessary abstraction. Junior developers do not have that internal checklist yet.
When a junior developer uses an AI assistant, they receive code that looks polished and reads as though it was written by a senior engineer. The gap between the appearance and the reality is where skill atrophy takes root. Over time, those developers learn to prompt models rather than reason about problems. They become consumers of software instead of stewards of a system.
That is not a small concern. Software development is still a discipline built on cause and effect. A developer needs to understand state, side effects, and failure modes before they can design systems that survive contact with real users. AI cannot give them that ability through autocomplete.
Anyone who follows Zoho’s product strategy knows that Vembu is not nostalgic for a world without AI. Zoho has spent years embedding its Zia assistant into business applications, and the company has consistently talked about “assisted intelligence” — a model in which AI handles a specific workload but the human stays accountable for the result.
That philosophy is directly relevant to coding. Assisted intelligence would mean using AI to draft boilerplate, write tests, or refactor patterns, with a senior engineer owning the final design. Autonomous development, by contrast, treats the model like a remote worker who does not need supervision. Vembu’s recent warning is an argument against the second model.
The distinction matters because it changes how managers measure progress. If a team tracks productivity by asking how many pull requests were opened, AI will win. If it tracks outcomes, rollback rates, and successful incident responses, the picture becomes more honest. Code that works once but cannot be understood is not a productivity gain. It is a future outage.
The most useful way to read Vembu’s warning is as a management problem, not a developer problem. Engineering leaders can take concrete steps to reduce over-reliance without banning AI.
First, every AI-generated pull request should be understandable by at least one human. If somebody cannot explain, in plain language, what the code does and why it is safe, it should not merge. That simple rule transfers accountability from the model to the engineer.
Second, AI usage should be visible in the review process. Teams should know which files came from an AI tool, because those files deserve extra scrutiny around authentication, data access, and error handling. This is not about punishing developers. It is about telling them where to focus their attention.
Third, developers need realistic feedback loops. If a junior developer starts with an AI assistant, they should also be asked to rewrite a small component without it. That exercise keeps the fundamentals sharp and prevents the feeling that coding is now someone else’s job.
Fourth, leaders should resist the urge to measure AI adoption as if it were a business metric. Lines of generated code, number of AI tool logins, or percentage of commits written by assistants are all vanity metrics. What matters is whether the software is reliable, maintainable, and secure.
Vembu’s warning comes amid a broader debate about the limits of artificial intelligence in jobs where accuracy matters. In programming, the margin for error is lower than it used to be. A single bad line can expose customer data or bring down a service. The industry spent years reducing mistakes through testing, review, and architecture. AI has increased speed, but it has not removed the need for those checks.
“Nobody knows anything here” is a memorable phrase, and it will probably be cited in stand-up meetings and strategy decks for the rest of the year. The danger is that it gets reduced to a joke about a developer staring at a chatbot. In fact, it is a warning about organizational culture: when a team stops being able to explain its own software, it has lost the most important safety net it had.
The teams that take this warning seriously will not abandon AI. They will build guardrails around it, protect review time, and keep human judgment in the author’s seat. That is a slower road than simply trusting the machine. It is also the one that keeps “anybody” in the room actually knowing what is going on.
