The ask was simple: use AI for faster, high-quality engineering. Not another shiny editor demo.
When I rolled Cursor out to engineering teams at Virgin Media O2, I wasn't shopping for a nicer IDE.
I was answering a harder question: how do we use AI for faster, high-quality engineering, without removing the humans who still have to verify and ship?
That's the spine of the rollout. Speed and quality together. Tooling in service of delivery, not the other way round.
You can feel what "not fast enough" looks like on a quiet bug ticket. Someone reported it. Someone else will get to it. Ten working days later (give or take) it finally moves. Not drama. Just lag. That scene isn't why we bought Cursor. It's what slow, fragmented delivery feels like when quality still matters and the queue still waits.
First lesson: token economics
When I trained people on Cursor, the first thing I looked at wasn't the flashiest agent demo.
It was token economics.
The teaching was simple. Plan mode should use a bigger model (something like Opus or Grok) because that's where you want depth. Execution can use a cheaper model (something like ChatGPT Luna or Gemini Flash) because that's where you burn turns doing the work.
Same IDE. Different jobs. Different meters.
I also intentionally gave people small budgets at the start, so they didn't feel AI was about to drive a huge bill. Once they got confidence (in the tool, and in their own judgement), we raised the budgets.
That's the human bit people skip. Trust first. Spend second. Not the other way round. High-quality engineering doesn't survive if everyone is scared of the bill, or burning Opus on every trivial turn.
)
Same direction for engineers and partners
A rollout only works if people aren't inventing their own way of working in private forks of the truth.
So we built Agent Plugin packages and distributed them through a private Cursor marketplace: team distribution, not the public marketplace. Engineers and partners could install the same packages, pulling in the same direction, instead of each team wiring their own half-finished setup.
What went in the packages was the boring stuff that keeps delivery aligned: things like internal NPM packages, infrastructure config, Next.js best practices, and the rest of the shared defaults you actually want everyone to inherit.
That's the unglamorous bit of an IDE rollout: shared defaults, shared agents, one private place to get them, without naming every partner in the room. Same standards in, faster quality out.
)
The pipeline
The path that actually moves work for engineering teams:
1. Jira automation triggers Cursor cloud agents to build
2. Bugbot reviews the change
3. A human stays in the loop via Slack
4. A human verifies, then schedules the release
Machines take the lag out of build and first-pass review. People still decide it's good enough. People still put it on the release train.
That's how you chase speed without pretending quality is optional.
(Public product notes. Cite the products, not as our metrics: Bugbot, Automations.)
The outcomes I own
Here's what I'll put my name on. These are my cleared claims for what that approach delivered:
Delivery speed: about 2×.
Defects: from roughly ten working days to next-day.
That second number still lands, not as proof we ran a bug-fix programme, but as proof the delivery loop got faster without abandoning quality. Ticket, wait, build, review, release compressed until "next day" stopped sounding ambitious.
The automation removes waiting. It does not remove responsibility.
)
Caveats
These are my cleared claims from how I ran the Cursor rollout with engineering teams. Which teams, which ticket types, which period still matter for how you read them. I'm not expanding into a fake baseline or a tidy ROI slide beyond what I've cleared.
Humans didn't leave the building. Slack is where the loop stays human. Verification stays human. Release scheduling stays human. The stack removed lag. It didn't remove judgement.
Thoughts
I didn't roll Cursor out to engineering teams to collect demos, or to turn engineering into a ticket firefighting story.
I did it to use AI for faster, high-quality engineering: shared packages so engineers and partners pull the same way, a pipeline that compresses wait time, and a person still on the release button.
The interesting question isn't "did you adopt AI?"
It's whether your engineering got faster and stayed good enough to ship.
What's next
Next up: we're going to build features using Jira, Figma and Skills.
Next week.
&w=3840&q=75)


