If you want to understand the modern software industry, do not look at the press releases from Silicon Valley giants. Instead, look at the technical support desk of an AI code editor.
In a recent episode of the podcast The Root Cause, host Priyank Upadhyay sat down with Mohit, who runs user operations and technical support at Cursor. For the uninitiated, Cursor is the AI-first fork of VS Code that has captured the attention of the global developer community.
What makes Mohit’s perspective so compelling is that he does not have a computer science degree. He is entirely self-taught, yet he spends his days solving complex system, network, and development bugs for some of the most critical, advanced programmers in the world.
His journey, and his day-to-day life inside the Cursor team, reveals several hard truths about the actual reality of building, debugging, and surviving in an industry that is shifting by the week.
1. Technical Support in the Age of Advanced Developer Tools
It is one thing to run customer support for a consumer application where users struggle with password resets. It is a completely different beast to handle user operations for an IDE used daily by elite software engineers.
When a Cursor user runs into an issue, they are not asking simple questions. They are reporting:
- Obscure local proxy configuration errors.
- Custom build pipeline failures in complex containerized environments.
- Microsecond lag spikes in autocomplete performance.
- Deep compatibility bugs with external programming languages.
Mohit explains that when he joined, he had to quickly learn how to diagnose deep system and network issues. Because his users are highly technical, his troubleshooting process cannot rely on canned responses. It requires a deep understanding of developer environments, local networks, and the underlying architecture of modern AI systems.
This is the new reality of technical support in the technology sector. As AI tools democratize simple coding, the role of the support professional merges with that of the systems engineer.
2. The Reality of "High-Agency" AI Development
One of the most popular narratives in tech right now is that an AI code generator can build anything instantly. We see viral videos of people shipping entire platforms with a single sentence.
Mohit’s own experience building a database-driven leaderboard microsite for 5,000 active users tells a much more realistic story. Yes, he built and shipped the entire production-grade project in a single week using AI assistants, but it was not a magic trick.
"It took me a couple of days and a good amount of burning through API credits just to get the database basics right," Mohit admits.
This is the side of AI software development that rarely gets talked about: the friction. Building with AI is not a passive activity. It involves a massive amount of cognitive effort, trial, error, and frustration. You still have to manage database state, figure out why an API payload is malformed, and debug environment variables.
The AI tool accelerates the writing of the code, but the human still has to supply the structural logic, the stubbornness to keep troubleshooting, and the ultimate accountability for the system.
3. The "Confetti" Trap of AI Code Generators
Despite working inside one of the most successful AI tools on the planet, Mohit is refreshingly skeptical of AI-generated code. To explain why, he uses a brilliant analogy: the Calculator App Metaphor.
If you ask a seasoned, highly disciplined human engineer to build a calculator application, they will write a lean, highly optimized 400-line codebase. The code will do exactly what you want, utilize minimal system resources, and remain incredibly easy to maintain. When you calculate two plus two, it will silently display four. There will be no extra fluff.
If you ask a generic AI assistant to build that same calculator, it defaults to visual pleasing and complexity. It wants to show off its capabilities. So, it writes a massive, 2,000-line codebase. It pads the application with modern animations, floating particles, and a cascade of digital confetti every time you hit the equals button, even if you never requested any of it.
This extra code is what Mohit calls "confetti." It is the bloat, the redundant libraries, and the unoptimized logic that Large Language Models (LLMs) insert to make their outputs look complete.
While the application might look impressive on the surface, the underlying architecture is often a bloated labyrinth. This is why the role of the software engineer is shifting from a writer of code to an editor of code. We must become the people who know how to prune the digital confetti, ensuring our systems remain clean, secure, and performant.
4. How MCP and IDE Integrations are Revolutionizing Modern SRE Workflows
Historically, systems operations and software development have lived in separate worlds. When an application failed, an engineer had to leave their workspace, open a web browser, log into Datadog, query Elasticsearch, and inspect logs in a completely different UI.
Cursor is part of a quiet movement to collapse these walls by bringing system observability directly into the developer environment.
Using the new Model Context Protocol (MCP) integrations, developers and support engineers can connect their IDE directly to their live infrastructure. Mohit shared how this works in practice during a support session.
If a user reports a localized lag or a network timeout, Mohit does not need to context-switch into external monitoring suites. By using plugins like RubixKube inside his editor, he can:
- Query live Kubernetes cluster configurations.
- Inspect enterprise network settings and firewall rules.
- Run real-time system diagnostics directly alongside the code files.
By pulling infrastructure context into the IDE, engineers can find root causes in seconds rather than hours. It changes the developer environment from a simple text editor into a unified control room for the entire system lifecycle.
5. The Illusion of the Skeleton Crew: Token Costs vs. Engineering Burnout
As companies look to cut costs, there is a dangerous assumption that AI will soon allow a three-person startup to build and run a global enterprise.
Imran and Mohit both warn that this is a fundamental misunderstanding of how scale works. While AI tools can drastically increase individual developer velocity, they do not reduce the sheer complexity of running a company.
If you shrink your team down to a tiny skeleton crew under the assumption that AI will handle the rest, you face two immediate crises:
Rapid Human Burnout
AI can generate code, but it cannot manage customer relationships, handle complex architectural decisions, or sit on a call to debug a critical production outage at midnight. The human coordination cost remains constant, and putting that entire load on a tiny team will break them.
Skyrocketing API and Token Costs
Relying entirely on recursive AI agents to write, test, and deploy code is incredibly resource-heavy. Currently, AI token prices are highly subsidized and artificially low. If you run complex autonomous workflows day in and day out, your API expenses can quickly rival what you would have spent on hiring experienced engineers.
6. Yuval Noah Harari’s Warning: The Mandate of Continuous Reinvention
At the end of the day, Mohit’s journey from a non-technical background to user operations at Cursor is a living example of a thesis put forward by historian Yuval Noah Harari.
In his book 21 Lessons for the 21st Century, Harari argues that the defining challenge of our generation is not learning a single trade, but the ability to constantly reinvent ourselves.
In previous generations, an individual could learn a specific skillset in their twenties and comfortably use that exact same knowledge to earn a living until retirement. That world is gone. Today, the lifespan of a technical framework or a specific language is incredibly short.
"It is entirely on us to keep adapting," Mohit says. "You cannot expect to remain relevant if you are not willing to learn how these new systems function."
The real dividing line of the future is not between those with computer science degrees and those without. It is between those who are comfortably settled in what they already know, and those who have the courage to continuously throw away their old tools, embrace the friction of learning, and adapt to the weekly cycle of technological change.