Browse
Log in / Register
Share
In a viral X post, a software engineer at a large company described a team forced to let AI do nearly all the thinking—writing specs, code, tests, product documents, tickets, and even resolving those tickets. The engineer said nobody likes it, and that employees are pushed to ship as much as possible, working 12-to-13-hour days just to "press enter." Zoho founder and CEO Sridhar Vembu replied on June 13, 2025 with a blunt warning: "This is sad. I tell our engineers to use AI but never cede our understanding to AI." His response has become a rallying point for developers worried that the AI coding boom is moving faster than the industry can responsibly handle.
The original post circulated widely in developer circles and struck a nerve because it describes a future many engineers say is already here. The team in question, at an unnamed large company, uses Anthropic's Claude Code as the de facto author of its software development lifecycle. "The specs, code, tests, PRDs, tickets, resolution of those tickets, reports, etc., everything is made by Claude Code," the engineer wrote. "Nobody on my team likes this. They are being forced to ship as much as they can."
The engineer described a draining rhythm: 12 or 13 hours a day spent feeding instructions into the model and moving on. There was little time, the post said, to inspect what the AI produced or to understand how the different pieces of the system fit together. "There is no sense of victory. Nobody is resolving bugs. In reality, nobody is thinking anymore," the engineer wrote.
The post drew hundreds of replies from people who identified with the description. Some said they are evaluated on raw output, making thorough code review a luxury their managers cannot afford. Others said they have been told to "trust the model" when they raised concerns about accuracy.
Vembu is not a typical Fortune chief executive. He still writes code, spends time on the ground with Zoho's engineering teams, and often uses X to discuss technical details. He also has a track record of resisting industry fads. Zoho remains one of the few significant software companies that has scaled without venture capital, and Vembu has frequently preached the value of long-term thinking over quarterly wins.
His response was aimed not at AI tools themselves but at what he sees as an attitude problem. "This is sad" was his reaction to the idea of an entire engineering team surrendering its judgment to a model. His follow-up warning made the risk explicit: "As an industry, we are driving too fast in a fancy new car we barely understand how to drive, inviting disaster."
Vembu's message to Zoho's own engineers is simple: use the tools, but never stop understanding what they produce. Zoho, meanwhile, has been integrating AI throughout its enterprise software stack, making clear that Vembu is not anti-AI. He is against unthinking adoption.
Vembu's warning lines up with some of the most closely watched research on AI in software engineering. Google's DORA research team, which publishes the widely cited State of DevOps report, found in its most recent edition that AI adoption among software teams has climbed sharply—but the results are mixed. Teams reporting the heaviest AI usage often saw faster delivery times, yet some also reported more difficulty keeping production systems stable. DORA's authors cautioned that AI, without the right engineering practices, can turn a speed gain into a reliability problem.
Surveys of developers tell a similar story. Stack Overflow's 2024 developer survey, which collected responses from tens of thousands of programmers, found that roughly three-quarters are using or planning to use AI tools. At the same time, many respondents remain skeptical about the quality of AI-generated code, and the most experienced developers tend to be the most careful about what they accept from models.
None of that proves AI is a net negative. It does suggest that the benefits depend heavily on what engineers actually do with the output.
The term "vibe coding," coined earlier this year by AI researcher Andrej Karpathy, describes the practice of telling a model what you want and accepting whatever code it returns if it looks plausible. For a script or a prototype, that can be astonishingly effective. For production business software, it is another story.
Enterprise codebases are dense with dependencies. A change that looks harmless in a generated diff might bloat a database migration, introduce a security flaw, or silently alter business logic. Without engineers who understand the context, those problems slip through, then resurface months later as an outage, a compliance issue, or a remediation project that costs far more than the time saved during development.
The engineer's post suggests that some companies have made vibe coding a full-time job: all day, every day, pressing enter and hoping the system holds together.
The reasons are not hard to find. Tech companies are under enormous pressure to show that AI investments are paying off. Executives have spent months telling investors that AI will make engineering teams smaller, faster, or both. That sets up an immediate incentive: ship more code, close more tickets, and demonstrate that AI is working.
What that misses is the difference between output and outcomes. Shipping code that nobody understands does not create value; it creates risk. And when engineers feel they cannot pause to review the work, the risk compounds. The engineer behind the viral post captured the result of that dynamic: long hours, low morale, and a sense that nobody is actually solving problems.
It is an especially acute problem for early-career engineers. The years a developer spends reading code, making mistakes, and learning why things break are the same years that build the judgment AI is helping to automate. If junior developers spend those years supervising model output instead of doing hands-on technical work, the industry may end up with a generation that can review AI's answers but cannot independently build or repair complex systems.
Vembu's advice for engineers does not require abandoning AI. It requires treating AI output the way a good engineer treats any draft: skeptically. Read it. Critique it. Run the tests. Rewrite the parts that do not feel right. Never check in a line of code that you cannot explain in a review.
For managers, the responsibility is to create the conditions for that kind of work. That means running AI-generated contributions through the same pipelines as human-written ones: code review, continuous integration, and a culture that rewards reliability as much as speed. Vembu has often said that software is a discipline of patience, and that shortcuts eventually demand to be paid back. The current push to use AI everywhere does not erase that rule.
The AI coding revolution will not be undone. Every major cloud provider and model maker is building toward a world where software is written in conversation with machines. Claude Code, Codex, Copilot, Jules, and their successors will keep improving, and their adoption will keep spreading.
But the questions raised by Vembu and the anonymous engineer are not about whether AI can generate good code. They are about what it means to be an engineer at a moment when generating is the easy part. If companies treat AI as a replacement for understanding, they will end up with codebases no one can defend, fix, or improve. If they treat AI as an assistant to people who still own the work, they just might get both speed and something rarer: software that the people building it actually understand.
