Skip to content

Invite-only

We write the code and maintain it. You bring the ideas.

Leave the coding to us. Your AI engineering team plans the architecture, writes the code, reviews it and merges it through machine gates, around the clock. The code is written on your machines, with your keys.

Request accessSee the audit trail
  • Your machines
  • Your keys
  • Every action audited
developerz.ai · fleetExample

AI devs at work

  • box-02Workingcheckout: writing the 3DS retry path
  • box-05Workingcheckout: reviewing the diff
  • box-07Workingbilling: fixing a red test run
  • box-11Idlewaiting for the next task

This pull request

Retry 3DS card authorizationsacme/checkoutfix/3ds-retry

  1. IssueRead, triaged, planned
  2. ReviewTests green, review answered
  3. MergedMachine gates passed

Auditpr.mergedacme/checkout · appended, append-only

An illustrative example, not a live feed: the fleet, pull request and audit views your dashboard renders, filled with made-up data.

We run the software side of your business.

No hiring rounds. One onboarding, and every AI dev after it. Consistent senior-level output, around the clock.

No hiring rounds
No job posts, no interview loops, no notice periods, no backfill when someone leaves. You describe the work and the work starts.
One onboarding, every AI dev after it
Your repository is onboarded once to be AI-first: its own rules, its specialist roster, its index. Every AI dev after that is configured for it, whether you run one seat or a thousand, because the context lives in the code and the audit log rather than in one person's head.
Consistent senior-level output
The same standard on a Tuesday morning and a Sunday night: every AI dev runs the same harness and the same prompt cascade, with your repository's own rules layered over ours, and nothing merges outside the review loop and the machine gates you set.

01The loop

An open PR is unfinished work, not an outcome.

One ask, end to end. A human is pulled in only for a decision that is genuinely theirs.

  1. Inputaskyour agent over MCP · GitHub issue · Linear · Sentry · webhook
  2. Scoutplana plan your agent starts can go straight to a box
  3. Triageexecutable workor dropped with a reason, or a question back to you
  4. Assignerpulled, not pushedan idle box claims the next ready task
  5. WorkerPRyour box, your AI dev, your tokens
  6. CI + reviewerfix looppush, CI, review, fix, until green
  7. Merge lanemergepast the machine gates, or held for a human
  8. Your deployproductionyour own pipeline ships the merge

Work comes in two main ways. Asks filed from your issues, your trackers, your alerts or your own agent go to triage, which judges each one on your own key: most become work, some are dropped with a reason, some go back to the asker with a question. Of the scout's work, a plan your own agent starts can go straight to a box; what the scout finds on its own rounds is filed as an ask like the rest. Idle machines pull the work from both, your AI devs write each pull request, review and CI trade laps until it is green, and the merge gate passes it or holds it for a human. After the merge, your own pipeline ships it.

  • in flight
  • waiting on a human
  • dropped with a reason
  • merged, in your pipeline
An illustrative animation, not a live feed: the machine names, the pull request references and the work moving through them are all made up, and nothing here is measured from our fleet.

Every transition is loggedPolicy refusals and escalations replay against a new policy, without re-executing

02The cost

What the work costs today, and what it costs here.

Two published figures anchor this page, and both are linked below. Every number we derive from them is labelled an estimate and shows its arithmetic, so you can redo it.

What you are paying forCostWhat that buys
One developer, at the US median$135,9801The median across every seniority, not a senior rate. One person, one working week.
One elite engineer, United States$654,0002Total compensation for a staff engineer at Google. Divided by 12, that is $54,500 a month for one person.Estimate
A team of 5, at the US median$679,9001EstimateOur arithmetic: 5 times the median wage. Salary only, so the real number is higher.
Consultants and contractorsBilled by the hour or by the engagementWe publish no rate here, because we have no source we can date for one. What is certain is that the work stops when the invoice stops, and the context leaves with the people.
developerz.ai$100 / mo flat, one AI dev$1,000 / ai-dev / moOne published price. The agents run on your own machines, on your own model keys, billed by your provider. Solo is one AI dev on a personal GitHub account.

A figure with a number beside it cites the source below. A figure we worked out ourselves says so and shows its inputs.

03The arithmetic

Run it over five years, at three team sizes.

Salary against our published Enterprise price, seat for seat. Every cell is arithmetic on two figures you can check, and both are listed under the table.

TeamAfter 1 yearAfter 3 yearsAfter 5 years
5 engineers$619,900$1,859,700$3,099,500
10 engineers$1,239,800$3,719,400$6,199,000
25 engineers$3,099,500$9,298,500$15,497,500

How this is worked outEstimate3

  • US median pay for a software developer: $135,980 a year.1
  • Our published Enterprise price, in US dollars: $1,000 per AI dev per month, which is $12,000 a year.
  • Per seat, per year: $135,980 less $12,000 is $123,980. Multiply that by the team size, then by the number of years.
  • Seat for seat: the same number of AI devs as engineers. This is a price comparison at equal headcount, not a claim about how much either one produces.
  • Salary only. Employer taxes, benefits, equipment, office, recruiting and management time are not counted. Neither are model spend and the machines the code is written on, which sit on your side, so the real difference can be larger or smaller than this table shows.
  • Model spend is in neither column. You bring your own keys and pay your provider directly.

04Our view

Software is going AI-first. We believe the companies that are not will disappear to the ones that are.

That is our reading of the market, not a measurement, and not a warning pointed at you. You decide whether it is true, when to move and how far. When you do move, the labour is ours and the repository, the keys and the gates stay yours.

A forecast we hold, written down as a forecast. You are the one who acts on it.

05Who it is for

Two ways to ask. One delivered pull request.

You do not need a written specification to get work done here, and you do not have to stop writing one. The ask arrives in whatever language you already think in, and it leaves as the same reviewed, gated change.

If you do not write code

Ask in plain language.

Customers keep giving up at checkout when their bank asks them to confirm the payment. Sort that out.

Scout reads your repository, asks you what it cannot work out on its own, and writes the plan as pull-request-sized tasks with acceptance criteria. You approve the plan, and you never open an editor.

If you have spent your career inside the code

Steer at the level you actually work at.

Make the retry idempotent on the payment intent, back off between attempts, and never retry a hard decline.

Your judgement is the scarce part and it stays yours: your repository rules, its specialist roster and its merge policy are yours to set, and every AI dev after that is configured for them. What you stop spending the week on is typing out what you already know.

Two example asks, invented for this page. Both end in the same place: one pull request that passed review, CI and the gates you set.

06The cast

What we replace, role by role.

Six jobs a product team does. Five ship today, each a named role you address by name on your own box. One does not, and says so.

  • scout

    Plans the work, never codes it.

    Your box

    Sits on a box with the repo checked out. Converses, grounds itself in the real code, and authors a dependency ordered plan of pull-request-sized tasks with acceptance criteria.

    Instead of The architecture pass that happens before anyone opens an editor.

  • worker

    One task, one pull request.

    Your box

    Branch, code, verify, push, open the pull request, answer the review comments. Every step an audited event.

    Instead of The ticket that sits in a queue until somebody has a clear afternoon.

  • reviewer

    Judges new changes only.

    Your box

    Reads what changed since the last review, in light of what was already decided. Never fakes a human approval.

    Instead of The review that waits for a reviewer with time.

  • worker

    Red build, same agent.

    Your box

    The agent that opened the pull request watches its own checks, reads the failing log and pushes the fix. It does not hand the red build back to you.

    Instead of The morning spent bisecting somebody else's flake.

  • devops

    Diagnoses first, and asks before production.

    Your box

    Reproduces a failure, reads production and reports what it found; a report is its default deliverable. Touching your infrastructure takes a fresh signed approval, and it runs on your own box.

    Instead of The escalation that starts with somebody reading logs at midnight.

  • Product and interface design.

    Planned

    Not built. There is no design role in the platform today and no visual tooling behind one, so we do not sell it as one.

07Your stack

Your repo as it stands, or a new one from nothing.

The table below is a shortcut, not a gate. A stack it recognises gets its setup, dev and check commands seeded without asking anyone; a stack it does not recognise is recorded as unrecognised and your own model writes the commands instead.

The repo you already have
Any language, including the parts nobody wants to open. We read the tree, seed the commands we can, and say plainly which ones we guessed.
Anything the table does not list
Recorded as unrecognised rather than forced into the nearest row. The setup, dev and check commands are then authored against your repo instead of read out of a table, and the run says which happened.
A new project from nothing
An empty repo is scaffolded with the house framework, through that framework's own generator. We vendor no templates, and an existing tree is never rewritten into a framework: that is a change a person approves, not a scaffold.

Recognised out of the box

  • Bun
  • Node
  • Python
  • Go
  • Rust
  • Ruby
  • ultimate

Nothing here requires a recognised stack. The recognised list only decides whether the first commands arrive for free.

08Your pace

Start small. Widen it when you are ready.

There is no big bang here and no rollout we run on your behalf. You buy seats, you point them at one repository, and you widen from there on the schedule you set.

  1. Pilot

    A few AI devs, one repository.

    Onboard one repository to be AI-first and put a few AI devs on the work nobody enjoys: the flaky test, the dependency bump, the ticket that has been open since spring. Auto-merge resolves off until your own policy file turns it on.

  2. Expand

    Add seats, not headcount.

    A seat is one concurrent AI dev, and how many you run is yours to choose. Add repositories as the trail earns your trust: every action is logged, and every refusal comes back as a named code you can route on.

  3. Lead

    Keep your best engineers on the work only they can do.

    Writing the code by hand is the part we take. Architecture, product judgement and what is worth building next stay with the people you already have, and they get their week back to spend on it.

The pace is yours. `project disable` stops new work on a repository and cancels its queued tasks; the row and its history stay, and `add` re-enables it for new work. Cancelled tasks don't come back. Your .dz/maintainer/maintainer.yml is yours to edit, and the next run is the policy you wrote. Some steps have not been verified as reversible yet, and we name which ones as each ships.

09The boundary

Your machines. Your keys. Your gates.

We sell orchestration, judgement and the trail. We never resell inference, and we never run the coding agent on our own hardware, on any plan.

You ownYour boxes

The machines, the keys and the policy

Where it runs
Your own VMs. The runner dials out to the control plane and opens no inbound port.
When it runs
Round the clock. It pulls the next task and streams every event back while you sleep.
Whose model keys
Yours. Every supported provider, plus any OpenAI-compatible endpoint. We never resell tokens.
Who sets the merge policy
Your own .dz/maintainer/maintainer.yml. Turn auto-merge off, or route a lane through a human, and that is the policy.
Who ships to production
Your own pipeline, after the merge. We do not operate your deploy.
We ownOur servers

Orchestration, judgement and the record

Who decides a merge
One gated merge call. The gate is re-asserted on a fresh read, bound to the commit it validated, and every refusal is a named code.
The record
Append-only and tamper-evident: each row carries the hash of the row before it, so a gap is visible.
Other bots
CodeRabbit, Copilot, Dependabot and Renovate are never answered: no bot argues with a bot. A Dependabot or Renovate bump is still work, reviewed and merged through the gate.
The line between what you own and what we are accountable for.

You bring · 01

Access

Repos, APIs, MCP servers and servers. Scoped credentials you can revoke in one move.

You bring · 02

VMs

The boxes the fleet runs on. Developers that do not sleep, on hardware you already pay for.

You bring · 03

AI tokens

BYOK across every supported provider, plus any OpenAI-compatible endpoint.

10The field

Coding agents got good. Owning the outcome is still a job.

Stage by stage: who does the work, and who carries it afterwards. Our column names a mechanism in our own code. Theirs quotes their own documentation.

Stagedeveloperz.aiClaude CodeDevin
Where the agent runsYour own VMs. The runner dials out to the control plane and opens no inbound port.Your own machine, or Anthropic's cloud.Cognition's cloud by default; a terminal client hands longer tasks to it.
Running while nobody is watchingRound the clock on your fleet. It pulls the next task and streams every event back.Routines run in the cloud and keep running when your computer is off.You follow the session in an embedded IDE and can take it over.
Writing the changeOne task, one branch, one pull request. Every step an audited event.One non-interactive command writes the change and raises a pull request for review.A session ends in draft pull requests waiting for review.
Reviewing what changedReads only what moved since the last review.Automatic code review on every pull request, through GitHub Actions.
Deciding the mergeOne gated merge call. The gate is re-asserted on a fresh read, bound to the commit it validated, and every refusal is a named code you can route on.
Shipping to productionYour own pipeline, after the merge. We do not operate your deploy.
Product and interface designPlanned No design role ships today, and we do not sell one.

The Claude Code and Devin columns describe what those products' own documentation states, read at code.claude.com/docs/en/overview and docs.devin.ai/get-started/devin-intro in September 2026. A dash means we found nothing published to cite, not that the product cannot do it. Named comparisons, with cited and dated prices, are one click away. Open the side-by-side comparisons

11The harness

Same model. The harness is what you are buying.

Point your own key at the same model a bare CLI would call. What changes is the loop around the call.

Left: one call, one answer, and the rest is yours. Right: the same model inside a loop that plans first, reviews its own diff, fixes its own red build and stops at your policy.

A model on its own

One prompt, one answer.

Judging the answer, wiring it in and getting it shipped all stay with you.

  1. You ask
  2. It answers
  3. You take it from there

The same model, in the harness

One task, one gated pull request.

The loop runs on your box, under your policy, until the change is merged or refused with a reason.

  1. Plans the task before touching a file
  2. Writes the change on its own branch
  3. Reviews its own diff before anyone else sees it
  4. Reads the red build and pushes the fix
  5. Stops at the gate your .dz/maintainer/maintainer.yml sets
  6. Writes every step to an append-only trail

We do not publish the briefs the harness seats the model in. What it does is public; how it is asked is not.

12Price

Seats. Not meters.

Access is invite-only today, so every plan below starts with an application.

  • Solo

    $100 / mo, flat, one AI dev

    • One AI dev, on your own boxes
    • Public and private repos on your personal account
    • One flat monthly price, no metering
    Request access
  • Recommended

    Enterprise

    $1,000 / ai-dev / mo

    • Direct a fleet, not an editor
    • AI devs, code review and self-hosted CI
    • 3 concurrent CI slots per AI dev
    • Zero quotas
    Request access

  • OSS Free

    $0 / mo (with limits)

    • Issue and PR handling on public repos
    • Public repos under your own name, no repo cap
    • 20 agent-hours a month (5 in your first)
    Request access

13Self-improvement

The platform is maintained by the platform.

developerz.ai is built the way your repository is worked: an AI dev plans the change, writes it, reviews its own diff, fixes its own red build and merges through the same machine gates. What you get next is the output of the product running on itself.

The improvement loop, drawn. The repository it runs on is our own.
  1. An AI dev plans the change against our own repository.
  2. It writes the change on its own branch and opens one pull request.
  3. It reviews its own diff before anyone else reads it, then answers the review it gets.
  4. A red build goes back to the same agent, not to a person.
  5. It merges through the machine gates, or it is refused by a named code.
  6. It is released, and the loop starts again on the next one.

It improves on our side of the line, never past yours.

Getting better does not mean getting looser. Every change that reaches your repository still crosses the policy you wrote and the gate you configured, and it is refused by name when it does not pass. A platform that could improve its way past your gates would be a platform you no longer hold, and that is not the one we sell.

No count of what that loop produced is published here. The dated entries below are the evidence instead.

14Shipped

What shipped, and when.

Dates, not a count: the most recent releases, read straight off the release notes.

  1. v4.314.1v4.314.1
  2. v4.313.1v4.313.1
  3. v4.313.0v4.313.0
  4. v4.312.1v4.312.1
Read the full changelog

The film

One minute on where software is going.

From punched cards to machines that write code, and what it takes to trust the work they ship. Narrated, 60 seconds.

Footage, voice and music generated with AI.

15Questions

Frequently asked questions

Whose API keys does it use?

Yours. BYOK is the only mode: your own key from Anthropic, OpenAI, Gemini, DeepSeek, Kimi, GLM, MiniMax and more, or any OpenAI-compatible endpoint. We never resell tokens.

Does it write the code?

On Solo and Enterprise, yes, and it maintains it: your AI devs write the code on your own enrolled boxes, with your own keys, and developerz.ai orchestrates the work, reviews every pull request and gates the merge. An issue you hand to Copilot is written where GitHub runs Copilot. On OSS Free no AI dev writes code: it triages issues and cuts releases on your public repositories, on your key.

Can I see what it did?

Yes. Every tool call and decision is logged. If it isn't logged, it didn't happen.

What about CodeRabbit or Dependabot?

It never converses with another bot: no bot-on-bot loops. It waits for a CodeRabbit review to settle before acting, and it reviews, fixes and merges Dependabot and Renovate PRs through the merge gate when your policy covers them.

Ship more. Maintain less.

We expect software to be written faster than any team can review it. Bring your repos, your boxes and your keys. We bring the org that keeps up.

Request accessmcp.developerz.ai

Sources

  1. US Bureau of Labor Statistics, Occupational Outlook Handbook, May 2025 Open the source
  2. levels.fyi, Google software engineer salaries, checked September 2026 Open the source
  3. Estimate computed from the US Bureau of Labor Statistics median annual wage, May 2025