Coding with Opus through pi on Cursor
The first post covered reviewers. This one asks the harder question: can Opus, running through pi on our Cursor subscription, do the coding itself?
The test
We gave it two real satelle features and ran each through satelle's full process. A planner wrote the plan, and two reviewers had to accept it. Then a single pi coder, on Cursor's Claude Opus 5.5, wrote the code in one go. A panel then reviewed the code against the feature's acceptance criteria, another reviewer checked the change stayed in scope, and automated checks ran the build, the unit tests, formatting and vet. The last checks happened at release.
Both review panels were Opus 5.5 fast and Composer 2.5 fast, both through pi on Cursor. It was Composer's first time reviewing real work, and it accepted the correct work it was shown.
Results
| Feature 1 | Feature 2 | |
|---|---|---|
| What it built | pi reviewers and coders running in pi's RPC mode, with real events, a clean exit on answer, stall handling and usage reporting | a coder whose work is rejected in review gets sent back with the findings to answer |
| Coder time | about 30 minutes | about 37 minutes |
| Files changed | 25 | 17 |
| Lines added | about 1,640 | about 870 |
| Acceptance criteria met | 9 of 9 | 5 of 5 |
| Code review | every check accepted on the first try | every check accepted |
| Shipped in | satelle 0.0.781 | satelle 0.0.782 |
Nobody edited the code by hand.
Planning was the hard part
Planning took more rounds than coding. The plan for feature 2 was rejected twice. The first version duplicated something that already had an owner in the code. The second contradicted one of its own criteria. It passed on the third round. Feature 1's plan needed four rounds. Each rejection was a real design problem, caught before any code was written.
What went wrong
The first coder run hit a "resource_exhausted" error from Cursor. A retry worked, and we were not actually over any limit.
During one code review, the Cursor provider pi uses dropped its connection and reopened it, and the review lost its original input. The reviewer recovered by reading the diff and the evidence for itself, and it still judged correctly. But it shows the provider is fragile on long runs.
The provider also warned that its copy of Cursor's protocol is behind the current one. It works by tracking a protocol Cursor does not publish, so it can break whenever Cursor changes it.
Cost
Same as last time. On the Cursor plan, Claude and GPT switch to pay-as-you-go once the included quota runs out, and a single Opus fast review cost between $0.38 and $2.20. Composer stays inside the included quota.
Where that leaves us
Opus coded both features through pi on Cursor and passed every check on the first try, with no human edits. The coding role on pi now works on two real features. The weak point is the third-party Cursor provider, not the model and not pi.
Still to come: a bigger set of review cases, and a costed comparison of taking a change from pull request to release on a local machine against doing it on a remote server.
To be continued.