Claude Code, Codex or Cursor: Starko Operates the Coding Agent You Already Use
Starko does not replace your coding agent. It operates it. Claude Code, OpenAI Codex or Cursor writes the code, using your own credentials and your own model choice. Starko decides what to build from customer feedback, writes the brief, provisions an isolated sandbox, verifies the result, has a reviewer agent read the diff, and keeps the ledger. This post explains the split, what you configure, and why the system around the model matters more than the model.
The agent is not the hard part anymore
Agents are good at writing code and widely used for it. Anthropic's Economic Index for September 2025 found that 77% of enterprise API transcripts showed automation patterns, where a task is handed over and completed with minimal back and forth, against 12% showing augmentation (). GitHub's coding agent created more than a million pull requests between May and September 2025 ().
Trust has not kept up. Stack Overflow's 2025 Developer Survey found 46% of developers actively distrust the accuracy of AI tools against 33% who trust it, and only 14.1% use AI agents daily at work while 37.9% have no plans to (). The gap between "agents can write code" and "I will merge what they wrote" is where a factory does its work.
So the question for a team is not which agent writes the best code. It is what happens before the agent starts and after it stops.
What the agent does and what Starko does
The left column is interchangeable. The right column is the product.
Bring your own agent and credentials
Each project chooses its agent. You connect your own Anthropic key for Claude Code, your own OpenAI key for Codex, or your Cursor account, and you pick the model. If you would rather not manage provider accounts, Starko can supply the model and provider instead. Starko tells the agent which environment variable names exist in the sandbox, never their values. Keys are shown masked in the project settings and merged on save.
Two consequences follow. Your model spend stays on your own account, visible in your own provider dashboard, and your choice of model is not tied to Starko's roadmap. When a provider ships a better coding model, you switch the project setting.
Enterprise plans go a step further: self-hosted models on dedicated, bare-metal runners, for teams whose code cannot leave their own infrastructure.
The sandbox: where control actually lives
Every run gets an isolated environment created for that run and destroyed when it finishes, whether it succeeded, failed or timed out. A timed safety net sweeps up anything a crashed run leaves behind.
What makes the sandbox safe to hand to an agent:
- Repository-scoped tokens. Access to your repository comes from a short-lived token scoped to that repository. It expires on its own.
- No environment key inside. The key that unlocks project secrets never enters the sandbox, and a run refuses to start if a key file survives from a previous one.
- Transcript scrubbing. Tokens, including the newer GitHub formats, are scrubbed from transcripts before they are shown, streamed or stored.
- Warm snapshots. Each project keeps a snapshot with dependencies installed, so a run boots in seconds and fetches the latest commit. The agent is not reinstalling your toolchain on every run.
- Your real commands. Project settings hold the commands to run: tests, typecheck, lint, build. Starko runs them itself after the agent finishes and records the exit codes.
The agent can be any of the three. The sandbox is the same.
The brief: why runs on your codebase stay on task
A coding agent in a fresh chat window starts with nothing. A run starts with a brief Starko assembles: the ticket and its internal thread, the customer transcript, the session replay analysis when there is one, the project's standing instructions, and a repository map written by an earlier research run.
The standing instructions are the first thing to set up on a new project. They are a per-project briefing document: conventions, gotchas, "always run the tests in package X", "never touch the migrations folder". They are injected into every run for that project regardless of which agent runs it.
Runs also leave notes for the next one. Learning lines from a run become backlog tickets and are staged back into the sandbox as a file. Concern and deviation lines are shown on the run so the reviewer knows where the agent was unsure.
The autonomy policy: how much runs without asking
Each project sets what Starko AI may do without a person:
- Ask before every run. Recommendations wait on the Improvements page until someone accepts them. The default.
- Auto-dispatch small fixes. Small bugs and improvements start on their own. Medium and Large wait for a decision.
- Open pull requests only. Runs may start and open pull requests, but nothing else happens automatically.
A reviewer revise or a red CI re-dispatches the run within a per-project cap in every mode. The merge is never automatic. The autonomy policy decides when work starts; a person decides when it ships.
This matters because the METR randomized trial from July 2025, which measured experienced open-source developers on 246 real issues, found they took 19% longer with AI tools while believing they had been 20% faster (). METR has since marked that result as out of date and published a follow-up with much wider uncertainty, but the lesson holds: perceived speed and real speed diverge, and a factory needs its own measurements rather than the agent's self-report. That is what the ledger is for.
The reviewer agent: a second model reads the diff
After the agent finishes and Starko has run the tests, a reviewer agent reads the full diff and posts a risk-rated assessment: green, yellow or red, with side effects, compatibility and performance scored separately. If it finds concrete defects, the run is dispatched to revise, bounded by the cap.
The reviewer is not limited to Starko's own pull requests. Point it at a repository and every pull request from your team gets the same verdict, concerns and evidence gaps in the pull request panel.
Switching agents mid-stream
Because the brief, sandbox, verification and review are Starko's, switching the agent on a project is a settings change. The ticket, the evidence format, the reviewer and the ledger stay the same. You can run the same class of ticket through two agents and compare merge rate and cost per merged pull request on the ledger before standardising.
Eval replay closes the loop on the Starko side. Flawed runs can be re-run against the current prompt and compared, so a prompt change is measured before it ships.
What you keep
- Your code, in your repository, with pull requests your engineers review and merge.
- Your model choice and spend, on your own provider account.
- Your conventions, injected into every run through project instructions.
- Your merge button. Nothing ships without a person.
For the walkthrough of a single run, read . For what the whole loop is, start with . For data handling and residency, see the .
Frequently Asked Questions
Which coding agents does Starko support?
Claude Code, OpenAI Codex and Cursor. Each project chooses one, with your own credentials and model choice, or with a model and provider Starko supplies. Enterprise plans can run self-hosted models on dedicated runners.
Does Starko use its own model to write code?
No. The coding agent you choose writes the code. Starko uses models for the surrounding work: triage, the brief, the reviewer agent and session replay analysis. It is the system around the coding agent rather than a replacement for it.
Where do my API keys live?
In the project's Starko AI settings, shown masked. The sandbox is told which variable names exist, never the values. Repository access uses a short-lived, repository-scoped token, and the environment key never enters the sandbox.
Can runs start without a person?
Only if the project's autonomy policy allows it, and only for the sizes you choose, such as Small fixes. Merging is never automatic. A person approves every pull request.
Can I switch agents on a project later?
Yes. The brief, sandbox, verification, reviewer and ledger belong to Starko, so changing the agent is a project setting. You can compare agents on the same tickets using merge rate and cost per merged pull request before standardising.
