AI Agents on Shane's Personal Blog

Cursor Is Brilliant—And Here's Why I Still Hate Using It

Fri, 19 Dec 2025 00:00:00 GMT

Let me tell you about the $600 burnout.

Two-thirds through the month, I’d already exhausted my Cursor quota. Not because I was being careless—I was just doing my job. Eight hours a day of building features, reviewing code, tweaking implementations. The kind of work that requires a senior engineer who cares about type-strict Python, modular architecture, and maintainable systems.

I sat there, staring at the “upgrade to pay-as-you-go” prompt, feeling something I hadn’t expected: exhaustion mixed with resentment. Cursor is brilliant. Its retrieval system finds scattered dependencies across your codebase like magic. Its context understanding makes other tools feel prehistoric. It rarely fails.

And yet, in that moment, I realized I’d been fighting it for weeks.

This isn’t a typical tool review. I’m not here to crown a winner or tell you what to buy. I’m a full-stack engineer running an AI startup, with a master’s in ML and strong opinions about code quality. I need tools that respect my judgment, not override it. What I learned using Cursor, Windsurf, and Claude Code for months revealed something more interesting than “which is best”—it exposed two fundamentally different philosophies about what AI-assisted development should be.

The Problem Nobody Talks About: Cognitive Predictability

Here’s what every review misses about pricing.

Cursor shows you token burn in real-time. Seems transparent, right? Except I had no idea what it actually meant. How much does a refactor cost? A feature implementation? A complex architectural change? The numbers were visible but meaningless.

I’d hesitate before exploring ideas. “Should I ask it to try this approach, or will that burn through my quota?” That hesitation—that’s the real cost. Not the dollars, but the cognitive overhead of constantly calculating whether a thought is “expensive enough” to pursue.

Then I tried Windsurf again.

Their pricing model is almost boring in its clarity. Every model has an explicit credit multiplier. Opus uses 3x credits. The million-token Sonnet? 10x credits. You know before you ask whether something will be expensive. Within a week, I’d internalized the pattern: roughly $10 per day of normal development work.

I set up auto top-up and stopped thinking about it entirely.

The psychological difference was striking. Not because Windsurf was cheaper—at similar usage intensity, they cost about the same. But because I could predict it. My brain could offload that worry and focus on the actual work. Cursor’s opacity created a constant background anxiety that I didn’t even notice until it was gone.

Opaque pricing doesn’t just affect your budget. It affects your thinking.

When Smart Tools Fight Smart Developers

I need to be precise about something: Cursor rarely makes mistakes. Its code is usually correct. Its suggestions are often clever. This isn’t about technical failure—it’s about something more subtle.

Let me show you what I mean.

My entire codebase uses single-line docstrings. Every function, every class—just a concise description of what it does. I’m strict about type hints at the function signature level, no type decorations cluttering the docstrings. When I use Pydantic models, that’s the pattern everywhere. The codebase is screaming its conventions at you.

Windsurf sees this and follows it. New code matches existing patterns. If the codebase uses Pydantic, the new feature uses Pydantic. If docstrings are single-line, they stay single-line. It treats your codebase as the source of truth.

Cursor sees this and… ignores it.

Unless I explicitly prompt “use single-line docstrings,” it generates multi-line ones. Even when literally every surrounding function uses single-line format. It wants to write tests. It wants to generate summary documentation. It has opinions about how code should look, and those opinions override what your project is telling it.

You can fight this with prompting. Every time I carefully articulate what I want to build, I also have to remember to say: “Follow the existing code style. Use single-line docstrings. Use Pydantic. Match the type hint patterns.” It’s like having a brilliant colleague who needs to be constantly reminded that they’re not working on their own project.

This creates an exhausting loop. I word my intent carefully, expecting a thoughtful proposal. Instead, Cursor immediately jumps to code editing, applying its global style defaults. I have to stop it, reassert constraints that should be obvious from the codebase, and restart. The tool itself becomes part of my cognitive load.

Here’s what makes this particularly frustrating: this behavior makes sense for beginners. If you’re learning, opinionated defaults teach good practices. The problem is that Cursor optimizes for the median developer—someone who needs guardrails. For senior engineers with established patterns and strong preferences, those same guardrails become chains.

I don’t want my tools to have opinions about my code style. I want them to learn mine.

The One Thing Cursor Actually Gets Right

I need to be fair here, because Cursor’s retrieval system is genuinely impressive.

When you ask Cursor a question about your codebase, it shows you its search in action. That “searching…” indicator isn’t just UI polish—it’s reflecting a powerful RAG system finding relevant context. It’s explicit, visual, and frequent. You can almost watch it think.

This makes Cursor exceptional at project-wide planning. Need to implement a feature that touches multiple services? Cursor finds the scattered pieces, understands the dependencies, and gives you a coherent proposal. It’s like having a colleague who’s memorized your entire codebase.

Windsurf has “Quick Context,” but it’s rarely invoked automatically. You have to explicitly ask for it, and even then, it feels more like keyword search than semantic retrieval. Fast, yes. But less powerful. Sometimes it traces files instead of actually searching for concepts.

The frustrating part? Cursor’s strength is also its weakness. Because the search is so opinionated and automatic, you can’t always tell when to trust it. I’ve had Cursor confidently delete code because its search didn’t find a feature—even though that feature existed and was important. When I catch this happening, I have to tell it: “Read the whole file, don’t search.” But sometimes it searches anyway.

This perfectly captures Cursor’s philosophy. The system is smart enough to be useful and opinionated enough to override you. For exploration and architecture planning, that’s valuable. For careful implementation of critical code, it’s dangerous.

The Mental Load You Don’t Notice Until It’s Gone

There’s a specific kind of frustration that’s hard to articulate. Not anger—more like background static.

With Cursor, I’m always aware I’m using Cursor. Will this prompt be expensive? Did it follow my style? Is it about to apply its defaults? Should I stop it before it generates tests I didn’t ask for?

With Windsurf, I think about the code.

That’s it. That’s the difference.

Windsurf occasionally hangs on tool calls—running multiple commands in parallel sometimes causes the first few to never stop. That’s a real bug, purely in their execution engine. But you know what? It doesn’t frustrate me the same way Cursor’s behavior does.

Because when Windsurf fails, it’s failing while trying to do what I asked. When Cursor frustrates me, it’s succeeding while doing something I didn’t ask for.

There’s a principle here: reliability without respect isn’t helpful. Cursor is more reliable technically—I rarely see it actually crash or error out. But Windsurf respects my intent more deeply. Given the choice between a tool that works perfectly but fights me constantly, and a tool that occasionally stumbles but fundamentally aligns with my goals… I’ll take the latter.

What Actually Matters: The Model, Not the Wrapper

Here’s something that took me months to realize: code quality comes from the model, not the IDE.

Claude Opus generates excellent code. Clear structure, proper types, handles edge cases well. Usually one or two iterations to get exactly what you want—assuming your prompt is clear. (Nothing can save you from bad prompting, by the way.)

Claude Sonnet is faster but noticeably weaker on complex type systems. It struggles with Python generics. Makes more syntax errors. For planning and proposals, it’s fine. For implementation of type-strict, high-quality code, it’s inadequate.

The IDE’s job should be simple: stay out of the model’s way. Let Opus be Opus. Let Sonnet be Sonnet. Provide context, handle tooling, then step back.

Cursor doesn’t step back. It wraps the model in layers of prompt orchestration. Forces conventions, generates extra artifacts, enforces style. Sometimes this improves the output for beginners. For experts, it degrades what the model could have produced on its own.

This is why I find myself switching back to Windsurf when I need serious, production-quality code. Not because Windsurf is smarter—it’s not. But because it trusts the model enough to mostly leave it alone. I get closer to what Claude Opus is actually capable of, without an IDE’s opinions interfering.

Why I Use Both (And Why You Might Too)

After months of frustration, experimentation, and honest assessment, here’s what I’ve learned:

I use Cursor for exploration. When I’m starting a new feature, trying to understand how different parts of the codebase connect, planning architecture—Cursor’s RAG system is unmatched. It’s worth the mental overhead for that initial phase. I get a clear map of what needs to change and why.

Then I switch to Windsurf for implementation. When I know what needs to be built and I need it done right—clean types, consistent style, modular structure—Windsurf respects my codebase’s patterns. The code it generates fits naturally into what already exists.

And when I’ve burned through quotas on both? Claude Code becomes the fallback. All-or-nothing interaction, but at least it’s thinking is sharp. I can’t edit incrementally, but for architectural decisions or complex reasoning, it still delivers.

This isn’t indecision. It’s pragmatism. Different tools for different phases of work.

The uncomfortable truth is that neither Cursor nor Windsurf is “better.” They represent fundamentally different philosophies about what AI assistance should be. Cursor is productized intelligence—heavily orchestrated, optimized for consistency across millions of users, opinionated by design. Windsurf is model-first intelligence—thinner abstraction, codebase-driven behavior, fewer guardrails.

If you’re a beginner or working on unfamiliar territory, Cursor’s opinions help you. If you’re a senior engineer with strong preferences and established patterns, those same opinions fight you.

The IDE I Actually Want to Use in Five Years

Right now, we’re in the hype phase. Everyone’s building “AI agents” and treating prompts like trade secrets. Cursor hides its orchestration entirely. Windsurf is more transparent but still opaque. We’re supposed to trust these black boxes because AI is magic and mysterious.

But the hype will fade. It always does. And when developers start caring more about productivity than novelty, something will shift.

The winning IDE won’t be the smartest. It’ll be the most honest.

I want an IDE that completely exposes its agent prompts. Not just makes them accessible if you hack around—actually shows them to you. In the UI. As first-class configuration. “Here’s what I’m telling the model. Here’s the context I’m injecting. Here’s the style guidance I’m applying. Change any of it.”

Full customizability. Per-project preferences. Per-user behavior profiles. Even AI-assisted prompt tuning—let me tell the IDE “be more like Windsurf” and have it adjust its orchestration accordingly.

This isn’t radical. It’s just taking developers seriously. We’re the users. We understand prompts. We can handle complexity. Stop treating us like consumers who need hand-holding and start treating us like engineers who need control.

The best AI IDE won’t have opinions. It will learn yours.

What This Means for You

If you’re evaluating these tools, here’s what actually matters:

Choose Cursor if:

You’re learning or working in unfamiliar domains
You need powerful project-wide context and planning
You’re okay with opinionated defaults and can work within them
You have predictable, moderate usage patterns

Choose Windsurf if:

You’re a senior engineer with strong style preferences
You prioritize code quality and codebase consistency
You want transparent, predictable pricing
You’re willing to manually invoke context when needed

Choose both if:

You do complex, multi-phase development work
You can afford the cognitive overhead of switching
You value exploration (Cursor) and implementation (Windsurf) differently

But here’s the deeper insight: don’t evaluate AI IDEs like you evaluate programming languages or frameworks. Evaluate them like you evaluate working relationships. Does this tool respect your expertise? Does it impose cognitive overhead or reduce it? Does it amplify your thinking or fight your intent?

Because we’re not just choosing tools anymore. We’re choosing collaborators. And the best collaborators aren’t the smartest—they’re the ones who know when to lead and when to follow.

I still use Cursor. I still get frustrated by it. I still pay the bills.

But I know now what I’m paying for: powerful intelligence that comes with the cost of constant negotiation. Some days, that’s worth it. Other days, I need a tool that just… builds what I asked for, the way I asked for it.

The future of AI-assisted development isn’t about building smarter agents. It’s about building more honest ones. Tools that expose their assumptions, respect our preferences, and understand that control isn’t the opposite of intelligence—it’s a requirement for trust.

Until then, I’ll keep both IDEs open. And keep fighting for the code I actually want to write.

(Written by Human, improved using AI where applicable.)

Predictable Agent Trajectories: Agent Trajectories as Retrievable Context

Mon, 29 Sep 2025 00:00:00 GMT

TL;DR

Here’s the gist: AI agents keep wandering off track because they don’t have a good way to remember what worked before. So instead of retraining them every time (which costs a fortune), we give them a smart memory system that learns from past successes.

The Problem: Agents start strong but drift away from what you actually wanted
The Solution: Let them look up “how we solved this before” from a library of successful attempts
The Magic: They get better at staying focused without expensive retraining
The Result: Agents that actually learn from experience and keep improving

Key Terms (Don’t Worry, It’s Not That Complicated)

Agent Trajectories: Think of these as detailed “success stories”—complete records of how an agent nailed a problem, including every step, tool, and decision that led to victory.
Trajectory Extraction: The process of taking messy real conversations and turning them into clean, reusable game plans that other agents can learn from.
Traditional RL Approaches: The expensive way to make agents better—methods like VERL that basically rebuild the agent’s brain through retraining.
ATRC (Our Approach): Instead of brain surgery, we give agents a smart librarian who can instantly find the best “here’s how we solved this before” examples.

The Recipe Box Problem

Picture this: You’re trying to teach your brilliant but absent-minded friend how to cook. They can follow any recipe perfectly—when they actually stick to it. But here’s the thing: give them something vague like “make something Italian for dinner,” and watch the chaos unfold. They’ll start with pasta, get distracted and pivot to pizza halfway through, then somehow end up attempting risotto with the leftover pizza dough. By the end, you’re both staring at this… creation… wondering how “Italian dinner” turned into whatever the hell that is.

Sound familiar? This is exactly what happens with AI agents today. They’re brilliant at following specific instructions, but throw them a curveball—something ambiguous or multi-step—and they start strong but then just… drift. One tiny misinterpretation snowballs into another, and suddenly your agent is solving a completely different problem than what you actually asked for.

But what if we could give agents a “recipe box” of proven strategies? Not hardcoded into their training, but something they could flip through whenever they needed guidance. What if they could actually learn from past wins without the whole expensive retraining song and dance?

That’s exactly what Agent Trajectories as Retrievable Context (ATRC) does.

The Core Insight: Smart Memory Beats Expensive Brain Surgery

Here’s the thing about traditional approaches like VERL: they improve agents by literally retraining the models. It’s like sending your chef friend to culinary school from scratch every time you want them to get better at Italian food. Sure, it works, but you’re talking massive computational resources, weeks of training time, and a budget that’ll make your CFO cry.

ATRC takes a completely different approach. Instead of rewiring the agent’s brain, we just give it access to a really smart memory system.

Here’s the kicker: most agent systems are already collecting Agent Trajectories—those complete records of successful problem-solving sessions. That’s not new. What’s new is treating these like a RAG system, dynamically pulling up the best examples when needed, all weighted by real user feedback.

Picture it this way: instead of shipping your friend off to culinary school every time they botch dinner, you give them a smart recipe box. This thing finds recipes similar to what they’re trying to make, prioritizes the ones that actually worked for other people, and updates its recommendations based on whether folks were happy with the results.

The magic moment? When your friend says “make something Italian,” the recipe box doesn’t just grab any random Italian recipes. It finds the ones that people actually nailed, weighted by recent success stories and filtered for your current situation—dietary restrictions, what’s in your fridge, how much time you’ve got.

How This Actually Works

The Two Main Parts

ATRC has two components that tag-team to make agents smarter:

1. The Smart Note-Taker (Trajectory Extraction) Imagine having a really good assistant who watches every successful interaction and turns it into a clean, reusable “recipe card.” When an agent nails a task, or when you give helpful feedback mid-conversation, a small language model with tons of context takes that messy real-world interaction and converts it into something structured that future agents can actually use.

It’s like turning “I fumbled around for three hours and eventually figured out how to migrate the database without breaking everything” into “Database Migration Recipe: 1) Backup verification, 2) Schema mapping, 3) Small batch test, 4) Full migration with rollback plan.”

2. The Smart Librarian (Retrieval Module)
This works like those document search systems you’ve probably heard about, except instead of finding documents, it digs up the most relevant Agent Trajectories. When facing a new task, it searches through past wins using four key factors:

Relevance: How similar is this to what I’m trying to do right now?
Quality: Did users actually like this approach, or did it suck?
Recency: Is this still relevant, or is it outdated advice from 2019?
Diversity: Can I get different angles instead of the same approach five times?

The Feedback Loop That Actually Works

Here’s how the whole thing comes together:

Capture: Agent finishes a task → Smart Note-Taker turns it into a reusable recipe
Store: Recipe goes into the database, tagged with how happy users were
Retrieve: New task comes in → Smart Librarian finds the best matching recipes
Guide: Agent uses these recipes as inspiration (not rigid rules) to plan its approach
Learn: User feedback updates how often each recipe gets recommended

The beautiful part? Recipes that actually make users happy get pulled up more often, so the system naturally evolves toward better strategies. No manual curation needed—just let success breed more success.

The Multi-Turn Challenge: When Everything Changes Mid-Flight

Here’s where things get really interesting. Most systems work great when life is simple: you ask → agent plans → agent executes → done. But real conversations? They’re a hot mess. Users change their minds, files get updated, new constraints pop up halfway through—you know, actual real life.

It’s like texting your friend directions to a restaurant, but halfway there you’re like: “Actually, forget that place, let’s hit up that new sushi spot instead. Oh, and can you grab my prescription on the way?” Traditional systems would either completely ignore your update or just give up and start over from scratch.

How ATRC Handles the Chaos

ATRC deals with this mess using three clever tricks:

1. The Living Briefcase Picture the agent carrying around a briefcase full of current context—requirements, file versions, constraints, the works. When something changes, it doesn’t chuck the whole briefcase and start fresh. It just swaps out the old stuff for the new stuff. File got updated? Replace the old version. User changed their mind about requirements? Update the goals. The agent keeps rolling with fresh context.

2. Real-Time Note-Taking
When you throw a curveball mid-task (“Oh wait, make sure it handles international addresses too”), the Smart Note-Taker immediately converts your clarification into a new mini-plan. This gets swapped into the agent’s briefcase as updated guidance, and boom—the agent pivots without missing a beat.

3. Smart Course Correction Instead of replanning the entire mission from scratch, the agent just tweaks the next few steps based on what changed. It’s like your GPS recalculating just the remaining route when traffic gets weird, not making you drive back to your starting point.

The result? Agents that actually roll with the punches instead of having a meltdown every time something changes.

Real-World Example: The Data Migration That Actually Worked

Let’s talk data migrations—you know, moving customer data between systems. It’s the kind of critical work that keeps you up at night because there are about a million ways it can go sideways.

Before ATRC: Every Migration is a Fresh Hell

Each engineer just wings it their own way
The same mistakes get repeated over and over
When someone figures out a great approach, it dies with them when they leave
Mid-migration disasters trigger full panic mode and frantic Slack messages

With ATRC: Actually Learning from Success

First Win Gets Captured: Someone finally nails a migration perfectly—backup verification, small batch test, incremental migration in chunks, rollback plan locked and loaded. The Smart Note-Taker turns this success into “Migration Recipe A: Conservative but Rock-Solid.”

The Playbook Grows: After several migrations, you’ve got different proven approaches:

“Conservative” (slow but bulletproof)
“Fast-track” (risky but gets shit done)
“Hybrid” (the sweet spot)

Smart Retrieval in Action: New urgent request drops—200,000 records, impossible deadline. The Smart Librarian finds similar past migrations, weighs them by how happy people were with the results, and recommends the “Hybrid” approach since it’s got the best track record for urgent large-scale stuff.

When Things Go Sideways: Halfway through, you discover corrupted data that needs cleaning. Traditional systems would either panic or just plow ahead and hope for the best.

ATRC? The Smart Note-Taker recognizes this as a data quality issue, finds migration recipes that handled cleaning before, swaps in those steps, and keeps trucking.

The Result: Migrations go from nail-biting adventures to following proven playbooks that actually adapt when reality hits.

What Can Go Wrong: The Challenges

Like any system that isn’t completely terrible, ATRC has some real challenges to wrestle with:

The Popularity Contest Problem

Popular tasks can completely drown out the rare but important stuff. It’s like having a recipe box that only ever shows you pasta dishes because that’s what most people cook—you’d never rediscover that incredible but uncommon Thai curry recipe that actually blew everyone’s mind.

The Fix: Keep different types of tasks in separate buckets, and make sure older successes gradually fade out (because let’s be honest, the world changes fast).

The Stale Context Trap

Files change, APIs evolve, requirements shift. A recipe that was absolutely perfect six months ago might fail spectacularly today if it’s still referencing some API endpoint that doesn’t exist anymore.

The Fix: The “Living Briefcase” approach tracks versions of everything and swaps in fresh context when things change. No more “why is this calling the old payment API?” moments.

The Gaming Problem

If people know their feedback affects what gets recommended in the future, some will definitely try to game the system—inflating ratings to push their favorite approaches or tanking ones they don’t like.

The Fix: Focus on objective success metrics (did it actually work?) alongside user satisfaction, and keep track of who’s giving reliable feedback versus who’s just being political.

Where ATRC Actually Makes a Difference

ATRC really shines in a few key areas:

Repetitive Expert Work: Tasks that need real expertise but follow recognizable patterns—code migrations, data transformations, system configurations. Perfect for building up a library of “how the people who actually know what they’re doing handle this.”

High-Stakes Operations: When screwing up costs serious money and you really need to learn from what worked before. Think financial processing, medical protocols, legal document review—stuff where “oops” isn’t really an option.

Team Knowledge Capture: Preventing that awful “brain drain” when your best people leave. Their successful approaches stick around in the system for the next person to learn from, instead of walking out the door with them.

Fast-Moving Fields: Areas where best practices change constantly—API integrations, cloud deployments, that kind of thing. ATRC captures what’s working right now and gradually phases out the stuff that’s become obsolete.

The Future: Agents That Learn from Each Other

Here’s where this gets really exciting: imagine agent communities that actually learn from each other. With the right privacy controls, successful strategies could be shared across teams, companies, even entire industries. Your data migration agent could learn from patterns that worked for similar companies. Your customer service agent could pick up approaches that killed it in adjacent domains.

The technical pieces are already here. What we need now is the discipline to build these systems thoughtfully—with real safeguards for privacy and quality control, not just the “trust us, it’s fine” approach.

Getting Started

Want to try ATRC? Start simple:

Pick One Thing: Choose something your agents handle regularly—don’t try to boil the ocean
Document Some Wins: Manually capture 5-10 successful completions and what made them work
Build Basic Lookup: Start with simple text matching plus some quality weighting
Try Dynamic Updates: Experiment with swapping context when requirements change mid-task
Actually Measure Stuff: Track success rates and how often agents wander off into the weeds

The goal isn’t perfection—it’s building a feedback loop where agents measurably get better at staying focused and learning from what actually worked.

The Recipe Box Revolution

ATRC changes how we think about making AI better. Instead of burning cash on retraining every time agents screw up, we give them access to a smart memory of what actually worked.

It’s like giving every agent a constantly-improving cookbook—not rigid rules they have to follow, but inspiration from proven wins. The insight here isn’t some complex technical breakthrough, it’s actually pretty human: maybe the best way to improve AI isn’t making models smarter, but making them better at learning from collective success.

Your agents don’t need to start perfect. They just need to get good at learning from what works. ATRC gives them that ability, one successful attempt at a time.

Simple concept, powerful results. Your agents stay focused, your users stay happy, and everyone learns from success instead of repeating the same damn mistakes over and over. Sometimes the best innovations aren’t about building something completely new—they’re about organizing what we already know in ways that actually make sense.