Two companies. Same annual Cursor subscription. Same complaint from their engineers: "We don't have enough credits to actually learn." Here's why the economics of experimentation determine who wins the AI transition -- and who produces engineers that damage their own codebase.

Published: 2026-02-11 | Author: Sahar Carmel | Category: General Agents Tags: AI adoption, engineering management, tool economics, Claude Code, Cursor | Reading Time: 12 min read

This week, two engineers from different companies reached out to me independently with the same problem.

"Sahar, we can't properly experiment with coding agents. We don't have enough credits, and we only use Opus occasionally because it's too expensive."

I asked what tool they were using. Both said Cursor. Both companies had purchased annual subscriptions, believing they'd checked the "AI adoption" box.

The first thing I did was call their managers.

I couldn't not say what I needed to say: there is zero chance your engineers will learn to code with AI if they don't get unlimited access to experimentation. Do you understand what this is equivalent to? It's like someone wanting to learn C++ but only being allowed to compile their code 10 times per month.

Both managers, to their credit, got it immediately. But the fact that they hadn't thought about it before -- that's the pattern I keep seeing. Companies invest in AI tool licenses and assume the job is done. The license is the beginning, not the end. What matters is the volume of experimentation the license enables.

And that's where the economics get interesting.

In 2002, researchers at Yale University School of Medicine ran an experiment that reads like it was designed to illustrate this exact problem.

They took 16 surgical residents (PGY 1-4 level) and randomized them into two groups. Eight residents received unrestricted access to a VR laparoscopic simulator, where they practiced gallbladder removal until they reached expert-level proficiency benchmarks -- typically requiring three to eight training sessions. The other eight received no simulator access at all.

Then both groups performed real gallbladder surgeries on real patients. The attending surgeons evaluating them were completely blinded -- they had no idea which residents had trained on the simulator and which hadn't. The interrater reliability for error assessment was 91%.

The results were devastating.

The untrained group made 6x more errors (7.38 errors per case vs. 1.19 for the trained group). They were 9x more likely to fail to make progress during the actual surgery -- to simply get stuck mid-operation with no idea how to proceed. And they were 5x more likely to injure the gallbladder or burn non-target tissue.

Not slower surgeons. Surgeons who harm patients.

Think about that for a moment. If a hospital administrator said "simulators are expensive, each resident gets 10 sessions per month," nobody would consider that reasonable. The Seymour study proved that restricting simulator access doesn't produce slightly less skilled surgeons -- it produces surgeons who actively damage the people they're trying to help.

Now translate this to software engineering.

When companies restrict their engineers' access to AI coding tools -- through token limits, budget caps, or inadequate subscriptions -- they're not producing slightly slower engineers. They're producing engineers who build worse software. Engineers who can't develop the intuition for when to trust the agent and when to intervene. Engineers who never learn the craft of prompt engineering through the only way it can be learned: through volume.

The surgical study demonstrated something counterintuitive: the cost of not training dramatically exceeds the cost of training. The residents who harmed patients didn't do so because they were inherently less skilled. They simply hadn't been given enough repetitions to develop procedural fluency.

The same principle applies to AI-assisted coding. Fluency with coding agents isn't a switch you flip. It's a skill built through hundreds of hours of interaction -- failed prompts, successful prompts, understanding when to be specific, when to be abstract, when to let the agent lead, when to constrain it. You cannot develop this fluency on 10 interactions per day.

I was lucky. Early in the AI coding transition, when the primary pricing model was per-API-call, I had a manager and executive team that pushed AI adoption with full conviction. The result? I was spending an average of $4,500 per month on tokens.

That sounds like a lot. It is a lot.

But here's what happened on the other end: we delivered in two months what would have taken a year without it. The tokens were worth every dollar -- not because each individual API call was efficient, but because the volume of experimentation enabled a fundamentally different way of working.

Most of those tokens went to failures. Bad prompts. Wrong approaches. Dead ends. That's the part people don't talk about. The learning happens in the failures. The 47th attempt at getting an agent to properly handle a complex database migration is where you develop the intuition for how to structure the 48th attempt -- the one that works.

If I'd been capped at $200/month during that period, I would have learned to be cautious with AI tools instead of fluent with them. Caution is the enemy of adoption. When every API call feels expensive, you self-censor. You revert to writing code manually "just to be safe." You never develop the muscle memory that separates someone who uses AI tools from someone who thinks through AI tools.

Here's the part most people don't understand, and it explains why the two companies I spoke with this week ended up in this position.

Anthropic's pricing model is fundamentally different from Cursor's.

Anthropic owns their servers and their models. They pay a similar cost whether their servers run at 10% capacity or 100% capacity. The marginal cost of serving an additional request, once the infrastructure exists, is minimal. This is why they can offer extremely generous rate limits on products like Claude Code. I pay roughly $200 per month for Claude Code and consistently receive what would be approximately $5,000 in value if measured at API rates. Anthropic's incentive is to fill their servers.

Cursor, on the other hand, operates on an API consumption model. They pay Anthropic (and other model providers) per request. Every token their users consume costs them real money, regardless of server utilization. This means Cursor has a structural incentive to limit usage, because unlimited usage at a fixed subscription price would make them unprofitable.

The result? An engineer on Cursor hits their rate limit after two hours of intensive work, gets downgraded to a weaker model, and effectively stops learning. The tool becomes something you use cautiously -- a resource to be conserved rather than a capability to be developed.

This isn't a criticism of Cursor as a product. It's a structural observation about pricing models. When your AI coding tool vendor pays per-token to their model provider, the economics of unlimited experimentation simply don't work. The vendor has to restrict usage or lose money. And when usage is restricted, learning is restricted.

For engineering managers evaluating AI coding tools, this structural difference matters more than feature comparisons, UI preferences, or even model quality. The tool that enables the most experimentation will produce the most capable engineers. Everything else is secondary.

Let's set aside the engineer working inside a company for a moment.

To truly become proficient with AI coding agents, you need to be all-in. You need to build side projects. Play. Experiment. Fail in low-stakes environments. Enjoy the process. This isn't optional -- it's a fundamental part of how people develop new technical skills.

Think about how developers learned to code in the first place. Most didn't learn exclusively through their day jobs. They built personal projects on weekends. They contributed to open source. They hacked on things that had no business value, purely because they were curious. The unstructured experimentation is where the deepest learning happens.

The same is true for AI-assisted coding. The engineer who only uses AI tools during work hours, on work tasks, with work constraints, will develop a narrow and cautious relationship with the tool. The engineer who also builds side projects with it -- who uses it to build a personal website, automate their home, create a game for their kids -- develops a fundamentally deeper intuition.

But how can you expect someone to do this when they'd need to pay hundreds of dollars per month out of pocket?

This is where the pricing model becomes a barrier not just to professional development, but to personal development. A tool that costs $200/month and provides effectively unlimited usage enables after-hours experimentation. A tool that requires per-token payment for heavy usage puts personal learning behind a paywall.

On February 1, 1980, Apple president Mike Scott issued an internal memo with the subject line "YOU ALL BETTER READ THIS."

The contents? An immediate, company-wide ban on purchasing or leasing typewriters.

At the time, Apple was developing word processing software -- but many of Apple's own employees still used typewriters for daily correspondence. Scott's reasoning was simple and forceful: "Let's prove it inside before we try and convince our customers."

The policy wasn't just prohibitive. It was incentivized. Engineers who surrendered their typewriters and switched to Apple II systems received first priority on new high-performance hardware. Apple didn't just remove the old tool -- they made adopting the new tool the path of least resistance and greatest reward.

This is the inverse of what most companies do today with AI coding tools.

Most companies add AI tools as an option alongside existing workflows, then wonder why adoption is slow. Apple understood something in 1980 that remains true in 2026: adoption doesn't happen by making the new tool available. It happens by making the old way unavailable -- or at minimum, by making the new way so frictionless and well-resourced that choosing the old way feels like swimming upstream.

The companies that will win the AI transition aren't the ones that give their engineers a Cursor license and call it done. They're the ones that:

1. Provide unrestricted access to the most capable AI coding tools
2. Remove friction from experimentation (no approval processes for trying new approaches)
3. Accept temporary productivity dips as the expected cost of learning
4. Reward early adopters with recognition and influence over team practices
5. Make the old way harder -- if you're still writing boilerplate by hand when an agent could generate it, that's a process problem worth discussing

Here's the honest, unvarnished message for anyone who wants their engineering team to work effectively with AI coding tools:

Your engineers must feel free to use, make mistakes, and experiment. Yes, even at the cost of short-term productivity. Yes, even on side projects that aren't directly related to their work tasks. Because that's how learning works.

There are no magic solutions. You don't purchase a coding agent subscription and immediately get 10x productivity. Anyone selling you that outcome is selling you a fantasy.

What actually happens is messier and more human than that:

• Week 1-2: Excitement mixed with frustration. The agent doesn't understand the codebase. Prompts are too vague or too specific. The engineer alternates between "this is amazing" and "this is useless."
• Month 1-2: The learning curve. Productivity may actually decrease as engineers learn new workflows. This is the danger zone where managers panic and restrict access.
• Month 3-4: Inflection point. Engineers who had unlimited access start to develop genuine fluency. They stop fighting the tool and start thinking through it.
• Month 6+: The compounding effect. Fluent engineers don't just code faster -- they think differently. They tackle problems they wouldn't have attempted before. They architect systems with AI collaboration baked into the design.

The critical insight: the timeline above only works with unrestricted access. Cap the tokens, and Month 3-4 never arrives. The engineer stays stuck in the frustration phase, concludes "AI coding tools don't really work," and reverts to manual workflows. You spent the money on the license and got nothing back.

Here's the closing thought that keeps me up at night.

In the Yale surgical study, the damage was visible and immediate. An injured gallbladder. Burned tissue. A surgeon stuck mid-operation. You could see the consequences of restricted training in real time.

With code, the damage is invisible.

An engineer who hasn't developed fluency with AI tools writes code that works but is subtly worse than what they could have produced. The architecture is more brittle. The edge cases are less well-covered. The tests are less comprehensive. The technical debt accumulates silently. Nobody looks at a pull request and thinks "this would have been better if the engineer had more token access." But the aggregate effect, compounded across a team and across months, is the difference between a codebase that enables velocity and one that slowly buries you.

The cost of restricting AI tool access isn't visible in any individual sprint or any individual PR. It's visible in the gap between where your team is in six months and where they could have been.

The surgeons who harmed patients weren't bad surgeons. They were undertrained surgeons.

Your engineers who aren't delivering on the promise of AI tools aren't bad engineers. They're undertrained engineers.

The question is whether you're willing to invest in the simulator time.

• Seymour et al., "Virtual Reality Training Improves Operating Room Performance" - Annals of Surgery, October 2002. The landmark Yale study referenced throughout this post.

• EDN, "Apple memo declares 'No more typewriters,' February 1, 1980" - Original reporting on Mike Scott's internal memo.

• Claude Code Pricing - Anthropic's current pricing model for Claude Code.

• Claude Code vs Cursor: A Technical Leader's Guide to Making the Right Choice for Your Organization - Deep dive into architecture, security, and organizational decision-making between the two tools.
• The Reality of AI-First Coding That Nobody's Telling You About - Honest assessment of the learning curve and what it takes to become fluent.
• What AI-First Development Reveals About Our Broken SDLC - How AI-first development exposes cracks in traditional software development lifecycles.
• Hiring in the AI Era: Why Recruitment Methods Always Lag Behind Technology - The organizational side of AI adoption, including how hiring practices lag behind tooling shifts.
• Will AI Replace All Engineers? Why Companies Will Want More Engineers, Not Fewer - Why AI tools increase demand for engineers rather than replacing them.

Sahar Carmel is the founder of Squid Club, a community of AI-first practitioners building with intelligent agents. He has guided dozens of engineering teams through AI tool adoption and previously built 10+ production AI agents at Flare.