SpaceX is acquiring Cursor for $60 billion in an all-stock deal, announced three days after the largest IPO in market history. Anysphere, Cursor’s parent company, did roughly $2.6 billion in annualized revenue this year. The deal closes in Q3 2026 pending regulatory approval, and folds Cursor into the xAI division alongside Grok and the Colossus supercomputer cluster.
That headline is the kind of thing most developers will scroll past. The reason it matters has nothing to do with the dollar figure and everything to do with what the dollar figure implies: AI coding assistants are no longer a developer-tools category. They’re being absorbed into the same companies operating frontier model labs, compute clusters, and now public-market capital. Anyone shipping software in 2026 is going to feel the downstream effects, and most of them land squarely on how you design and test your APIs.
I’ve spent the last few months helping teams adjust their API workflows for AI coding agents. Below is what’s actually changing on the developer side, and a hands-on walkthrough of one part of the stack you can fix today: making sure your APIs are usable by the agents that are about to start calling them.
The deal in one paragraph #
Cursor popularized what people are now calling “vibe coding”, a workflow where a developer describes intent in natural language and the agent writes, edits, and sometimes runs the code. Stripe, Adobe, and Nvidia were already among Cursor’s enterprise customers, and Jensen Huang publicly called it his “favourite enterprise AI service”. The acquisition is xAI’s bid to close the gap with Anthropic, OpenAI, Google, and Meta on the AI-for-development front. SpaceX gets a distribution channel into engineering teams. Cursor gets access to compute it couldn’t have afforded otherwise.
What this signals for developers #
Three things are now true that weren’t obviously true a year ago.
AI coding agents are a permanent layer of the stack. When a company valued north of $2 trillion pays $60 billion to own a coding tool, that’s a long-term commitment to the category. Treating agent-assisted development as a passing trend isn’t a defensible position for any engineering org budgeting for the next two years. The 2025 State of the API report found that 70% of developers know about Model Context Protocol (MCP) but only 10% use it regularly. That gap is going to close fast.
The agent is now a first-class API consumer. When Cursor or any similar agent writes code that calls your API, the agent reads your docs, picks endpoints, generates request bodies, and interprets responses. If your API is ambiguous, under-documented, or returns unhelpful errors, the agent will write broken code confidently. Humans push back on bad APIs. Agents ship them.
The pace of generated code is outrunning the pace of test coverage. This is the part I keep seeing teams underestimate. An agent can write a feature in 20 minutes that takes 4 hours to manually verify against a real API. If you don’t have automated integration tests, the agent’s output is unverifiable. You ship vibes.
The agent-API interface problem #
Here’s the practical issue. An AI coding agent calling your API needs three things to do useful work:
- A machine-readable description of what your API does, ideally an OpenAPI 3.1 specification - A way to actually call the API during a session, with auth and environment context
- A way to verify the call worked, with assertions the agent can read
Most APIs in production have item 1 in some form. Items 2 and 3 are where things break down. The agent ends up either fabricating endpoint shapes (the dreaded hallucinated URL) or stopping short of running the request because it has no safe way to authenticate. The Model Context Protocol spec addresses this by giving agents a structured way to discover and call tools, and APIs are the natural unit of tooling.
The Postman MCP server exposes your Postman workspace to any MCP-aware client. The agent can list collections, see request schemas, run requests, and read structured responses. Below is what setting that up looks like for a working API.
Hands-on: making your API callable by an AI coding agent #
You’ll need:
Postman Desktopor the web app- A free Postman account - An MCP-aware client (Claude Code, the Postman VS Code extension, or any client that speaksMCP) Node.js v18+if you want to run the Postman CLI locally
Step 1: Start from a spec, not a request
If your API doesn’t have an OpenAPI spec yet, generate one. From a Postman Collection, you can export a spec directly. If you’re starting from code, the Postman generate-spec workflow can build one from your source files.
The spec is what gives the agent a stable reference. Without it, the agent guesses field names from your docs, which is fine until your docs are wrong.
A minimal spec for a user creation endpoint:
openapi: 3.1.0
info:
title: Users API
version: 1.0.0
paths:
/users:
post:
summary: Create a new user
operationId: createUser
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateUserRequest'
responses:
'201':
description: User created
content:
application/json:
schema:
$ref: '#/components/schemas/User'
components:
schemas:
CreateUserRequest:
type: object
required: [email, name]
properties:
email:
type: string
format: email
name:
type: string
role:
type: string
enum: [admin, developer, viewer]
User:
type: object
properties:
id:
type: string
email:
type: string
name:
type: string
role:
type: string
created_at:
type: string
format: date-time
Notice the enum
on role
. Agents read enums and respect them. Loose string
types are where hallucinated values come from.
Step 2: Build a collection with realistic test scripts
Import the spec into Postman and let it generate the collection scaffolding. Then add test scripts, or as Agent Mode to do it. Test scripts do two jobs here: they validate the response, and they leave a readable artifact the agent can use to confirm the call worked.
pm.test("Status code is 201", () => {
pm.response.to.have.status(201);
});
pm.test("Response includes a user ID", () => {
const body = pm.response.json();
pm.expect(body).to.have.property('id');
pm.expect(body.id).to.be.a('string');
});
pm.test("Email matches request", () => {
const body = pm.response.json();
const requested = JSON.parse(pm.request.body.raw);
pm.expect(body.email).to.equal(requested.email);
});
pm.test("Role is one of the allowed values", () => {
const body = pm.response.json();
pm.expect(['admin', 'developer', 'viewer']).to.include(body.role);
});
const created = pm.response.json();
pm.environment.set("last_created_user_id", created.id);
The last line matters more than it looks. Saving the ID to an environment variable lets the agent chain requests, calling GET /users/{{last_created_user_id}}
next without having to remember anything between turns.
Step 3: Expose the collection via the Postman MCP server
The Postman MCP server makes your collections, environments, and runs available to any MCP-aware client. Set your Postman API key as an environment variable:
export POSTMAN_API_KEY="PMAK-..."
Configure your MCP client to point at the Postman MCP server. For Claude Code, that’s a small addition to the MCP config file:
{
"mcpServers": {
"postman": {
"command": "npx",
"args": ["-y", "@postman/mcp-server"],
"env": {
"POSTMAN_API_KEY": "${POSTMAN_API_KEY}"
}
}
}
}
The agent can now list your workspaces, read collection schemas, and run requests against your API with the environment you’ve configured. When it generates code that calls your API, it has a verifiable example of the call shape and a way to actually try it.
Step 4: Run the collection from CI to catch agent-generated regressions
If an agent writes code that hits your API, the safest place to catch a bad call is in CI before the PR lands. The Postman CLI runs a collection against any environment from a pipeline:
postman collection run "Users API Tests" \
--environment "Staging" \
--reporters cli,junit \
--reporter-junit-export results.xml
A working run looks like this:
-> Create user (valid input)
POST /users [201 Created, 312B, 142ms]
✓ Status code is 201
✓ Response includes a user ID
✓ Email matches request
✓ Role is one of the allowed values
-> Fetch the user we just created
GET /users/usr_8a3f2b [200 OK, 298B, 89ms]
✓ Status code is 200
✓ Returns the same email
✓ Returns the same name
┌─────────────────────────┬────────────┬────────────┐
│ │ executed │ failed │
├─────────────────────────┼────────────┼────────────┤
│ iterations │ 1 │ 0 │
├─────────────────────────┼────────────┼────────────┤
│ requests │ 2 │ 0 │
├─────────────────────────┼────────────┼────────────┤
│ test-scripts │ 2 │ 0 │
├─────────────────────────┼────────────┼────────────┤
│ assertions │ 7 │ 0 │
└─────────────────────────┴────────────┴────────────┘
Wire this into GitHub Actions (or whatever you use) so the agent’s PR can’t merge without passing the same collection that defines what the API actually does.
Things to watch for #
A few patterns I’ve seen go wrong when teams first set this up.
Don’t ship a collection that depends on undocumented setup state
If your collection assumes a user exists, or a token is pre-issued, or some upstream service is in a specific state, the agent will run it and get confused when the assertions fail. Use pre-request scripts to create whatever state the request needs, or use a mock server for endpoints that aren’t ready yet:
if (!pm.environment.get("auth_token")) {
pm.sendRequest({
url: pm.environment.get("base_url") + "/auth/token",
method: "POST",
body: { mode: "raw", raw: JSON.stringify({
client_id: pm.environment.get("client_id"),
client_secret: pm.environment.get("client_secret")
})}
}, (err, res) => {
pm.environment.set("auth_token", res.json().access_token);
});
}
Be specific about errors
Agents rely heavily on error messages to recover. A 400 that says “Invalid request” is worthless. A 400 that says {"error": "email_already_exists", "field": "email"}
lets the agent retry with a different email instead of giving up or trying the same call twice.
Don’t expose write endpoints to an agent without guardrails
The first time I let an agent call a real DELETE
endpoint, it deleted three test users it shouldn’t have. Use separate environments for development and production, and consider read-only API keys for any environment you don’t fully trust the agent in. The Postman Local Vault keeps secrets out of cloud sync if you want a tighter boundary.
Run the same tests with and without the agent
If your CI passes when a human writes the code but fails when the agent writes it, the test is doing its job. If both pass and the feature still breaks in production, your assertions are too shallow. I look for tests that explicitly check the thing the agent is most likely to get wrong: field names, enum values, required headers, response shape.
What I’d actually do next #
If you’re a developer or eng lead reading the SpaceX-Cursor news and trying to figure out what it means for your week, here’s where I’d start:
- Generate an OpenAPI spec for your most-called internal API if you don’t already have one. Without it, every agent that touches your codebase is working from your README, and your README is wrong.
- Build a small Postman Collection covering the happy path and the three most common error cases. Don’t try to cover everything.
- Wire it into CI with the Postman CLI. Make agent-generated PRs run against it before they merge.
- Connect your editor’s AI agent to the Postman MCP serverso it can call the API during development instead of guessing what the API does.
The acquisition is going to make AI coding tools cheaper, faster, and more widely deployed inside engineering orgs. The teams that come out ahead are the ones whose APIs were already legible to a machine consumer, not the ones who get caught retrofitting that legibility under time pressure.
Try it on one API this week, see what breaks, and tell me where the friction was. I’m curious what fails first in your stack, because everyone’s failing in slightly different ways right now.
Resources #
Postman MCP server overviewPostman MCP server product pageThe Postman CLI documentationPostman Agent ModePostman test scripts referenceOpenAPI 3.1 specificationModel Context Protocol specificationPostman plugin for Claude CodePostman State of the API 2025