Forem: Manas kolaskar

Cursor Introduces a TypeScript SDK for Building Programmatic Coding Agents With Sandboxed Cloud VMs, Subagents, Hooks, and Token-Based Pricing

Manas kolaskar — Fri, 01 May 2026 15:51:13 +0000

Cursor, the AI-powered code editor, is opening up the core technology behind its coding agents to developers everywhere. The Cursor team announced the public beta of the Cursor SDK — a TypeScript library that gives engineers programmatic access to the same runtime, harness, and models that power Cursor’s desktop app, CLI, and web interface.

This signals a meaningful shift in how AI coding tools are being positioned: not just as interactive assistants sitting alongside a developer, but as deployable infrastructure that organizations can wire into their existing systems.

From Interactive Tool to Programmable Infrastructure

If you’ve used Cursor before, you know it as an IDE where you interact with an agent in real time — asking it to write functions, fix bugs, or explain code. The Cursor SDK changes the access model. Instead of a developer sitting at a keyboard, the agent can now be invoked programmatically: from a CI/CD pipeline trigger, a backend service, or embedded directly inside another product.

Think of it this way: previously, you had to be “in” Cursor to use its agents. Now, you can call those same agents from anywhere in your stack with a few lines of TypeScript.

Getting started is a single command:

From there, you create an Agent instance, send it a task, and stream the response back — all in TypeScript. Here’s the minimal example from Cursor’s announcement:


import { Agent } from "@cursor/sdk";

const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2" },
  local: { cwd: process.cwd() },
});

const run = await agent.send("Summarize what this repository does");

for await (const event of run.stream()) {
  console.log(event);
}

The Agent.create() call accepts an apiKey, a model field (where you specify which model to run), and either a local or cloud configuration depending on where you want execution to happen.

Why Building Your Own Agent Stack is Hard

Before diving into what the SDK offers, it’s worth understanding the problem it solves. Building fast, reliable, and capable coding agents that run safely against your data requires meaningful engineering effort: secure sandboxing, durable state and session management, environment setup, and context management. And when a new model ships, dev teams often have to rework their agent loops entirely just to take advantage of it. The Cursor SDK eliminates this complexity so teams can focus on building useful agents instead of maintaining the underlying infrastructure.

Build programmatic agents with the Cursor SDK · Cursor

Launch, steer, and compose custom agents with the Cursor SDK.

cursor.com

The Agent Harness: What “Same Runtime” Actually Means

SDK agents use the same harness that powers Cursor’s own products. ‘Harness’ here refers to the full set of supporting infrastructure that makes an agent effective beyond just the LLM call itself. In Cursor’s case, that includes:

Intelligent context management

— Codebase indexing, semantic search, and instant grep so agents retrieve the right code context before generating responses. This is critical because LLMs are only as good as the context they receive; poor retrieval leads to hallucinated or irrelevant outputs.

MCP servers

— Agents launched through the SDK can connect to external tools and data sources over stdio or HTTP, either via a .cursor/mcp.json config file or passed inline in the API call. MCP (Model Context Protocol) is an open standard for wiring tools into agent runtimes.

Skills

— Agents automatically pick up reusable behavior definitions from a .cursor/skills/ directory in the repository.

Hooks

— A .cursor/hooks.json file lets you observe, control, and extend the agent loop across cloud, self-hosted, and local runtimes — useful for logging, guardrails, or custom orchestration.

Subagents

— The main agent can delegate subtasks to named subagents with their own prompts and models via the Agent tool, enabling multi-agent workflows without custom orchestration code.

The Day GitHub Broke (and Developers Became Philosophers)

Manas kolaskar — Thu, 30 Apr 2026 18:28:51 +0000

There are outages…

and then there are events.

The recent GitHub disruption wasn’t just “oops, services are down.”

It was the kind of moment where the entire dev ecosystem collectively stared at their screens and went:

“So… what do we even do now?”

🧠 Stage 1: Denial

First reaction?

“Must be my internet.”

Classic.

You refresh.

You restart VS Code.

You question your WiFi.

You question your life.

🔥 Stage 2: Realization

Then it hits.

GitHub is actually down.

Suddenly:

PRs won’t load
Actions are stuck
Issues are gone
Your deploy pipeline is just… vibes

And somewhere, a senior engineer whispers:

“Don’t touch anything.”

😂 Stage 3: Internet Humor (Peak Productivity)

And then, the comments start rolling in:

“30% of our code is written by AI. Yeah… we can tell.”

“AI = Automated Incompetence”

“From ‘it works on my machine’ → ‘it worked on my local repo’”

“My dog ate my revert commits.”

“Who needs AI hallucination? Just click merge.”

Honestly?

The internet handled it better than most incident dashboards.

🤖 The AI Angle Nobody Wants to Admit

Here’s the uncomfortable part.

We’re generating code faster than ever:

Copilot
LLMs
AI-assisted everything

But outages like this reveal a gap:

👉 Speed has outpaced understanding.

When something breaks, a surprising number of devs are left asking:

“Wait… how does this part actually work?”
“Who wrote this logic?”
“Why is this even here?”

Spoiler: the AI doesn’t know either.

🧩 The Bigger Problem: One Platform to Rule Them All

Let’s be real.

GitHub isn’t just a tool anymore.

It’s infrastructure.

When it goes down:

CI/CD pipelines freeze
Teams can’t collaborate
Releases stall globally

We’ve accidentally built a world where:

One platform outage = global productivity loss

That’s… not ideal.

⚠️ What This Incident Actually Taught Us

Not “GitHub should fix their servers.”

That’s obvious.

The real lessons:

1. Convenience has a cost

We traded control for speed — and now we feel it.

2. AI is a multiplier (good and bad)

It scales productivity… and mistakes.

3. Most systems aren’t truly resilient

They’re just working fine… until they don’t.

🛠️ So What Now?

No, you don’t need to ditch GitHub.

But maybe:

Understand your pipelines beyond the UI
Don’t blindly trust generated code
Have at least some fallback plan
And occasionally… read your own code

Wild concept, I know.

🧠 Final Thought

The funniest part?

When GitHub went down,

developers didn’t stop working.

They just switched to:

memes
philosophy
and mild existential crises

And maybe that says more about our ecosystem

than the outage itself.

“It worked on my local repo.”

— probably the most accurate statement of 2026

I Let Claude Choose My Tech Stack for 6 Months. Here’s What I Learned the Hard Way.

Manas kolaskar — Sun, 26 Apr 2026 13:48:00 +0000

For the last 6 months, I was in flow state.

Every project I touched - from small side hustles to my Final Year Bachelor’s Project - was built with AI assistance. I’d open Cursor, fire up Claude Sonnet, and let the magic happen.

Why waste time thinking about architecture when the AI can just write the code?

Why argue over whether to use PostgreSQL or MongoDB when Claude can decide?

I was shipping features faster than ever. My GitHub looked like a construction site at 3 AM - messy, but moving.

I thought I was becoming a 10x developer.

Turns out, I was becoming something else entirely: a dangerous junior developer with a fake sense of expertise.

The Confession I Didn’t Want to Make

Here’s the truth I avoided for months:

I let Claude or Cursor choose my tech stack. Every. Single. Time.

"Hey Claude, build me a task manager with auth"

"Cursor, add real-time notifications"

"What database should I use for this?" → AI decides

And you know what? It worked. The code compiled. The app ran.

But then something strange happened.

I was presenting my final year project to my supervisor. He asked a simple question:

"Why did you choose WebSockets over Server-Sent Events for this specific feature?"

Silence.

I didn't know. Claude chose WebSockets. I just accepted it.

Then he asked:

"What happens if 10,000 users hit this endpoint at the same time? Walk me through the queueing system."

More silence.

I realized something terrifying: I had never actually understood how any of my systems worked internally.

I was just an AI prompt engineer. Not a software engineer.

The Video That Broke My Brain (In a Good Way)

I was doom-scrolling YouTube when I stumbled across this:

👉 Why you suck at system design (and how to fix it)

(Watch it. I'll wait.)

The video didn't teach me a new framework or a fancy library. It did something worse (better).

It showed me how little I actually knew about the fundamentals.

The video made me realize:

AI is brilliant at syntax but terrible at context

AI will happily suggest a microservices architecture for a to-do list app

AI doesn't know your team size, your deadline, or your actual traffic patterns

AI optimizes for "it works now" — not for "it works at scale"

I had been treating AI like an architect. But it's not an architect.

It's an extremely fast typist who has read a lot of Stack Overflow posts.

The Painful Pivot

I stopped coding for 2 weeks.

Instead, I went back to basics:

Drew system design diagrams on paper (yes, actual paper)

Studied CAP theorem, load balancers, message queues, caching strategies

Asked "why" 100 times for every architectural decision

Read engineering blogs from Stripe, Discord, and Netflix

Then I went back to my final year project.

And I redesigned everything from scratch.

Not because the AI code was broken — but because I finally understood why certain choices were wrong for my specific use case.

I kept using AI. But differently.

Now I tell Claude: "I'm using PostgreSQL because I need strong consistency for transactions. Here's my schema. Help me optimize this specific query."

Not: "Build me a social media app."

The Lesson I Wish I Learned Earlier

AI is not your senior engineer.

AI is your rubber duck that can type really fast.

If you don't understand:

How your database handles concurrency

Why your API is rate-limited

What happens when your cache misses

How your message queue guarantees delivery

...then you don't actually know what you've built. You're just hosting AI's best guess.

What I Do Now (And What You Should Steal)

Here's my new workflow. It's slower. But it's mine.

Before (AI-driven) After (Human-driven)
"Claude, pick a stack" "I'll pick the stack based on my constraints"
"AI, write everything" "I design the system, AI writes the boilerplate"
No diagrams Draw first, code second
Fix errors by reprompting Fix errors by understanding the root cause
Never read the docs Read docs, ask AI to summarize
My golden rule now: Never ask AI to make an architectural decision that you couldn't defend in a job interview.

If you can't explain why Redis is better than Memcached for your use case, don't let AI choose for you.

The Hard Truth for Students (Like Me)

We're in a weird generation of developers.

We have superpowers (AI) but also new ways to shoot ourselves in the foot.

Your final year project isn't just about getting a grade. It's about proving you understand systems well enough to build reliable software.

If your AI builds it, and you can't explain it... did you really build it?

(I'll let you sit with that one.)

Where I'm At Now

I still use Cursor daily. I still love Claude.

But now I'm the architect. AI is my pair programmer who's really good at remembering syntax.

My code is slower to write. But it's mine. I understand every line. I know why every database is indexed that way. I can draw the entire data flow on a whiteboard.

And honestly? That feels better than shipping fast.

Fast is temporary. Understanding is forever.

Your Turn

Have you ever let AI overstep and make decisions it shouldn't have?

Or are you still in the "Claude knows best" phase?

Drop a comment below. Let's save each other from building beautifully broken systems.

If you found this useful, share it with a friend who's letting AI design their database schema. They might need to hear this.

P.S. Watch that video I linked. Seriously. It changed everything for me.