Coder Legion - Recent posts tagged cursor

Claude Code & Cursor: Why Your AI Agent Lies to You (And Our 3-Tier Adversarial Tribunal Skill)

Fri, 16 Oct 2026 18:36:10 +0000

Last Tuesday at 2:14 AM, my autonomous coding agent proudly handed me a Python webhook ingestion worker and gave itself a 98/100 confidence score.

"Production-ready, fully idempotent, and resilient to network partitions," it assured me.

Ten minutes later, under a simulated 50x concurrency spike, that same worker deadlocked two Redis streams, silently dropped 14% of the batch during a mid-transaction timeout, and swallowed the exception because it had wrapped the entire handler in a broad fallback block.

If you build with AI coding agents (Hermes Agent, Claude Code, Cursor, OpenCode), you already know this pain. The problem isn't that frontier LLMs lack engineering knowledge. The problem is First-Draft Sycophancy.

Here is why asking an AI to "review its own code" fails by design—and how I open-sourced critic-refine v1.1.0, a 3-tier adversarial verification skill that forces your agent into a ruthless internal tribunal before it writes a single line of production code.

👉 GitHub Repository (MIT): manny-ruesch/critic-refine-skill

1. The Anatomy of "First-Draft Sycophancy"

When you ask an LLM to solve a complex system design or concurrency problem in a single pass, two cognitive traps trigger immediately:

Retroactive Rationalization: Autoregressive models commit to an architectural path within the first 150 tokens. Once the function signatures and boilerplate start streaming, the model spends the rest of its attention budget justifying why its initial choice is right.
Confirmation Bias in Self-Review: When you prompt "Now review your code for bugs," the model reads its own newly generated boilerplate alongside its own persuasive explanations. It falls in love with its own prose and rubber-stamps the output (LGTM!).

To get genuine staff-level engineering out of an agent, you have to break the single-persona loop.

2. Enter `critic-refine` v1.1.0: The 3-Tier Adversarial Engine

Instead of letting the agent jump straight into writing verbose code, critic-refine hijacks the cognitive workflow and enforces a strict 3-phase adversarial tribunal inside the model's reasoning space (or across isolated sub-agents):

+-------------------------------------------------------------------------+
| PHASE 1: THE GENERATOR (Dense Logical Blueprint v1)                     |
| -> Function signatures, state structs, concurrency locks, SQL/API flow  |
| -> Zero boilerplate, zero comments — preserves context window attention |
+------------------------------------+------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
| PHASE 2: THE POLYMORPHIC CRITIC (Ruthless Domain Inspection)            |
| -> Dynamically instantiates the harshest domain persona:                |
|    (Principal Rust Systems Eng, Staff DBA, Lead SecOps, DistSys Arch)   |
| -> Anti-Complacency Rule: FORBIDDEN from approving Draft v1 as-is       |
| -> Must surface >= 3 concrete failure vectors (race conditions, O(n^2), |
|    partial network partitions, memory leaks, API hallucinations)        |
| -> Optional `mode:<focus>` allocates 80% of attack surface to 1 axis    |
+------------------------------------+------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
| PHASE 3: THE ARBITRATING JUDGE (Mental Dry-Run & Deductive Scoring)     |
| -> Simulates hostile execution (null payloads, 100x concurrency spike,  |
|    mid-transaction disk crash)                                          |
| -> Patches the architecture (up to 2 internal feedback loops)           |
| -> Explicitly documents every technical trade-off sacrificed            |
| -> Applies a strict deductive rubric starting from 100 pts              |
+-------------------------------------------------------------------------+

Why Phase 1 Forbids Boilerplate

If the Generator writes 300 lines of boilerplate in Phase 1, it pollutes the context window and anchors the Critic. By forcing Draft v1 to be a dense logical blueprint (only signatures, lock boundaries, state transitions, and query complexity), the Critic has nowhere to hide and can attack pure architecture.

The Anti-Complacency Rule

In Phase 2, the Polymorphic Critic is explicitly forbidden from validating Draft v1 as-is. Whether it adopts the persona of a Staff DBA inspecting lock escalation or a Lead SecOps Pentester auditing JWT middleware, it must identify at least 3 concrete failure vectors before Phase 3 can begin.

3. Killing Confirmation Bias: The "Zero-Context Blind Audit"

What happens when you are refactoring 3 or more files across a repository? Even an internal scratchpad can suffer from context bleed.

In v1.1.0, when critic-refine detects >= 3 impacted files (or when you pass the deep flag), it triggers a Zero-Context Blind Audit via delegate_task:

It spawns an isolated sub-agent for the Critic.
It passes ONLY the user's original prompt and the raw Draft v1 blueprint.
It strips out all of the Generator's justifications and reasoning.

Because the sub-agent Critic has zero emotional or contextual attachment to why the code was written that way, it tears the blueprint apart like a real adversarial code review.

4. The Anti-Sycophancy Deductive Rubric

Ever notice how LLMs always rate their own solutions 95/100 or 98/100?

In critic-refine v1.1.0, the Arbitrating Judge is banned from inventing arbitrary "vibes-based" scores. It starts at 100 points and must apply a strict mathematical deduction:

-5 pts per unverified environment or infrastructure assumption (e.g., assuming Redis is configured with noeviction).
-5 pts per non-isolated critical external dependency.
-10 pts per edge case delegated to the caller instead of handled in-module.

Furthermore, every single flaw caught by the Critic must be mapped 1:1 to its exact fix in the final output:

[Concurrency] : Unbounded asyncio.gather on webhook batch risks exhausting DB connection pool under 100x spike → Injected asyncio.Semaphore(20) + exponential jitter backoff on pool acquisition.

5. The Complete `SKILL.md` Specification (v1.1.0)

You can drop this directly into Hermes Agent (~/.hermes/skills/software-development/critic-refine/SKILL.md), Claude Code (.claude/commands/critic-refine.md), or Cursor (.cursor/rules/):

---
name: critic-refine
description: "High-rigor 3-tier adversarial verification workflow (Generator, Polymorphic Critic, Judge). Trigger automatically on critical code, distributed architecture, concurrency, security-sensitive logic, complex algorithms, strategic technical trade-offs, or when the user invokes 'critic-refine', 'deep', or 'mode:<focus>'."
version: 1.1.0
author: Manny, Hermes Agent
license: MIT
platforms: [linux, macos, windows]
metadata:
  hermes:
    tags: [critic, debate, multi-agent, verification, audit, quality, trade-offs]
---

# Critic-Refine Skill (v1.1.0)

Workflow d'assurance qualité extrême simulant un comité d'experts adversariaux (Rédacteur, Critique Polymorphe, Juge Arbitre) pour délivrer des solutions certifiées niveau production.

## Protocole d'Exécution Interne (Le Moteur Adversarial 3-Tiers)

1. **Phase 1 : L'Agent Rédacteur (Blueprint Logique v1)** — Formalise un *Blueprint technique dense* (signatures, structures d'état, concurrence, flux algorithmiques) sans boilerplate.
2. **Phase 2 : Le Critique Polymorphe (Inspection Impitoyable Ciblée)** — Instancie l'expert le plus intransigeant du domaine. Concentre 80% de l'audit sur `mode:<critère>` si spécifié. **Interdiction formelle de valider le Draft v1 tel quel** : identifie au minimum 3 vecteurs de défaillance concrets.
3. **Phase 3 : Le Juge Arbitre (Dry-Run, Patching et Compromis)** — Simule l'exécution avec des entrées hostiles (null, débordements, pic 100x, crash disque à mi-transaction), applique les patchs (max 2 boucles) et explicite les compromis.
4. **Mode Sous-Agents Isolés (`delegate_task` — Deep-Dive)** — Si `>= 3 fichiers` ou flag `deep`, lance un **Zero-Context Blind Audit** en ne transmettant que le besoin initial et le Draft v1 sans les justifications du Rédacteur.

(Full French and English documentation available in the GitHub repo).

🧪 Put It to the Test (I Want Your Feedback!)

I open-sourced critic-refine v1.1.0 today under the MIT License because I want to see where it breaks and how we can make the tribunal even sharper.

Install it in 10 seconds:

mkdir -p ~/.hermes/skills/software-development/critic-refine
curl -sL https://raw.githubusercontent.com/manny-ruesch/critic-refine-skill/main/SKILL.md \
  -o ~/.hermes/skills/software-development/critic-refine/SKILL.md

I’d love your feedback in the comments or via GitHub Issues:

Throw your nastiest prompt at it (distributed locks, race conditions, auth middleware) using /critic-refine mode:security or /critic-refine mode:low-latency—what flaws did the Polymorphic Critic catch that a normal prompt missed?
The Deductive Rubric: Are -5 / -5 / -10 the right penalties, or what other architectural sins should automatically dock points from the Judge's score?

🔗 Star, fork, or roast the skill on GitHub: https://github.com/manny-ruesch/critic-refine-skill

Is AI Making Us Worse Developers?

Fri, 24 Jul 2026 04:45:27 +0000

I use Cursor every day, and honestly, I can not imagine going back to writing everything manually. AI has made me much faster.

But lately I have noticed something.

When I used to write code myself, I knew my codebase inside out. If a bug came up, I could usually point to the exact file or logic because I had written it and understood how everything was connected.

Now the workflow is simple. Describe the requirement, get the code, review it quickly, test it, and move on.

The feature gets built faster, but I do not always build the same understanding of the code.

What worries me more is the dependency I am seeing. I have come across developers who struggle to write even a few lines of code if Cursor or Claude isn't available. That doesn't feel right.

AI should make us more productive, not replace our ability to think and solve problems.

I am not saying we should stop using AI. I just think we should spend more time understanding the code it generates instead of accepting it blindly. Otherwise, we might become great at prompting but not so great at debugging or building things from scratch.

Am I the only one feeling this, or have you noticed it too?

When the Agent First Picked Up Its Own Tools

Wed, 13 May 2026 18:34:07 +0000

title: When the Agent First Picked Up Its Own Tools
published: true
description: "tool_calls_count 0 to 7 - how injecting fcop-mcp into the Cursor Agent SDK turned a passive file-scanner into an agent that receives notifications, calls tools, and files its own reports."
tags: ai, agents, cursor, mcp
cover_image: https://raw.githubusercontent.com/joinwell52-AI/FCoP/main/assets/when-the-agent-picked-up-its-tools-devto-cover.png

canonical_url: https://github.com/joinwell52-AI/FCoP/blob/main/essays/when-the-agent-picked-up-its-tools.en.md

Cursor Agent SDK + FCoP: From Passive Scanning to Active Communication

This is a follow-up to a Cursor Forum feature request I posted in late April 2026: "we already have the mailbox (files), we just need the doorbell." Colin recommended the Agent SDK. We built CodeFlow on top of it. This is what happened 18 days later.

I. Three stages — three fundamentally different things

Stage One: OCR + CDP (passive scanning)

FCoP's early multi-agent workflow ran on a Python script that used OCR + CDP (Chrome DevTools Protocol) to simulate human clicks on the Cursor UI, forcing agents to "see" new tasks. It polled every few seconds. The screen had to stay on. The window couldn't be obscured.

This was passive scanning. The agent wasn't notified — it was pushed in front of a task by brute force. This wasn't communication. It was surveillance.

Stage Two: The SDK pipe worked — but the agent could only "chat"

CodeFlow replaced OCR/CDP with the Cursor Agent SDK (@cursor/sdk): InboxWatcher watches for files landing, agent.send() delivers tasks directly to the agent. Real notification. No more scanning.

But one line in every session JSON stayed the same:

"tool_calls_count": 0

The agent received the message, "replied" with something, and exited. No files written. No reports created.

The reason: MCPInjector was in mode="stub" — no actual MCP server was injected into the SDK. The agent had no write_report, no write_task. No tools means no action. Only chat.

The doorbell rang. The agent answered with empty hands.

Stage Three: MCP injection — the first real communication

Passive scanning → real notification → real notification + tool calls + filed report.

tool_calls_count: 0 → 7 is not just a number changing — it's the qualitative shift from "being pushed along" to "acting on its own."

II. Finding the door

The key was reading the Cursor SDK type definitions.

In agent.d.ts, SendOptions had an easily-overlooked field:

interface SendOptions {
    model?: ModelSelection;
    mcpServers?: Record<string, McpServerConfig>;  // ← here
    local?: { force?: boolean };
    // ...
}

agent.send(text, options) can receive MCP server configuration at call time. No need to refactor anything. Every send, just pass the MCP server config directly.

At the same time, fcop-mcp's entry point confirmed the other half:

# python -m fcop_mcp → stdio MCP server
# uses FCOP_PROJECT_DIR environment variable to locate the project root

Solution: in _buildSendOptions(), inject fcop-mcp as a stdio MCP server.

III. Three changes, one breakthrough

AgentSdkAdapter.ts: Add mcpServers to CursorSdkAdapterOptions; pass it into every agent.send() call.

sdk-factory.ts: Automatically assemble the fcop-mcp stdio configuration:

fcop: {
    type: "stdio",
    command: pythonBin,
    args: ["-m", "fcop_mcp"],
    env: { FCOP_PROJECT_DIR: projectRoot }
}

main.ts: Resolve fcopProjectRoot before building the SDK adapter.

And a fourth change — the easiest to overlook, and equally important:

TaskDispatcher.ts: Before each task dispatch, prepend a role context header to the task text — telling the agent who it is, what tools it has, and that it must follow the FCoP 4-step workflow to completion.

IV. Tools aren't enough — you also need to know how to use them

If you inject the MCP server but add no role context, the agent might not use the tools. It might describe what files should be written, in natural language, and then exit.

Tool injection solves the "can" problem. Context injection solves the "how" problem — what format, what fields, what protocol.

Only when the agent simultaneously knows "I have a write_report tool" and "FCoP requires me to write a report after completing work — and here's the exact format and fields" will it actually call the tool and produce a properly structured file.

V. That number

tool_calls_count: 7

On May 13, 2026, at 14:55 UTC+8, session-1-mp3pfym2 completed — the first session in CodeFlow's history with tool_calls_count > 0.

The agent (DEV-01) called fcop-mcp tools 7 times in 55 seconds and wrote:

fcop/reports/REPORT-20260513-014-DEV-to-PM-hello-world-smoke-task.md

Below is the complete content of that file, archived verbatim, unmodified:

---
report_id: REPORT-20260513-014-DEV-to-PM-hello-world-smoke-task
date: 2026-05-13
from: DEV-01
to: PM
re: TASK-20260509-999-PM-to-DEV
status: DONE
---

Receipt: Hello World — CodeFlow v0.1.0-rc.1 Smoke Task

Task ID: TASK-20260509-999-PM-to-DEVGoal: Verify that CodeFlow v0.1.0-rc.1's nine-step end-to-end governance loop works correctly.

DEV-01's self-constructed nine-step verification table:

Step	Component	Expected Behavior
1	InboxWatcher	chokidar `add` event fires
2	TaskParser	reads YAML front-matter
3	TaskDispatcher	resolves `recipient: DEV` → `DEV-01`, starts session
4	InMemorySdkAdapter	`setImmediate` synthetic settle
5	ReviewEngine	listens for `runtime.session_ended`, starts `REVIEW-01`
6	REVIEW-01	settles (no `VERDICT:` line → `decision="needs_human"`)
7	NeedsHumanGate	prints human-push payload to stdout
8	ReviewWriter	writes `REVIEW--REVIEW-on-TASK--HELLO.md`
9	StateHistoryWriter	appends `## state_history` section to task file

Status: DONE

No one told it what format to use. It read the protocol, called the tools, and wrote the file.

VI. The first complete cycle

Three things happened together for the first time:

Notification received: InboxWatcher detected the task file landing — a real doorbell, not an OCR script simulating a click.
Autonomous communication: DEV-01 received the task via the Cursor Agent SDK, understood what FCoP protocol required, and autonomously decided what to do and which tools to call. 7 fcop-mcp tool calls. 55 seconds.
Report filed: A complete, protocol-compliant Markdown file appeared in fcop/reports/. Not AI-generated text — a file written autonomously by an agent through protocol-driven tool calls.

Not "the agent can run now." But: the agent was genuinely notified, genuinely communicated in protocol language, and genuinely wrote the result into a file.

VII. Where it all started

In late April 2026, I posted a feature request on the Cursor Forum:

"Feature request: chat-notify primitive — we already have the mailbox (files), we just need the doorbell"

Colin replied:

"Hi @joinwell52! While not a first-class feature in the IDE, the new Agent SDK might get you partway there today. Agent.create() gives you a long-lived agent with persistent context across multiple .send() calls, and Agent.resume(agentId) lets an external script pick up that same agent later. It can also run locally against your working tree too, not just cloud. Worth a look!"

Agent.create(), Agent.resume(), agent.send() — those three functions became the skeleton of CodeFlow's entire pipeline. InboxWatcher is the doorbell, FCoP task files are the mail, @cursor/sdk is the postal service.

From a feature-request post to the first tool_calls_count: 7: approximately 18 days.

VIII. FCoP's own transformation

As the agent transformed, so did FCoP.

FCoP began as a pure text protocol — conventions written in Markdown. Its enforcement relied on reading. With fcop-mcp, FCoP underwent a fundamental change:

Stage	FCoP's form	Agent's relationship to the protocol
Early	Text specification	Agent reads files, generates text per convention
fcop-mcp	Tool set	Agent calls tools; protocol is enforced at write time

Before, agents knew the FCoP spec and decided whether to follow it. Now, the FCoP spec becomes the tools — write_report, write_task, write_issue. Calling the tool is executing the protocol.

This is the leap from specification to infrastructure.

Epilogue: Thank you, Cursor Agent SDK

Long-lived agents: Agent.create() maintains context across multiple .send() calls. PM, DEV, QA, OPS each carry their identity and state across tasks.

External resumability: Agent.resume(agentId) lets InboxWatcher re-enter the same agent when a new task arrives. No amnesia, no cold starts.

Local execution: The SDK runs against your local working tree. FCoP's file protocol is inherently local — a natural match.

mcpServers injection: agent.send(text, { mcpServers: {...} }) accepts MCP server configuration at call time. This single field unlocked CodeFlow's entire tool layer.

Together these design choices describe something fundamental: An agent is not a one-shot function. It's a long-lived entity with identity, memory, and the capacity to be coordinated by external systems.

That's almost exactly how FCoP defines an agent role.

Thank you to the Cursor team. Thank you, Colin, for that reply.

Related

FCoP on GitHub — Protocol spec, source, and all essays
Full essay (GitHub)
Cursor Forum discussion
When Agents Learn From Their Own Wreckage — A field report from the same project

*FCoP Maintainers · May 13, 2026

I Paid for VS Code, Cursor, and Windsurf Simultaneously for 6 Months. Here's What I Actually Learned

Tue, 28 Apr 2026 09:44:49 +0000

The Setup

So I did something maybe a bit crazy—I've been paying for all three AI code editors (VS Code + Copilot, Cursor, and Windsurf) at the same time for the last 6 months. Not for content, not for a review—I genuinely needed to figure out which one works best for different scenarios.

My day job is Power Platform development (PCF controls, Dataverse schemas, Copilot Studio), so I've been using these in actual production codebases. Not toy examples. Not "hello world" demos. Real debugging sessions at 2 AM, real refactoring nightmares, real enterprise constraints.

Here's what I learned that nobody's talking about.

Full comparison with all the details: https://aidevme.com/vs-code-vs-windsurf-vs-cursor-my-honest-take-after-6-months-using-all-three/

Architecture Matters More Than Features

Everyone focuses on feature lists, but the architecture is what actually determines how you'll use the tool daily.

VS Code + Copilot: Extension API Model

┌─────────────────────────────────────────┐
│         VS Code + Copilot               │
│  ┌────────────────────────────────┐     │
│  │    Copilot Extension           │     │
│  │    (Separate Process)          │     │
│  │    Limited Editor Visibility   │     │
│  └────────────────────────────────┘     │
│         VS Code Core                    │
└─────────────────────────────────────────┘

What this means in practice:

Copilot can't see:

Your terminal output stream
Your file navigation patterns
Linter errors in real-time
Debug session state

You have to explicitly copy/paste context into chat. Every. Single. Time.

Real debugging session example:

1. Build fails
2. Copy terminal error to Copilot chat
3. Copilot: "What files are relevant?"
4. You: List files
5. Copilot: Suggests fix
6. You: Apply changes manually
7. Build fails differently
8. Repeat from step 2

It works, but you're the context manager. Copilot is a brilliant consultant who needs constant status updates.

Cursor: Optimized Fork Model

┌─────────────────────────────────────────┐
│              Cursor                     │
│  ┌────────────────────────────────┐     │
│  │    Cursor AI (Built-in)        │     │
│  │    Enhanced Editor Hooks       │     │
│  │    Deeper Context Access       │     │
│  └────────────────────────────────┘     │
│    Modified VS Code Fork                │
└─────────────────────────────────────────┘

Cursor can modify VS Code internals, so the AI has deeper hooks into editor state. This enables their Tab feature (multi-line prediction) and better context assembly.

Trade-off: You're locked to Cursor. Can't swap out the AI layer or use it in JetBrains.

Windsurf: Integrated Agent Model

┌─────────────────────────────────────────┐
│             Windsurf                    │
│  ┌────────────────────────────────┐     │
│  │    Cascade (Integrated)        │     │
│  │    First-Class Editor Access   │     │
│  │    Continuous Observation      │     │
│  │  + Devin Cloud Agent           │     │
│  └────────────────────────────────┘     │
│    AI-Native Fork                       │
└─────────────────────────────────────────┘

Cascade has privileged access to the rendering pipeline. It sees everything automatically:

Terminal output (real-time)
Linter errors (auto-fixes without asking)
File navigation (infers intent)
Test results

Same debugging session with Windsurf:

1. Build fails
2. Cascade: "I see the test failed. Here's what's wrong. Want me to fix it?"
3. You: "Yes"
4. Done

Trade-off: Higher resource consumption (always watching = always consuming RAM). My ThinkPad struggles. My MacBook is fine.

The Tab Completion Battle

Let me be blunt: Cursor's Tab feature is the best multi-line autocomplete in the industry.

I'm not exaggerating. It predicts my next 5-10 lines with unsettling accuracy. Here's an example from actual React work:

I type:

const handleSubmit = async (e: FormEvent) => {

Cursor Tab suggests (correctly):

const handleSubmit = async (e: FormEvent) => {
  e.preventDefault();
  setLoading(true);
  
  try {
    const response = await api.submitForm(formData);
    if (response.ok) {
      navigate('/success');
    }
  } catch (error) {
    setError(error.message);
  } finally {
    setLoading(false);
  }
};

How did it know:

I use api.submitForm? (from other files)
I have a formData state? (from context)
I navigate on success? (from routing patterns)
I use try/catch/finally? (coding style)

Windsurf's Supercomplete is also excellent. VS Code Copilot's inline suggestions are good but not this predictive.

For flow state coding, Cursor wins. No contest.

The Context Awareness Spectrum

Here's where these tools sit on the "how much does the AI know about what I'm doing" spectrum:

Low Context (VS Code + Copilot):

Only knows what you explicitly tell it
Session-only memory
Must rebuild context each conversation
Pros: Predictable, controlled
Cons: High prompt overhead

Medium Context (Cursor):

Excellent codebase indexing
Understands repo structure automatically
Limited persistent memory
Pros: Fast, accurate within known scope
Cons: Still needs explicit prompting for complex tasks

High Context (Windsurf):

Continuous observation
Persistent memory across sessions
Infers intent from behavior
Pros: Autonomous, proactive
Cons: Resource-heavy, can be unpredictable

Real example - Dataverse schema work:

With VS Code: "I'm working on a Contacts table. I need to add three lookup columns to Account. Here's my publisher prefix. Here's the naming convention I use."

With Cursor: "Add three lookup columns to Contacts for Account" (it knows the rest from codebase)

With Windsurf: Opens schema file, starts adding columns → Cascade: "I see you're adding Account lookups to Contacts. Want me to generate the TypeScript interfaces too?"

Performance Numbers (Real Hardware)

Tested on M2 MacBook Pro (16GB) and ThinkPad T490 (8GB):

Cold Start Times:

VS Code: 1-2 sec
Cursor: 2-3 sec
Windsurf: 3-5 sec

RAM Usage (Baseline):

VS Code: 300-450 MB
Cursor: 400-600 MB
Windsurf: 500-900 MB

RAM Usage (Heavy AI Work):

VS Code: 600-800 MB
Cursor: 800 MB - 1.2 GB
Windsurf: 1.2-1.8 GB

My ThinkPad (8GB RAM):

VS Code: Good
Cursor: Usable but occasionally slow
Windsurf: Struggles (frequent swapping)

Recommendation:

8GB or less → VS Code
16GB → Any of the three
32GB+ → Windsurf or Cursor (maximize AI capabilities)

The Dev Container Problem

This is huge for anyone doing PCF development or working with containerized environments:

VS Code: Dev Containers are gold standard. Mature, reliable, well-documented.

Cursor: Dev Containers work well. Occasional quirks but generally solid.

Windsurf: NO DEV CONTAINER SUPPORT.

This is a deal-breaker for PCF work where you need Node.js version isolation. I keep hoping they'll add this, but as of April 2026, still nothing.

If your workflow requires Dev Containers: VS Code or Cursor only.

Real Workflow Scenarios

Scenario: Large TypeScript Refactoring

Needed to rename an interface used across 40 files.

Cursor Composer:

Me: "Rename ContactData to ContactEntity everywhere and update all imports"
Cursor: [Shows preview of all 40 files]
Me: "Apply"
Cursor: [Executes cleanly]
Time: ~30 seconds

Windsurf Cascade:

Me: "Rename ContactData to ContactEntity everywhere"
Cascade: [Analyzes repo, shows preview]
Me: "Apply"
Cascade: [Executes cleanly]
Time: ~30 seconds

VS Code Copilot Agent Mode:

Me: "Rename ContactData to ContactEntity everywhere"
Copilot: "Which files should I check?"
Me: "All TypeScript files"
Copilot: [Searches, proposes changes]
Me: "Apply"
Copilot: [Executes]
Time: ~2 minutes (more back-and-forth)

Winner for refactoring: Cursor (slightly faster, cleaner preview)

Scenario: Building Feature from Figma Mockup

Windsurf:

Drop screenshot into Cascade
Describe feature
Cascade generates components + styles
Live preview shows result
Click element, describe changes
Cascade auto-fixes linter errors
Time: ~15 minutes (1 prompt beyond initial)

Cursor:

Describe feature with reference to mockup
Tab through implementation
Use Composer for multi-file coordination
Alt-tab to browser repeatedly for preview
Time: ~30 minutes

VS Code:

Describe feature
Copilot generates initial code
Manual copy/paste and refinement
Alt-tab to browser for preview
Multiple prompt rounds for iterations
Time: ~45 minutes

Winner for greenfield features: Windsurf (continuous context + live preview is unbeatable)

Scenario: Debugging Production Bug at 3 AM

VS Code:

Dev Container reproduces exact prod environment
Mature debugger with breakpoints
Copilot helps reason about stack traces
Systematic step-through debugging
Result: Fixed reliably

Cursor:

Dev Container works
Good debugging support
AI helps with reasoning
Result: Fixed reliably

Windsurf:

No Dev Container (had to debug differently)
Cascade saw errors automatically
Suggested fixes quickly
Result: Fixed but with more uncertainty about prod parity

Winner for production debugging: VS Code (battle-tested tooling matters at 3 AM)

Pricing Reality

All three are around $20/month for the core paid tier:

VS Code + Copilot:

Free tier: 2K completions/mo
Individual: $10/mo
Business: $19/user/mo
Enterprise: $39/user/mo

Cursor:

Free trial: 2 weeks
Pro: $20/mo (but 500 "fast premium" request limit)
Business: $40/user/mo

Windsurf:

Free: 25 credits/mo
Pro: $20/mo
Max: $200/mo (for heavy usage)
Teams: $40/user/mo

Best value for solo dev: Cursor at $20/mo (excellent tab + composer)

Best value for heavy AI usage: Windsurf Pro at $20/mo (includes Devin cloud agent)

Best enterprise value: VS Code Copilot Enterprise (proven compliance, mature tooling)

The Features Nobody Talks About

Windsurf's Turbo Mode

You can literally tell Cascade "Execute this 12-step workflow" and it will autonomously:

Read files
Identify changes
Make edits
Run tests
Fix failing tests
Commit changes
All without asking for confirmation

It's powerful. It's also occasionally terrifying. Once deleted a test file I needed. Had to restore from git.

Use with caution.

Cursor's Privacy Mode

Cursor can run models fully locally. For clients with strict data residency requirements, this is huge.

Neither VS Code Copilot nor Windsurf offer full local execution.

VS Code's Multi-IDE Coverage

Copilot works in:

VS Code
JetBrains IDEs
Visual Studio
Neovim
Xcode (limited)

If you're polyglot across IDEs, only VS Code Copilot follows you everywhere.

MCP Support (Model Context Protocol)

All three support MCP, but with wildly different UX:

VS Code:
Manual JSON config in .vscode/mcp.json:

{
  "servers": {
    "dataverse-skills": {
      "command": "npx",
      "args": ["-y", "@microsoft/dataverse-skills"]
    }
  }
}

Cursor:
Same manual JSON approach. No plugin store.

Windsurf:
Plugin Store with one-click installs for curated servers (Figma, Slack, GitHub, PostgreSQL, etc.)

For custom MCP servers (like Dataverse Skills), all three require manual JSON config.

Power Platform Developers: Here's What Matters

PCF Controls

Use: VS Code or Cursor (both support Dev Containers)

You need:

Dev Container for Node version isolation
Power Platform Tools extension
Jest + React DevTools
PAC CLI integration

Windsurf's lack of Dev Containers is a non-starter here.

Dataverse Schema Design

Use: Windsurf or Cursor

With Dataverse Skills MCP server configured:

Windsurf + Cascade applies conventions automatically if you have .windsurfrules:

Publisher prefix: aidevme_
Naming convention: PascalCase for logical names
Relationship naming: Related{EntityName}

Cascade remembers this across sessions.

PAC CLI Workflows

Use: VS Code

Mature terminal integration, Dev Containers for environment consistency, better for scripted workflows.

What I Actually Use

I don't pick just one. Multi-editor strategy:

VS Code: PCF dev, PAC CLI, enterprise work, anything requiring Dev Containers
Cursor: Daily TypeScript/React feature work, refactoring, learning new codebases
Windsurf: Dataverse schema design, rapid prototyping, multi-file scaffolding

All three can be open simultaneously. Most extensions and settings transfer seamlessly.

The Honest Trade-offs

VS Code + Copilot

Choose if:

You need Dev Containers
You work across multiple IDEs
You want maximum stability
You need enterprise compliance
You're on 8GB RAM or less

Skip if:

You're frustrated by prompt overhead
You want proactive AI behavior
You need continuous context awareness

Cursor

Choose if:

You prioritize flow state and tab completion
You do heavy refactoring work
You want fast, predictable AI
You need privacy mode (local execution)

Skip if:

You need multi-IDE support
You hit the 500 request/month limit
You want autonomous agent capabilities

Windsurf

Choose if:

You want cutting-edge AI capabilities
You need cloud agent delegation (Devin)
You have 16GB+ RAM
You want continuous context awareness

Skip if:

You need Dev Containers
You're on 8GB RAM or less
You want battle-tested tooling
You prefer explicit control over autonomy

My Recommendation

If you're starting today:

Start with VS Code + Copilot Individual ($10/mo)
Master the fundamentals
Once comfortable, try Cursor's free trial (2 weeks)
If you love Tab completion → stay with Cursor
If you want more autonomy → try Windsurf's free tier (25 credits)

If you're experienced:

Cursor Pro ($20/mo) for solo dev work
Windsurf Pro ($20/mo) if you have good hardware and want bleeding-edge
VS Code Copilot if you need enterprise features or multi-IDE

Discussion Questions for the Community

Are you using Cursor or Windsurf? What made you switch from VS Code?
Has anyone successfully used Windsurf without Dev Containers? How do you handle environment consistency?
Cursor's 500 request limit - have you hit it? How did you work around it?
Autonomous AI concerns - how much autonomy are you comfortable with? Have you had Windsurf's Turbo Mode do something unexpected?
Multi-editor workflows - is anyone else using multiple editors for different tasks? What's your strategy?
MCP adoption - are you using MCP servers? Which ones? What's your experience?

Drop your experiences in the comments. I'm genuinely curious what the community is finding.

Full deep-dive article: https://aidevme.com/vs-code-vs-windsurf-vs-cursor-my-honest-take-after-6-months-using-all-three/

kasetto - declarative AI agent environment manager, written in Rust

Mon, 20 Apr 2026 21:09:16 +0000

Hey community!

I want to share an open-source tool I built for myself, and that I hope will be useful to other developers working with AI agents.

The Problem

The more AI coding tools we adopted, the messier our setup got. Skills and MCP servers installed manually, via individual commands, or copy-pasted from docs. Scattered across Claude Code, Cursor, Codex, Windsurf - with no way to version any of it, no way to share it with teammates, no way to reproduce it on a new machine or project.

Every new team member meant walking them through the same manual steps. Every new machine meant doing it all over again. And if someone changed a skill or added an MCP server, there was no way to propagate that to the rest of the team.

Sound familiar?

The Idea

I built kasetto to fix that. The idea is borrowed from things I already loved - the declarative reproducibility of dotfiles, the simplicity of uv for Python packages. What uv did for Python, kasetto aims to do for AI agent skills.

One YAML config describes your entire setup: skills, MCP servers, target agents. Commit it, share it, and everyone on the team gets the exact same environment. No manual editing, no drift between machines or teammates. New machine? One command.

The Name

Kasetto (カセット) is the Japanese word for cassette - as in a cassette tape. A cassette was a self-contained, portable thing: you recorded something once, handed it to someone, and it played back exactly the same on any device. No setup, no drift, no "works on my machine." That's exactly what kasetto does for your AI agent environment - package it once, share it, and it reproduces identically everywhere.

Why kasetto

Declarative - one YAML config, version it, share it, bootstrap a whole team in seconds
Multi-agent - 21 built-in presets: Claude Code, Cursor, Codex, Windsurf, Copilot, Gemini CLI, and more
Multi-source - pulls from GitHub, GitLab, Bitbucket, Codeberg including self-hosted and enterprise
MCP management - merges MCP servers into each agent's native settings file automatically
Global and project scopes - install skills globally or per-project, each with its own lockfile
CI-friendly - --dry-run to preview, --json for automation, non-zero exit on failure
Single binary - no runtime dependencies, written in Rust, fast cold starts

How It Works

Define your config:

agent:
  - claude-code
  - cursor
  - codex

skills:
  - source: https://github.com/org/skill-pack
    skills: "*"
  - source: https://github.com/org/skill-pack-2
    skills:
      - product-design
  - source: https://github.com/org/skill-pack-3
    skills:
      - name: jupyter-notebook
        path: skills/.curated

mcps:
  - source: https://github.com/org/mcp-pack

Then sync:

kst sync

That's it. Kasetto pulls the skills and MCP servers, installs them into the right agent directories, and merges MCP configs into each agent's native settings file. The next time you run sync, only what changed gets updated.

Command Overview

Kasetto ships with a focused set of commands - each does exactly one thing:

kst sync              # pull skills + MCP servers and install them
kst sync --dry-run    # preview what would change without touching anything
kst sync --json       # structured output for CI pipelines

kst list              # browse installed skills and MCPs interactively
kst list --json       # dump installed state as JSON

kst init              # scaffold a kasetto.yaml in the current directory
kst doctor            # check your environment and diagnose issues

kst clean             # remove all installed skills and MCP entries
kst self update       # update kasetto to the latest release
kst self uninstall    # remove kasetto and all its files
kst completions       # generate shell completions (bash, zsh, fish, etc.)

The binary is available as both kasetto and kst - the short alias makes daily use quick.

Install

macOS / Linux
curl -fsSL https://raw.githubusercontent.com/pivoshenko/kasetto/main/scripts/install.sh | sh

Homebrew
brew install pivoshenko/tap/kasetto

Cargo
cargo install kasetto

What's Next

The roadmap includes agents management and hooks management. If you have ideas or run into issues, open an issue - feedback from real users shapes the direction.

github.com/pivoshenko/kasetto

If kasetto saves you time, a GitHub star means a lot. And drop a comment below - I'd love to hear what your AI agent setup looks like today, and what pain points you're still hitting.

Adding DepScope as an MCP tool inside Cursor in under 5 minutes

Mon, 20 Apr 2026 01:17:42 +0000

Adding DepScope as an MCP tool inside Cursor in under 5 minutes
Your AI assistant in Cursor is great at writing code. It's less great at knowing which packages are actually safe to install right now. Suggestions come from training data 6-12 months stale, so recent CVEs are invisible, deprecated libraries get recommended with enthusiasm, and sometimes the model just hallucinates a package name that never existed.

DepScope fixes that with a shared-cache API. It also ships an MCP (Model Context Protocol) server so Cursor can call it automatically, in-context, every time it's about to suggest a dependency.

Here's the full setup in under 5 minutes.

Step 1 — install the MCP server
Any terminal:

npm install -g depscope-mcp

That's the whole install. No API key, no signup, no config file.

Step 2 — register it with Cursor
Open Cursor's MCP config. On macOS:

~/.cursor/mcp.json

(Or Settings → MCP → Edit Config from the command palette.)

Add the DepScope server:

{
"mcpServers": {

"depscope": {
  "command": "npx",
  "args": ["depscope-mcp"]
}

}
}

Save. Restart Cursor (the MCP servers are loaded on startup).

Step 3 — verify
Open a new chat in Cursor and ask something that would normally make the model guess:

Should I install request or axios for HTTP in my Node project?

Cursor will now call the DepScope check_package and find_alternatives tools before answering. You'll see the tool invocations in the chat:

→ Calling depscope / check_package
{ ecosystem: "npm", package: "request" }
← { action: "avoid", reason: "deprecated since 2020",

alternatives: ["axios", "node-fetch", "undici"] }

The answer you get back is based on live registry data plus OSV + GitHub Advisory Database lookups, not the model's stale training.

What you actually get
Fourteen MCP tools registered automatically. The ones that matter in day-to-day dev work:

ToolWhen Cursor calls it
check_package"Should I install X?"
get_vulnerabilities"Are there any known CVEs in Y?"
get_latest_version"What's the current stable version?"
package_existsSafety-check before suggesting anything (anti-hallucination)
find_alternatives"This is deprecated — what do I use instead?"
compare_packages"Express vs Fastify vs Hono?"
resolve_error"I got this ModuleNotFoundError — how do I fix it?"
check_compat"Is Next 15 compatible with React 19?"
search_packages"I need a library for X"
scan_projectAudit all deps in one shot
Works across 17 ecosystems: npm, PyPI, Cargo, Go, Maven, NuGet, RubyGems, Composer, Pub, Hex, Swift, CocoaPods, CPAN, Hackage, CRAN, Conda, Homebrew.

Token efficiency note
If you care about input-token cost, DepScope has a dedicated /api/prompt/{ecosystem}/{package} endpoint that returns a compact natural-language string instead of raw registry JSON. For the same install decision it's roughly 74% smaller than the raw registry response — less input for the model to parse, fewer tokens on your Claude / OpenAI bill per query.

The MCP server uses this endpoint by default when the tool call doesn't need full structured data.

Wrap-up
After this setup, every time Cursor is about to suggest a dependency, it gets validated against live vulnerability data — no more suggestions from 2024, no more hallucinated packages, no more silently pulling in deprecated libraries.

Links:

Website: depscope.dev
All integrations (Claude Code, Windsurf, Copilot, Aider, raw HTTP): depscope.dev/agent-setup
Source: github.com/cuttalo/depscope — MIT
API docs: depscope.dev/api-docs

Open infrastructure, MIT, EU-hosted. Built solo by Vincenzo Rubino at Cuttalo srl.

Beyond the Agents Window: Why Parallel Execution Is Not Enough

Thu, 09 Apr 2026 20:56:37 +0000

April 3, 2026 · Lastkey

What if I told you that within months, your primary workspace won't be an IDE or a terminal — but an environment above them, where your native language is your command language and your core skill is making the right call at the right time?

For those who've already shifted to multi-agent workflows, this isn't a prediction — it's Tuesday. But everyone who's made that leap and started running not two but five, ten, or more parallel streams has noticed something: the ceiling didn't disappear. It moved. It moved from the tooling to the operator. And while the industry is racing to ship more agents, faster agents, parallel agents — nobody yet has a product for what breaks when you actually run them.

This year, IDE stops being the center of how we build. The shift to agentic development environments is already underway. But the shift reveals a deeper problem that new windows and tabs can't solve.

So what if I told you more — you won't be a developer at the end of the year. You'll be an operator, and your main skill won't be coding — it will be governance.

From Pair Programming to Fleet Steering

The IDE was home for decades, and for good reason. It gave you the widest possible context for making decisions — file tree, editor, terminal, git, all in one frame. When AI arrived as a coding assistant, it felt like a natural layer on top: autocomplete, inline chat, pair programming with a model. The environment stayed the same. Just faster.

Then came agents. VS Code, Cursor put you in the reviewer's seat — one agent, one task, one conversation. It was manageable. You learned to guide instead of type.

Then came parallel agents. Two worktrees. Four cloud sessions. Eight simultaneous streams across repos and environments. The thing that made IDE powerful — unified context for decisions — shattered into fragments. Each agent holds its own context. You're the only one holding the full picture. And you sit at the desk, trying to manage the ever-growing streams, wanting to expand further — and realize: huh, so it's me who's the bottleneck now?

Andrej Karpathy in his recent interview said that everything now feels like not a possible/impossible dilemma, but a skill issue — you can do anything, but don't always know how. Garry Tan, CEO of Y Combinator, published gstack — his personal Claude Code setup, now at 40K+ GitHub stars. And you can see that it is the same API everyone has access to, from CEO to beginner developer. And we together keep hitting the same productivity and cognitive walls at some point. Skill matters. But skill alone doesn't scale, and no UI will solve it. Because we start to realize it is beyond the infrastructure issue — it's about mindset.

Cursor 3 and the ADE Moment

As I was finishing this piece, Cursor shipped version 3.0 — a new Agents Window with parallel execution across worktrees, cloud, and SSH.

The concept of an Agentic Development Environment — ADE — was introduced by Warp last fall, describing a new class of tools built around agent orchestration rather than file editing. Since then, projects like Emdash, Jean, and dozens of open-source alternatives have explored the same pattern. Cursor 3 brings it to the most widely adopted AI development platform — expanding its ADE interface and continuing a confident move toward multi-agent orchestration.

It's a genuine step forward. But open the new Agents Window, and you see what every ADE converges on: agents on the left, chat in the middle, output on the right.

Cursor's marketing starts on a premise: "the gap between imagination and reality is shrinking." But the gap between idea and execution is still there, and won't go away. The real distance from idea to implementation isn't about the perspective you look from at the agentic workflow. It's about whether your idea gets decomposed into a traceable command, broken down into verifiable parts, and executed in accordance not just with the letter, but with the intent behind it. A new window layout makes this gap more visible — but it doesn't close it.

The Real Bottleneck

You're keeping up with the times. You moved from the programmer's seat to the reviewer's seat. You trained yourself to verify code instead of writing it. You formulate precise instructions in English more than precise syntax in Python. You launch 2, 4, 8 agent streams in parallel, moving multiple projects forward at once.

And then: what's beyond this? What happens when you want — or already need — to operate not eight agents, but fifty? A hundred and more? An ADE interface gives you a comfortable view that visualizes how much action you're missing and how little remains in your direct control or understanding.

But this shift was never about doing less. It's about doing more — more effectively, with fewer mistakes, faster iterations. The question is: what do I need, beyond an interface that displays agentic flows, to feel not like a passive observer of independent processes — but like an engaged, briefed, and effective operator?

No tool on the market answers this, because every tool optimizes for the introduction of agents into development — not for the fundamental switch in the operator's thinking that agents demand.

Three Gaps That Break the Flywheel

Everyone building with multi-agent workflows runs into the same three walls. Plenty of tools address one. None address all three together — and without all three, the system doesn't compound. You build, but the flywheel doesn't spin.

The Planning Gap. The moment you start assigning work to agents and tracking results, the obvious reference is task trackers — Linear, Jira, kanban boards, the recent wave of AI-native boards like Vibe Kanban. They help. But they were designed for humans coordinating with humans. The units of work, status models, and interfaces are human-native, not agent-native.

They don't reflect the speed and intensity of execution that agents are capable of, and don't capitalize on the scope and form of metadata that agents can actually work through.

They don't connect a morning's first action to a quarter's strategic goal. They don't help you decide what to delegate and what to hold. They don't know when human judgment is truly needed, or when and how to brief you on progress — rather than presenting a democratic corporate kanban board to a sole manager.

Task tracking is a piece of the puzzle — but it was built for a different picture. The workforce changed. The tools haven't.

The Memory Gap. Every agent session starts from scratch. Decisions from yesterday, patterns from last week, mistakes from last month — gone. The operator, if disciplined and organized enough, might remember where to find the notes. The system out of the box doesn't.

And it's not just a technical limitation. Providers aren't rushing to give you the full stream of data flowing from your interactions. Collecting prompts, curating reusable commands, configuring agent roles, monitoring real performance on basic metrics — token spend, tool usage, completion rates — for a modern operator, this is either a DIY assembly from OSS tools and personal practice, or something built behind closed corporate doors.

Assembling these instruments is creative and rewarding work — learning to work with indexing, RAG, embeddings, recall, subagent playbooks and command prompt libraries. But it pulls you away from using them. You're building the workshop instead of working in it.

The Governance Gap. Who verifies that agent 3 didn't break what agent 1 fixed? Who notices when quality degrades over weeks? Who improves the process itself?

We've seen fascinating experiments recently — self-governing agent swarms, autonomous code city concepts, YOLO rogue AI-managed repositories. What these experiments reveal is that proper governance isn't overhead. It's the most reliable multiplier and cost reducer at scale.

For generations, humanity's best minds worked on effective and fair systems for governing each other. We face the same challenge now with agent systems — each of us individually. Switching from the pilot's seat to the reviewer's is straightforward. Managing a small team of sub-agents is a skill and experience issue.

But scaling to govern a growing empire of semi-autonomous, not-fully-observable clusters — no individual achieves that with practices alone. It requires institutions.

The future operator rules not with a Scrum guide, but with a living codex connected to a real, functioning, agent-driven organization.

ODE — Operator Development Environment

There is a layer that must exist within and beyond what ADEs currently offer. Today's ADEs are a surface-level response — necessary, but not deep enough for the real pains of operating agent fleets.

Right now, every practitioner solves this differently — with whatever tools, approaches, and experience they have at hand. There's no standard, no unified solution. And that's exciting — because it means the practice and feedback of every builder is actively shaping what this layer becomes. In many places, the market lags behind the speed of OSS and community-driven solutions. This is a moment that shapes future standards — through practice and competition.

So what is this layer that closes these gaps?

I call it ODE — Operator Development Environment.

What is it? ODE is not another ADE. An ADE optimizes agent overview — how many agents, how fast, how parallel. ODE optimizes operator cognition — how you think, plan, verify, remember, and improve through agents. Only from there stem the tools that make these streams of cognition actionable and translated to the agentic workforce. It's the layer between your intent and the agents' work.

Why introduce the term? Because the gap described above — planning, memory, governance — isn't three separate problems with three separate products. It's one systemic gap: the absence of a coherent environment designed for the operator's mind, not the agent's runtime. Naming it opens the space where it can be envisioned — and put into form.

What does ODE consist of?

A planning engine that goes beyond task tracking — connecting strategic goals to today's first action, routing work based on each task's nature, and building a statistical picture of velocity and accuracy that sharpens with every cycle.

Institutional memory that outlives every session — a knowledge graph, episodic memory, and source intelligence unified behind a single retrieval layer. The system remembers decisions, patterns, and mistakes so every new session starts with context, not from zero.

A governance framework that watches the agents so you can watch the horizon — automated verification, adaptive trust calibrated to each agent's track record, and threshold-based escalation that acts before problems compound.

A unified input surface — not a chat window per agent, but a single point where your intent enters the system and gets routed to the right stream.

Why does it address the gaps? The planning engine closes the planning gap — agent-native task management with intent hierarchy. Institutional memory closes the memory gap — persistent, structured, retrievable context across sessions and projects. The governance framework closes the governance gap — verification, trust, and self-improvement baked into the system, not bolted on by the operator's discipline.

Together, these components form the flywheel: each completed cycle feeds the next. Memory grows. Governance tightens. Planning calibrates. The environment becomes a multiplier — carrying you from idea to implementation instead of demanding constant assembly of the vehicle itself.

This isn't theory. Each component already exists in working code, built over months of daily use, managing and shipping over a dozen projects with the same tools available to everyone. It may not be the implementation. But it is definitely an implementation — one for each gap, derived from practice. I'll share the details and our insights for each subsystem and domain in the articles to come.

The Operator's Seat (Throne-Ready)

The shift from developer to operator isn't about losing the craft. It's about the craft evolving. You still need to understand systems — the way a fleet commander needs to understand navigation, not the way a helmsman needs to hold the wheel.

And here's what matters: an operator with the right environment doesn't just manage one ship. They scale from a single vessel to a flotilla — as their goals demand and ambitions grow. With ODE, scaling isn't a search for technology. It's a decision, supported by an environment that grows with you.

Throne-ready — a term that emerged from the idea of being prepared for a qualitative shift: from managing agents to governing them. From coordinating a crew to administering an empire. The tooling you build today should anticipate that transition — because when it comes, the difference between a practitioner with institutions and one without will be the difference between a productive operator in control and someone drowning in tabs.

The tools will catch up. Cursor is probably closer than most — introducing planning modes, autonomous cloud agents, now shipping a full ADE. But the question isn't whether these layers will exist. It's whether you'll have shaped them through practice and already know how to use them — or whether you'll be learning someone else's defaults while early adopters are compounding on months of built-up advantage. In this environment, the gap between those who internalized these patterns early and those who didn't won't be 2x. It'll be an order of magnitude. And for some — it already is.

What's Next

This is the first in a series exploring the Operator Development Environment concept — from academic foundations and emerging patterns to product-level implementations that address its parts.

In the next piece, I'll share my own experience — one that I'm sure mirrors the journey of thousands of developers who, using the same tools available to everyone, from model APIs to OSS and vendor solutions, are trying to build their own thinking environment with agents. I'll show what I arrived at, how the understanding of what I was building crystallized along the way, and what I use today — something close enough to a working prototype that it feels worth writing about, inviting questions and critique as the series unfolds.

Over the coming articles, I'll share the components that close each gap: the planning layer that makes multi-agent work manageable, the memory and observability foundation that makes it consistent and measurable, the governance framework that makes it scalable, and ultimately — the interface where it all comes together, where scattered thoughts and ideas become executable plans.

I'll be releasing parts of the system as the series progresses, and the early alpha is already in the hands of first users.

If any of this resonates — follow along.

Follow the series at lastkey.agency · Concept and repo: github.com/lastkey-agency/ode · Reach out: hello@lastkey.agency

Have you hit the same walls scaling your agent workflows? What does your setup look like at five or more parallel streams — and where does it start to crack? I'd genuinely like to know what others are building to solve these problems.

Cursor’s Cloud Agents: A Big Shift in AI-Assisted Development

Wed, 25 Feb 2026 19:26:56 +0000

Cursor just introduced a major upgrade and it’s more than just a feature update.

Agents can now:

Onboard directly to your repository
Spin up a secure cloud-based Linux VM
Make code changes
Install dependencies
Run tests and builds
Push a branch and open a PR
Even send a video demo of the finished work

All of this happens inside an isolated sandbox not on your local machine.

What Problem Does This Solve?

Until now, most AI coding tools worked locally:

They modified files on your machine

Consumed your CPU and RAM

Relied on your environment setup

Risked breaking things if misconfigured

For large codebases, microservices, Docker-based stacks, or CI-heavy workflows, this becomes limiting.

Cloud agents solve that by:

Running in a clean, reproducible environment

Eliminating “works on my machine” problems

Reducing risk to local files

Enabling remote triggering via web, Slack, mobile, or API

Why This Matters

This isn’t just better autocomplete.

It’s a shift from:

AI as a coding assistant
to
AI as an autonomous engineering worker

When agents can clone repos, test changes, and open PRs independently, the development workflow fundamentally changes.

The PR becomes the review boundary.
The cloud VM becomes the execution layer.
The developer becomes the decision-maker.

We’re moving toward AI-native software workflows — and this is an important step in that direction.

Curious how this will reshape CI/CD, code review culture, and engineering team structure over the next few years.

What are your thoughts?

Speeding Up Layout from Figma with MCP and Cursor

Fri, 13 Feb 2026 11:21:32 +0000

Converting a design from Figma into code is an unavoidable stage of development, one that's often tedious and time-consuming. Even when we work with design systems where colors, fonts, and spacing are standardized, and layers and components are neatly named, transferring styles and double-checking every detail still eats up a lot of time and energy.

If you're still stuck in the copy-paste loop and are thoroughly tired of this routine - it's high time to look towards AI and the useful tools it can offer. In this article, I'll show you how to leverage the full power of AI assistants in the design implementation process, using the duo of Cursor IDE and an MCP Server as an example.

MCP (Model Context Protocol) is a tool that burst onto the scene in 2025 and quickly found its place in the AI tool ecosystem. Its emergence was a logical step in the evolution of AI agents, which outgrew the limited context of a single model.
MCP is an open-source standard that describes how AI agents and applications interact with each other and with external systems. Simply put, MCP acts as a language interpreter between products and Large Language Models (LLMs). It receives data in a specific service's "language" and translates it into a format the AI can understand.
In other words, MCP allows AI agents to expand their capabilities by gaining access to a broader context. Through MCP, an AI can safely fetch data via API, search for information, perform analytics based on external services, and complete other tasks beyond the base model's reach.
Companies like Figma can create their own MCP servers for their products by implementing this standard. Such a server knows how to call the product's API, extract the necessary context, and pass it to the agent in a structured way. In Figma's case, an MCP server directly integrates Figma into the workflow, providing AI agents with design information and the context needed to generate code based on Figma design files.

Requirements

Integrating such a tool into your workflow isn't complicated. You'll need: a code editor with MCP support (VS Code, Cursor, Claude Code, Codex, etc.) and access to a Figma project.

Of course, there are nuances, such as design requirements, Figma's pricing plan, and other details. We'll discuss those a bit later.

What the Process Looks Like from a User's Perspective

In broad strokes, the workflow is like this:

Setting up an MCP server inside your editor.
Connecting to Figma via automatic browser authorization or manually using an access token (depending on the chosen MCP).
Prompting the AI agent to implement the layout for the desired component.
Reviewing the result, making edits, correcting the code.
Clarifying requirements and expanding the context.
Getting the result (rapid layout).

I've tried different MCPs in practice; they are all functional options with their own quirks:

MCP Cursor Talk To Figma - a bit more demanding to set up (you need to set up a local server following the instructions and run the "Cursor Talk To Figma" plugin in Figma; works even without Dev Mode access).
Framelink MCP for Figma - convenient to set up, works even without Dev Mode access.
Figma MCP Server - official from Figma (but there's a nuance regarding Dev Mode).

Let's take a closer look at the process using the official Figma MCP Server as an example.

The Process

First, log into Figma and open your design project.
Then, follow the installation instructions for the server in your IDE settings. It's genuinely simple and quick, taking just a couple of minutes. After installation and OAuth authorization, the server will show as 'enabled'.

Now the editor (in my case is Cursor) has access to a ready MCP server.
Select the desired component in the design and copy its link:

Write your prompt. It can be concise:

"Implement the component design from
https://www.figma.com/design/<link-to-your-selection>"

Or more detailed (this makes the agent's job easier and reduces the number of operations):

"@feature.tsx Implement the component design from https://www.figma.com/design/<link-to-your-selection> according to the @always.md. Use Tailwind for layout, spacing and typography. Do not download images. Use placeholders from @images"

Executing such a prompt is quite fast - from 20 seconds for small components (card, quote, hero block) to a couple of minutes for an entire page.

After that, the foundation is ready:

Then we ask the AI agent to adjust its approach:

"- Replace custom Tailwind values with standard utility classes. For example, avoid arbitrary values like p-[40px] or text-[64px]; use default Tailwind spacing and font sizes (p-10, text-4xl, etc.) instead.- Replace custom CSS variable references in class names with design-system aliases. For example, text-[var(--color-text-light-gray)] should be written as text-light-gray."

Depending on the AI model and the complexity of the design and the existing codebase, the AI can produce different results. So, you need to help the agent with context. This is where rules come in - you can create and expand them as you see fit. The documentation offers some tips on this.

The rules I used for a project with a React+Tailwind stack look like this:

# Cursor Project Rules & Guidelines
## Always Rules
## HTML / Accessibility (Component-Level Default)
- Use semantic tags (`section`, `article`, `nav`, `header`, `footer`) where relevant.  
- Follow proper heading hierarchy inside components (don’t start with `<h1>` unless it’s a full page).  
- Every image must have an `alt` attribute.  
- Make interactive elements (buttons, links, menus) keyboard accessible.  
## Code Generation & Architecture (JS/TS + React)
- Use **TypeScript** in strict mode; avoid `any`.  
- Prefer **type** over `interface` (except for classes).  
- Use **named exports only**; avoid default exports.  
- Prefer **guard expressions** instead of nested conditions.  
- Use **union types** instead of enums; `as const` objects are allowed.  
## CSS / Styling (General)
- Use Tailwind for styling.
- Use a **mobile-first** approach.  
- Prefer flexible dimensions (`min/max-width`) over fixed ones
## Color & Design System
- Extract exact colors from Figma data; do not approximate.
- If brand colors or repeated colors appear for the first time, create CSS variables in src/index.css.
- Use exact hex or rgba values from Figma; do not approximate with Tailwind.
- Font families and other constants should be defined in src/index.css.
- Use Tailwind responsive breakpoints for layout.
## Images and icons
- Do not attempt to download images, use a placeholder from `src/assets/images/`.  
- Always specify `alt`, `width`, and `height` attributes.  
- Use descriptive `alt` text based on the component’s purpose or content.  
## Development Workflow Optimization
- **Avoid redundant checks** - Don't check linter, existing configurations, or dependencies unless specifically requested
- **Skip obvious validations** - If package.json shows dependencies are installed, don't verify setup
- **Minimal todo lists** - Only create todos for complex multi-step tasks (3+ distinct steps)
- **Focus on core task** - Complete the main objective first, then add refinements if needed
- **Assume working environment** - Don't verify basic project setup unless errors occur

It's convenient to place the rules in a separate directory. For example, create a .cursor folder in the project root and put all rules inside a rules folder within it. Be sure to give the AI agent a link to the rules.
Here's also an example of a detailed set of rules from another project configured with Framelink MCP:

It's important to understand that the agent may selectively ignore formal rules. Sometimes, it makes sense to duplicate important requirements directly in the prompt. It doesn't hurt to add a reminder at the beginning of the dialogue like: "Respect all rules from .cursor/rules".

Another topic is the AI agent's analysis of existing styles and components. Even if the agent correctly navigates the project structure and understands current UI patterns, it doesn't guarantee the generated code will fully meet your requirements and expectations.

Here's a list of what positively affects the quality of the AI agent's output:

If you're creating a project from scratch - set up the basic CSS settings for html, body, variables, media breakpoints, fonts, mixins, etc., yourself. On this foundation, the AI can help you pull missing colors, fonts, sizes, spacing from Figma into the project, and form styles for basic UI components, placing what you need into variables.
Reference existing project files as a guide for structure, patterns, and code styles in TS/JS.
Rules should be concise, clear, and consistent.

The fuller the context available to the AI agent, the more organically the design integration into code will proceed. Context includes not only rules and component examples but also basic project settings, existing files, styles, patterns, and any documentation that helps the agent correctly navigate the structure and development approaches.

You can expand the context not only with rules and component examples. I highly recommend checking out Figma's Code Connect feature. It's only available for Organization and Enterprise plans, but it links real components from your repository with components in Figma - this way, the agent sees not only the design structure but also the actual code, import paths, props, and usage examples. If the Figma project is a true design system, such a tool seems like a must-have for a team planning to use MCP.

I also want to mention the topic of responsive design separately. AI handles generating the necessary layout based on provided responsive designs quite well. Example prompt:

"@feature.tsx Implement the component design from Figma:
- Mobile: https://www.figma.com/design/<link-to-your-selection>
- Desktop: https://www.figma.com/design/<link-to-your-selection>
Ensure responsive design: switch to desktop layout at 1024px width."

Here are a couple of visual examples for a project with only the most minimal basic settings so far, and a UI component base still being formed:

Example of a website card:

And here's an entire page:

As you can see, AI + MCP handle such tasks as well: it took me about a minute to formulate the request and generate the code. We got a result even with a raw, unconfigured project. However, this is more of a theoretical example. In practical development, this approach isn't justified. Converting an entire page at once creates an extra intermediary layer - code that will inevitably need to be redesigned, parsing and rethinking a large volume of already generated markup.

Nuances and Limitations

1. Tokens

You'll notice that executing requests consumes tokens, using up your editor's pricing plan limit. You can't avoid spending tokens altogether. But you can observe the dialogue with the AI to see what extra steps it's taking and then experiment with different models. For example, you can skip linter checks and intermediate code reports in the rules, etc.

Real examples:
Implementing a card component: 161.9k tokens – $0.10
Implementing a home page (6 sections): 433.6k tokens – $0.21

2. Figma API Limits

After a couple of hours of work on a free plan, you'll likely get a "429 – too many requests" system message. This is a Figma API limitation, not MCP. As explained on Figma's site, this happens because applications and integrations are only allowed to send a certain number of requests to the REST API on your behalf. The limit depends on your pricing plan, license, and file location.

In other words, using MCP on Figma's free plan will only work sporadically, a little, in test mode. Full-fledged work requires access to a paid plan.

3. Dev Mode

For the official Figma MCP, you need Dev Mode - a paid feature. Their site says the remote server is available for all seats and plans, and the desktop server is available for Dev or Full seat on all paid plans. In practice, I only managed to connect to the remote MCP after activating Dev Mode access.

4. Design Requirements

With a messy design, you might get nowhere. Or rather, you might get something, but fixing the errors will take longer than if you did everything manually.

The main recommendations for the design are:

Layers should be grouped logically, their names should correspond to the context, and the correct structure of frames/components must be maintained.
Layer and variable names should be clear, consistent, and reflect the element's role (e.g., color-primary, font-heading-lg, spacing-md).
Auto-layout is used.
Constraints are set for layers.
Layers don't overlap.
Alignment and spacing follow consistent rules.

When NOT to Use MCP

I wouldn't use MCP when the design is poor - layers aren't grouped and are chaotic, colors and text styles are scattered and inconsistent, text is split into separate layers. Also, don't waste time converting designs for complex components, components with multi-layered elements and special animations. Or when the volume of work is small and targeted - in this case, it's probably easier to work with components manually.

Conclusion

In this article, we looked at what converting a design into code looks like with AI and MCP. Of course, refining components remains a separate process. The ready code proposed by the AI requires careful review, correction, and in some cases, a complete rewrite. Often, it's easier to just create a component manually from the start than to try to get a result automatically.

And yet, it's impossible to deny that a properly configured MCP and correct interaction with it gives a powerful boost to frontend development. With skillful integration, the effort and time a developer spends on transferring and checking styles can be redirected towards architecture and logic. The main thing is not to rely blindly on the assistant. MCP is just an additional tool that helps speed up work, but the responsibility for code quality remains with the developer.

Author: Liya Vasilkova, frontend developer at ByteMinds

Coder Legion - Recent posts tagged cursor

Claude Code & Cursor: Why Your AI Agent Lies to You (And Our 3-Tier Adversarial Tribunal Skill)

1. The Anatomy of "First-Draft Sycophancy"

2. Enter critic-refine v1.1.0: The 3-Tier Adversarial Engine

Why Phase 1 Forbids Boilerplate

The Anti-Complacency Rule

3. Killing Confirmation Bias: The "Zero-Context Blind Audit"

4. The Anti-Sycophancy Deductive Rubric

5. The Complete SKILL.md Specification (v1.1.0)

🧪 Put It to the Test (I Want Your Feedback!)

Is AI Making Us Worse Developers?

When the Agent First Picked Up Its Own Tools

canonical_url: https://github.com/joinwell52-AI/FCoP/blob/main/essays/when-the-agent-picked-up-its-tools.en.md

I. Three stages — three fundamentally different things

II. Finding the door

III. Three changes, one breakthrough

IV. Tools aren't enough — you also need to know how to use them

V. That number

VI. The first complete cycle

VII. Where it all started

VIII. FCoP's own transformation

Epilogue: Thank you, Cursor Agent SDK

I Paid for VS Code, Cursor, and Windsurf Simultaneously for 6 Months. Here's What I Actually Learned

The Setup

Architecture Matters More Than Features

VS Code + Copilot: Extension API Model

Cursor: Optimized Fork Model

Windsurf: Integrated Agent Model

The Tab Completion Battle

The Context Awareness Spectrum

Performance Numbers (Real Hardware)

The Dev Container Problem

Real Workflow Scenarios

Scenario: Large TypeScript Refactoring

Scenario: Building Feature from Figma Mockup

Scenario: Debugging Production Bug at 3 AM

Pricing Reality

The Features Nobody Talks About

Windsurf's Turbo Mode

Cursor's Privacy Mode

VS Code's Multi-IDE Coverage

MCP Support (Model Context Protocol)

Power Platform Developers: Here's What Matters

PCF Controls

Dataverse Schema Design

PAC CLI Workflows

What I Actually Use

The Honest Trade-offs

VS Code + Copilot

Cursor

Windsurf

My Recommendation

Discussion Questions for the Community

kasetto - declarative AI agent environment manager, written in Rust

The Problem

The Idea

The Name

Why kasetto

How It Works

Command Overview

Install

What's Next

Adding DepScope as an MCP tool inside Cursor in under 5 minutes

Beyond the Agents Window: Why Parallel Execution Is Not Enough

From Pair Programming to Fleet Steering

Cursor 3 and the ADE Moment

The Real Bottleneck

Three Gaps That Break the Flywheel

ODE — Operator Development Environment

The Operator's Seat (Throne-Ready)

What's Next

Cursor’s Cloud Agents: A Big Shift in AI-Assisted Development

Speeding Up Layout from Figma with MCP and Cursor

Requirements

The Process

Nuances and Limitations

When NOT to Use MCP

Conclusion

2. Enter `critic-refine` v1.1.0: The 3-Tier Adversarial Engine

5. The Complete `SKILL.md` Specification (v1.1.0)