Vibe Coding · PiniShv

The Vibe Coding Backlash Is Right. Seniors Are Losing the Argument Anyway.

Fri, 24 Apr 2026 14:00:00 +0300

Something finally broke this week. Forbes published Vibe Coding Will Break Your Company. Senior engineers are circulating it. Other senior engineers are writing their own versions. The pushback on vibe coding culture has been brewing for months, and it just hit mainstream media.

The seniors are right. And they’re about to lose the argument anyway.

Here’s why, and what needs to happen if they actually want to win it.

What the seniors are right about
#

The data at this point isn’t close.

Multiple independent audits of AI-assisted codebases are converging on the same picture: AI-co-authored code ships with materially more “major” issues than human-written code. Audits of no-code AI app-generation platforms keep finding meaningful percentages of generated applications going live with real security holes: hardcoded API keys, client-side-only authentication, unsanitized user inputs.

In July 2025, a Replit AI agent deleted a live production database during an explicit code freeze, affecting over 1,200 executive users. The agent had permissions. The permissions were never meant for an agent. Nobody designed for the possibility.

Across the industry, Stack Overflow’s trust-gap research and DX’s Q1 2026 impact report tell the same story: 84% of developers use AI daily. Only 29% trust the code reaching production. PR throughput is up 46% in some teams. Defect rates are up 50% in some of the same teams.

And the perception gap keeps embarrassing us. METR’s study measured experienced developers as 19% slower with AI while they believed they were 20% faster. 39 percentage points of self-deception. The feeling is real. The feeling is wrong.

The craft didn’t change. The pressure to ship faster without understanding what shipped did. And when you ship what you don’t understand, you pay for it later, with interest. The next generation of senior engineers is taking the brunt of it.

The seniors are not wrong to push back. They’re watching production systems rot in slow motion.

What the vibe coders are also right about
#

For a lot of what companies actually ship, fast-and-rough is genuinely fine. Internal tools nobody will maintain in two years. One-off data migrations. Prototype features for customer calls. Throwaway scripts. The economics of fussing over these pieces changed. If an agent ships them in thirty minutes and they work, that’s a real win.

The vibe coders are also right that a lot of “senior engineering rigor” is muscle memory from an era where code was expensive to produce. Gatekeeping code review, nit-level style comments, architectural debates that take longer than the feature itself. Some of it was always noise. More of it is noise now that the economics flipped.

And they’re right that the pushback often sounds like resistance to change from people protecting their role.

Both sides are right about different things. The fight isn’t which side wins. It’s where the line gets drawn.

Why the seniors are losing anyway
#

In most engineering orgs, the pushback against vibe coding is losing. Not because the data is wrong. Because the seniors can’t make their case in the meetings where throughput metrics get shown.

Imagine the scene. Quarterly review. Director pulls up a dashboard.

PR throughput: up 46%
Commits per engineer: up 2.1x
Features shipped: up 34%
Deployment frequency: up

Then the senior engineer raises a hand and says “but the code quality is degrading.”

Where’s that dashboard? What’s the number? Can you point to the specific incidents that didn’t happen because you caught them in review? Can you show the rework that wasn’t done because you stopped a bad architecture at design time?

Usually, no. The senior engineers have the instinct and the experience. They don’t have the receipts.

Throughput is legible. Judgment is invisible. In a fight between legible and invisible, legible wins every time.

This is the real problem. The seniors are right, and they’re losing, and they’re losing because the thing they’re right about doesn’t show up on the charts.

What “legible judgment” actually means
#

In organizations doing this well, the senior engineers who keep winning this argument don’t do it by being louder. They do it by making the prevented damage visible. Five concrete moves.

Write down the decisions you stop from shipping. When you block a PR because the approach is wrong, don’t just close it. Write a one-line note: “Rejected: would create a race condition under load. Suggested redesign: queue-based.” Collect these. After six months, you have a measurable “incidents prevented” count. That’s a number. Numbers win.

Track rework on AI-generated code specifically. Most PR analytics can’t distinguish AI-generated from human-written code. If yours can, instrument it. Show the quarterly trend: what percentage of AI-generated commits get reworked within 30 days? If it’s higher than your human-written baseline, that number is your argument.

Tie blocked architectures to real incident data. When an incident happens that a senior flagged earlier, say so in the postmortem. Not as blame. As calibration data. “This failure mode was identified in PR #1847 on March 3 and was not addressed before ship.” That’s the receipt.

Put a senior on every AI-native system’s design review, not just the code review. Code review is too late. By then the architecture is set and the only conversation left is stylistic. Design review is where senior judgment actually prevents expensive mistakes. Move your seniors upstream.

Run quarterly “prevented incident” retros. Once a quarter, the senior engineers present what they caught and the counterfactual. What would have happened if this had shipped? What did it cost to catch it? That reframes senior time as prevention, not overhead.

The bigger reframe
#

The vibe coding debate is a symptom. The underlying issue is that engineering organizations built their scorecards for a world where code production was the bottleneck. In that world, throughput meant progress.

That world ended sometime around late 2024. The bottleneck isn’t production anymore. It’s ownership. Review capacity. System understanding. Architectural coherence across the full surface area. Governance. Incident response.

If your scorecard only measures production throughput, you will systematically underfund the ownership layer. The senior engineers trying to protect that layer will keep losing quarterly reviews while the on-call pager gets louder.

The seniors aren’t wrong. The scorecard is.

What senior engineers should do right now
#

Three moves, in order.

Stop arguing about vibe coding. The debate is a distraction. Every hour spent defending “slow careful engineering” in principle is an hour not spent proving prevented cost in practice.

Start a prevented-incident log today. One line per blocked PR, rejected design, caught architectural issue. Share it monthly with your manager, not as complaint, as data. Six months from now you’ll have a case you can actually make.

Volunteer for the AI incident response playbook. When the next AI agent deletes something important (and it will), be the person with the playbook. Incidents shift organizational gravity. You want to be the person organizations call, not the person who said “I told you so.”

The seniors who survive this era will not be the ones who pushed back the loudest. They’ll be the ones who learned to make their judgment measurable, visible, and impossible to dismiss when the throughput chart is on screen.

The vibe coders are going to keep shipping. That’s fine. The question is who’s going to own what they ship in production three months later. That’s the open job. If you’re a senior engineer, that’s your job. Go take it.

What prevented-incident data do you actually have from the last quarter? Find me on X, Telegram, or LinkedIn.

Disclaimer: This article references specific studies, surveys, and public commentary for illustrative and educational purposes, including work from Forbes, Stack Overflow, DX, METR, Medium authors, Replit and Lovable incident reports, and industry analyses available at the time of writing. I have not independently verified all claims. The analysis and opinions expressed are my own. I have no financial interest, business relationship, or affiliation with any companies or tools mentioned. This is commentary, not investment, legal, career, or business advice.

Google Stitch Just Made UI Design a Developer Skill

Fri, 20 Mar 2026 10:00:00 +0200

Here’s a number that should make every engineering leader pay attention: 12 seconds.

That’s how long Google Stitch takes to generate a settings page. Complete UI. Interactive prototype. Production-ready React and Tailwind code. Twelve seconds.

The same page takes about 45 minutes in Figma if you know what you’re doing.

When Google announced the March 2026 Stitch updates, Figma’s stock dropped 8.8%. The headlines said “Figma is dead.” Twitter was full of designers updating their LinkedIn profiles. The panic was loud and immediate.

But the panicking people are asking the wrong question. Stitch doesn’t replace designers. It does something more interesting. It makes UI design a developer skill.

What Stitch actually is
#

Stitch is a free, browser-based tool from Google Labs that generates high-fidelity user interfaces from text prompts, voice descriptions, sketches, or uploaded images. It produces both visual designs and synced production code simultaneously. React with Tailwind CSS, HTML/CSS, or Flutter. It exports directly to Figma with proper Auto-Layout applied.

It’s powered by Gemini under the hood. The March 2026 update brought an infinite canvas, voice interaction, a design agent that reasons across your entire project, and something called “Vibe Design” where you describe the feeling you want instead of specifying components.

The GitHub repo has an open-source skills ecosystem for extending it. There’s MCP integration so your AI coding agents in Cursor, Claude Code, or Windsurf can call Stitch directly to generate UI without leaving the IDE.

And it’s completely free. No credits, no subscription. Just a Google account.

Here are some examples of what Stitch generates from simple text prompts. Dashboards, admin panels, e-commerce layouts, mobile feeds. All generated in seconds, all with production-ready React and Tailwind code behind them:

Scroll to see more. Each screen generated by Stitch from a text description.

These aren’t mockups I made in Figma. The code behind each screen is production-ready React with Tailwind CSS.

Why developers should care more than designers
#

The design community is having the wrong conversation. They’re debating whether Stitch replaces Figma. It doesn’t. Figma is where serious design collaboration, brand refinement, and complex design system work happens. That’s not going anywhere.

The real shift is on the developer side.

Think about the typical flow in most engineering orgs. A product manager writes requirements. A designer creates mockups in Figma. Those mockups go through review cycles. Eventually they land in front of a developer who translates them into code. That translation process is where things get lost. The spacing is wrong. The colors are close but not exact. The responsive behavior wasn’t specified. The developer interprets, the designer reviews, and the cycle repeats.

Stitch compresses that entire pipeline into a conversation with an AI. A developer can describe what they need, get an interactive prototype in seconds, iterate by talking to the canvas, and export production-ready code. No design tool proficiency required. No translation layer. No interpretation gap.

For engineering teams, this changes three things:

Prototyping becomes instant. When you’re evaluating an approach, testing a user flow, or building an internal tool, you don’t need a designer in the loop for the first draft. You describe what you want, get something real, and iterate from there. The feedback loop goes from days to minutes.

Internal tools stop looking terrible. Every engineering org has internal dashboards and admin panels that look like they were designed in 2008. Nobody allocates design resources to internal tools. With Stitch, a developer can generate a clean, professional UI for an internal tool in the time it used to take to write the boilerplate HTML.

The design-to-code gap shrinks. When the same tool produces both the visual design and the code, there’s no translation error. The code matches the design because they’re the same artifact. That alone saves hours of back-and-forth on every feature.

How it fits into the AI app builder landscape
#

Stitch is not the only tool in this space, and understanding where it sits matters.

Stitch is design-first. It generates polished UI and exports frontend code. It does not build backends, databases, authentication, or deploy anything. It’s the design and frontend layer only.

Lovable is app-first. It builds complete full-stack applications. Frontend, backend on Supabase, database, authentication, one-click deployment. If you want to go from idea to deployed MVP, Lovable does the whole thing. The UI won’t be as polished as Stitch, but you get a working app.

Bolt.new is code-first. A browser-based development environment from StackBlitz. It generates full projects with real-time preview and flexible framework choices. More control than Lovable, but you need developer skills for backend and deployment.

v0 (Vercel) is component-first. It generates clean React components that drop into existing codebases. Less about full-page design, more about generating specific UI components with good code quality.

Google AI Studio is prototype-first. It generates code and runs a preview you can share. More interactive than Stitch but less design-focused. It’s the middle ground between designing a UI and building a working app.

Firebase Studio is production-first. Full developer environment with terminal, dependencies, and deployment pipeline. The tool for when you’re past prototyping and building for real.

The pattern: Stitch handles the “zero to design” phase better than anything else. But it hands off before the “design to production” phase. For teams that already have a development pipeline, that handoff is natural. For solo builders who want everything in one tool, Lovable or Bolt are better fits.

The MCP integration is the sleeper feature
#

Most coverage of Stitch focuses on the canvas, the voice interaction, and the Figma export. The feature that matters most for developers gets buried in the docs.

Stitch has an MCP server. That means your AI coding agent in Cursor, Claude Code, Windsurf, or any MCP-compatible IDE can call Stitch directly to generate UI components as part of a coding workflow.

Think about what that means. You’re building a feature in Cursor. Your agent needs a dashboard layout. Instead of switching to a browser, opening Stitch, generating the design, and copying the code back, the agent calls Stitch as a tool, gets the component, and drops it into your codebase. All without leaving the IDE.

There’s also a “Design DNA” feature that extracts design context (colors, typography, structure) from generated screens and feeds it to the agent. So subsequent screens maintain visual consistency automatically. And DESIGN.md exports your design system as a portable file that can be imported into other projects.

For anyone already running AI agents in their development workflow (and you know I am), this is where Stitch stops being a design tool and starts being infrastructure.

Will it replace UI/UX designers?
#

No. But it will change what they spend their time on.

Stitch eliminates the blank canvas problem. The first draft, the initial layout, the “let me explore three different approaches” phase. That used to take hours or days. Now it takes seconds.

What Stitch can’t do is brand identity. Design systems that feel cohesive across an entire product. The subtle decisions about hierarchy, rhythm, and emotional response that make the difference between a functional interface and one that people love using. The output quality is good, sometimes surprisingly good, but it lacks the refined aesthetic that an experienced designer brings to high-end work.

The honest assessment: Stitch handles 0-to-1 better than any tool I’ve seen. But 1-to-100, the refinement that turns a prototype into a polished product, still needs a human designer. Probably in Figma.

The real shift for design teams is that the bar for “good enough” just moved dramatically. Internal tools, admin panels, MVPs, quick prototypes, landing pages. All of these used to need designer time. Now they don’t. That frees designers to focus on the work that actually needs their taste and judgment.

For managers, the question isn’t “should we fire our designers?” It’s “what should our designers stop doing so they can focus on what only they can do?”

The limitations nobody’s hyping
#

85% accuracy in standard mode. That means roughly 1 in 6 components won’t be quite right. The experimental mode hits 95% but takes 45 seconds instead of 12. For prototyping that’s fine. For production you’re editing either way.

No backend. Stitch generates beautiful frontends that don’t do anything. No API calls, no state management beyond the UI, no data persistence. You need a developer to wire it up.

Free comes with a question mark. It’s a Google Labs product. Google has a history of killing Labs experiments. If you build workflows around Stitch, you’re betting Google keeps investing in it. The free pricing is great today, but there’s no guarantee about tomorrow.

The “vibe design” concept has limits. Describing a feeling works for simple pages. For complex enterprise UIs with dozens of states, error handling, and edge cases, you still need to be specific. The AI can’t infer your business logic from a vibe.

What this means for engineering orgs
#

Every few years, a tool shifts the boundary between what developers can do without specialist help and what requires a dedicated team.

GitHub Copilot shifted the boundary on code generation. Terraform shifted it on infrastructure. CI/CD platforms shifted it on deployment. Each time, the specialists didn’t disappear. They moved up the stack to harder problems.

Stitch is shifting the boundary on UI design. Developers can now produce professional-quality interfaces without design training. That doesn’t eliminate designers. It eliminates the bottleneck where developers wait for design input on work that didn’t need a designer’s taste in the first place.

For engineering leaders, the practical implications are:

Evaluate Stitch for internal tooling. If your team builds admin panels, dashboards, or internal tools, Stitch can compress the UI phase from days to hours. The ROI is immediate.

Integrate through MCP. If you’re already running AI agents in your development workflow, add Stitch as a tool. Let your agents generate UI components as part of the coding flow. The context switching savings alone are worth it.

Rethink the designer-to-developer ratio. If developers can handle the first 80% of UI work, your designers can focus on the 20% that actually needs their expertise. That’s a better use of everyone’s time.

Don’t bet everything on it. It’s a Google Labs product. It’s free. It’s excellent. And it could get shut down, pivoted, or monetized at any point. Use it as a tool in your toolkit, not the foundation of your process.

The wall between design and code has been getting thinner for years. Stitch didn’t remove it. But it put a very large door in it. And for engineering teams, that door is wide open.

Using Stitch in your development workflow? Integrating it with AI coding agents? I’d love to hear how you’re using it. Find me on X or Telegram.

When Nvidia's CEO Says 100% of Engineers Use Cursor, He's Not Exaggerating

Fri, 17 Oct 2025 00:00:00 +0000

Last week, Nvidia CEO Jensen Huang sat down for an interview with Citadel Securities and dropped a statement that should make every developer pay attention: “100% of our software engineers and chip designers use Cursor.”

Not “some teams are trying it.” Not “we’re evaluating it.” One hundred percent.

Then he listed five other AI companies shaping the future of work: OpenAI, Harvey, OpenEvidence, Replit, and Lovable. Six startups total. These aren’t random picks. This is Nvidia’s CEO, someone who sees the entire AI landscape, calling out the tools his engineers actually use to build some of the world’s most complex software.

Cursor stood out. Not just mentioned, but specifically highlighted as the tool that’s achieved total adoption across Nvidia’s engineering organization.

I’ve been using Cursor for about a year now. When I heard Huang’s statement, my reaction wasn’t surprise. It was recognition. He’s describing what I’ve been experiencing every day.

What Huang Actually Said
#

The interview with Citadel Securities, published on October 15, focused on how AI will reshape workforces. Huang has been saying for months that future companies will have both human and “digital” employees working together. He’s been calling it the age of “agentic AI,” where AI assistants handle specific tasks as part of integrated teams.

When talking about what that looks like in practice, he pointed to six companies: “Some of them will be OpenAI-based, and some of it would be Harvey-based or Open Evidence or Cursor or Replit or Lovable.”

OpenAI builds the foundation models that power much of this AI revolution. Harvey focuses on legal work, OpenEvidence on healthcare. Replit, Cursor, and Lovable are what Huang called “vibe coding” tools. AI-powered coding environments where you describe what you want and watch it materialize.

But Cursor got special attention. That 100% adoption number. And then this: “Productivity gains, the work that we do is so much better.”

Not just faster. Better.

That distinction matters. Plenty of tools make you faster while producing worse results. Cursor is apparently doing both: speed and quality improvements.

Why I Agree With Huang
#

I’m not going to pretend to have Nvidia’s scale or complexity. But I’ve been building software for years, and I’ve tried most of the AI coding assistants that have emerged in the last two years. Cursor isn’t just incrementally better than alternatives. It’s fundamentally different in ways that matter.

When I start working on a feature, Cursor understands the entire codebase. Not just the file I’m editing, but the patterns I’ve used elsewhere, the architecture I’m following, the dependencies that exist. It’s context-aware in a way that GitHub Copilot never was.

I can highlight a section of code and ask “why would this fail if the user uploads a file larger than 10MB?” and get an actual answer based on my specific implementation. I can describe a feature in natural language and watch Cursor scaffold the entire thing, following my existing patterns, using my preferred libraries, matching my code style.

The result: I spend less time writing boilerplate and more time thinking about architecture. Less time debugging syntax and more time catching edge cases. Less time searching documentation and more time making design decisions.

This is what Huang meant by “better work.” The cognitive load shifts from mechanical tasks to judgment calls. From typing to thinking.

The UI/UX Is Legitimately Good
#

Let me be specific about why Cursor’s interface works.

First, it’s built on Visual Studio Code. This isn’t a new interface you have to learn. If you know VS Code, you know Cursor. All your extensions work. Your keybindings work. Your color themes work. The learning curve is essentially zero.

Second, the AI features are integrated without being intrusive. There’s a sidebar where you can chat with the AI about your code. There’s inline suggestions that appear as you type. There’s the ability to highlight code and ask questions or request changes. All of it feels native, not bolted on.

Third, the AI understands scope. When I ask it to refactor something, it knows what files are related. When I ask it to implement a feature, it suggests which files to create or modify. It doesn’t just generate code in isolation. It thinks about the system.

Fourth, it shows you what it’s doing. When Cursor makes changes, you see a diff. You can accept, reject, or modify. You’re never locked into AI decisions. The AI is a collaborator, not a black box.

The interface respects the developer. You’re always in control. The AI makes suggestions, you make decisions. That balance is hard to get right, and Cursor nails it.

Compare this to some other AI coding tools. Some feel like chatbots awkwardly embedded in an IDE. Some generate code you can’t see until you accept it. Some fight with your existing workflow instead of enhancing it. Cursor got the UX right from the start.

The Pricing Problem Nobody Wants to Talk About
#

Here’s the uncomfortable truth: for the last year, the main reason people leave Cursor isn’t the product. It’s the pricing.

In mid-2025, Anysphere (the company behind Cursor) changed their Pro plan from a fixed request model to a usage-based credit system. The $20 monthly subscription still exists, but now it covers a variable amount of work depending on which AI models you use and how intensively you use them.

Some users suddenly found themselves burning through credits faster than expected. Others got surprise bills. The confusion was real enough that Anysphere’s CEO, Michael Truell, issued a public apology and offered refunds to affected users.

Then in July, they introduced a $200-per-month “Ultra” plan for heavy users. The jump from $20 to $200 is steep. The justification is that the Ultra plan offers 20 times more usage than Pro, but the messaging was unclear. People felt blindsided.

I’ve watched developers I know switch away from Cursor specifically because of pricing uncertainty. Not because the tool wasn’t valuable. Not because they found something better. Because they couldn’t predict their monthly costs.

This is the one area where Cursor is consistently failing. The product is excellent. The pricing model is a mess.

The irony: if Nvidia is willing to pay for 100% of their engineers to use Cursor, the value must be obvious at enterprise scale. But individual developers and small teams are jumping ship over billing confusion.

Anysphere needs to fix this. Transparent, predictable pricing. Clear tiers. No surprise bills. If they don’t, competitors will use pricing clarity as a wedge to steal market share, even if their products are technically inferior.

The Six Companies That Matter
#

Let’s go back to Huang’s list: OpenAI, Harvey, OpenEvidence, Cursor, Replit, and Lovable.

This is a CEO who sees the entire AI industry. He’s not picking companies because they have good marketing. He’s picking companies that are actually changing how work gets done.

OpenAI is obvious. They build the foundation models that power much of the AI revolution. GPT-4 and its successors are infrastructure for the AI age.

Harvey focuses on legal work. It’s an AI assistant specifically trained on legal documents, case law, and legal reasoning. Big law firms are adopting it because it actually understands legal context in ways general-purpose AI doesn’t.

OpenEvidence does the same thing for healthcare. It helps clinicians find relevant medical research and evidence-based guidance. In a field where being wrong can kill people, having AI that understands medical literature matters.

Replit is an online IDE with AI assistance. You can build and deploy entire applications from a browser. It’s lower friction than local development, which makes it powerful for prototyping and learning.

Lovable (formerly GPT Engineer) lets you describe an app and generates the entire codebase. It’s “vibe coding” taken to the extreme. Specify what you want, get a working application.

And Cursor, which sits between Replit’s simplicity and traditional development’s power. You get a full IDE, but the AI understands what you’re building deeply enough to be genuinely helpful.

What these six companies have in common: they’re not trying to replace humans. They’re building tools that let humans operate at a higher level of abstraction. Lawyers still make legal decisions, but Harvey handles research. Doctors still diagnose patients, but OpenEvidence surfaces relevant studies. Developers still architect systems, but Cursor handles implementation details.

That’s the pattern Huang sees. That’s the future he’s betting on.

Why Cursor Hits the Mark
#

I’ve used GitHub Copilot. I’ve tried Amazon CodeWhisperer. I’ve tested Tabnine and Kite and a dozen other AI coding assistants. Cursor is the one that stuck.

Here’s why:

It understands projects, not just files. Most AI coding assistants look at the file you’re editing and maybe a few related files. Cursor understands the entire repository. It knows your architecture, your patterns, your dependencies. This context awareness is the difference between “here’s generic boilerplate” and “here’s code that fits your specific system.”

It handles complex tasks. I can ask Cursor to implement a multi-file feature, and it will suggest creating new files, modifying existing files, and updating configuration. It thinks at the feature level, not the line level.

It learns your style. After working in a codebase for a while, Cursor generates code that looks like code I would write. Same patterns, same naming conventions, same structure. It’s not just correct. It’s consistent.

It explains what it’s doing. When Cursor suggests a change, I can ask why. It doesn’t just generate code and move on. It can walk through the reasoning, point out edge cases, explain trade-offs.

It gets out of the way. When I don’t need AI assistance, Cursor is just a normal editor. The AI features don’t interrupt or distract. They’re there when needed, invisible when not.

This combination is why Nvidia’s engineers use it. Not because someone mandated it. Because it actually makes their work better.

The Evolution Continues
#

Anysphere raised $900 million at a $9.9 billion valuation in mid-2025. They’re not treating Cursor as a finished product. They’re investing heavily in making it better.

Recent updates have added support for more AI models, better context handling, improved multi-file editing, and features specifically for reviewing AI-generated code. They acquired Supermaven, another AI coding tool, in late 2024 to enhance capabilities.

The trajectory is clear: Cursor is evolving toward being a development environment where AI assistance is native, not added on. Where the default mode is collaborating with AI, and the AI is good enough that you want to.

This is what I meant when I said it feels like Cursor is on the right path. Every update makes the product more capable and more usable. The core interaction model is solid. They’re building on a strong foundation.

If they fix the pricing confusion, there’s no reason Cursor shouldn’t become the standard development environment for anyone building software with AI assistance.

What This Means for Developers
#

When the CEO of Nvidia says his entire engineering organization uses a tool, pay attention. Nvidia builds some of the most complex software and hardware in the world. Their engineers are not easily impressed. If they’ve standardized on Cursor, it’s because Cursor delivers value at the scale and complexity they operate at.

I’ve seen this personally. The features I build now are more ambitious than what I would have attempted a year ago because I know Cursor can handle the implementation details. I spend more time thinking about what to build and less time fighting with syntax.

This is the future Huang is describing. Not AI replacing developers, but AI enabling developers to work at a higher level of abstraction. To be more ambitious. To focus on design and architecture while AI handles the mechanical work.

Cursor is the tool making that possible today. Not perfectly. The pricing issues are real and frustrating. But the core product is so good that even with pricing confusion, it’s achieving the kind of adoption Huang described.

The Bottom Line
#

Jensen Huang called out six companies shaping the future of work. Cursor was the only one he said has 100% adoption at Nvidia. That’s not a casual mention. That’s an endorsement from someone who sees the entire AI landscape and knows what actually works at scale.

I agree with him. After a year of using Cursor, I understand why Nvidia chose it. The UI is intuitive. The AI is capable. The integration is seamless. The productivity gains are real.

The pricing model needs work. That’s the one significant weakness, and it’s causing users to leave even though they value the product. Anysphere needs to fix this before competitors use pricing clarity to steal market share.

But the core insight remains: Cursor has figured out how to build an AI-assisted development environment that enhances rather than replaces developer judgment. It’s the tool that lets developers operate at the level Huang is describing, where AI handles implementation and humans focus on design.

That’s the innovation. That’s why it matters. And that’s why, despite the pricing frustrations, I keep using it every day.

Vibe Coding · PiniShv

The Vibe Coding Backlash Is Right. Seniors Are Losing the Argument Anyway.

What the seniors are right about #

What the vibe coders are also right about #

Why the seniors are losing anyway #

What “legible judgment” actually means #

The bigger reframe #

What senior engineers should do right now #

Google Stitch Just Made UI Design a Developer Skill

What Stitch actually is #

Why developers should care more than designers #

How it fits into the AI app builder landscape #

The MCP integration is the sleeper feature #

Will it replace UI/UX designers? #

The limitations nobody’s hyping #

What this means for engineering orgs #