The autonomous software factory
A specification goes in. A reviewed pull request comes out.
Wharfly runs several coding models in parallel on the same task, keeps the one that passes the tests, has it audited by other models, then opens the pull request. On a server dedicated to you, with your accounts and your keys.
- Autonomous
- Verified
- Measured
01 · What it is
A software factory. You specify, it executes.
You write the specification for each task. Wharfly codes, tests, has it reviewed by models from other families, opens the pull request, merges when all your conditions hold, and deploys as a canary with automatic rollback. There is no chat window to watch.
When a condition is not met, the task stops and waits in an exception queue, with the detail of what blocked it. That is the only place you step in.
What you supply
- A repository
- git, with the commands that build and test it
- A specification
- with acceptance criteria a command can verify
- Models
- ours, yours, or both
02
A task's journey
Every stage has inputs, deliverables and a passing criterion. Stages marked automatic use no model: they are commands, therefore facts.
-
Admissibility
The specification is refused if an acceptance criterion is not measurable or a deliverable is not named. Nothing starts before that.
-
Coding — one to three coders in parallel
Each on its own copy of the repository, blind to the others, and it writes the tests.
-
Verification of each candidateautomatic
Build, lint, tests. A failing candidate is eliminated here.
-
Selection
A model from another family compares the surviving candidates on their test results and diffs, and picks a winner. It fixes nothing.
-
Security audit and architecture audit
Two distinct models, read-only, judging against your declared criteria. The blocking severities are the ones you defined.
-
Functional run-throughautomatic
End-to-end scenarios on a throwaway environment, if your project declares one.
-
Pull request, merge, deploymentautomatic
The merge happens if all your rules are true: green tests, no file out of scope, no sensitive path touched. Deployment is a canary, with automatic rollback.
03 · Several coders, one winner
Eliminate by testing before comparing
One model can fail a task two others complete. Rather than retrying in series, Wharfly launches several coders in parallel on different models.
Selection is therefore never made on an impression. It is made on what builds, what passes, and what stays inside the requested scope. If only one candidate survives, there is nothing to compare and the stage is skipped.
On the higher tiers, the tests can be written by a model that does not compete: candidates are then judged on a suite none of them wrote.
One specification, one declared scope
build · lint · tests
passesbuild · lint · tests
passestests failing
eliminatedSelection — model from another family, on evidence
One winner, then audits, then pull request
Schematic: the number of coders is capped by your tier and reduced when a quota cannot see the task through.
04 · Why not just an interactive harness
Wharfly does not replace those models — it consumes them
The coding models on the market are the engines. Wharfly is the factory around them. What those tools, excellent interactively, do not do:
They assume you are there
An interactive harness waits for your answers. Wharfly is a line: it runs when you are away, and when it can go no further it stops at a defined place with the reason and the evidence. The difference is not the model's intelligence, it is the machinery around it: gates, evidence, budget caps, escalation expressed as rules, an exception queue.
They compare nothing
One model, one attempt. Wharfly puts several coders on the same task and selects on test results. That is not a preference, it is a different distribution of outcomes.
Nothing checks what the model claims
Interactively, “the tests pass” is what the model tells you. Wharfly runs the build, the lint and the tests itself, and takes the exit code as fact. It then compares the touched files to the declared scope, and has the diff reviewed by models from other families: a model does not review its own output.
You don't know the cost per deliverable
Wharfly records tokens by class, prices them from a dated grid, and gives you the cost per accepted deliverable. That is the only figure that lets you choose a model rationally. A session total does not say it.
Nothing coordinates several repositories
A change crossing three repositories becomes three specifications, three tasks, a declared order, dependency resolution against the upstream repository's winning branch, and a barrier before the first merge.
Nothing manages your quotas
Wharfly knows the state of your plans, does not start a task it cannot finish, and can switch to a usage-billed route if you allow it.
There is no team layer
Roles and permissions, per-project workflows, a log of every decision with the rule that fired it, a shared exception queue, logs shipped to your SIEM.
And to be clear
If you want to pair-program with a model, an interactive harness is the right tool and Wharfly is the wrong one. Wharfly is for work you can specify and want executed without you.
05
Our models, or yours
The choice is made per provider, not globally. You can take one provider from us and another with your own keys.
Wharfly models
Nothing to subscribe to or configure. We provide access through our gateway, with a virtual key of your own, capped and revocable. One invoice. We follow the catalogues' evolution for you.
Your own accounts
Your API keys, your coding plans, or your self-hosted models. You keep your negotiated rates, your commitments and control over the path your code takes.
| Criterion | Wharfly models | Your own accounts |
|---|---|---|
| Start-up | immediate | you supply keys or accounts |
| Billing | one invoice, usage-based | billed by your providers |
| Cost predictability | usage-based, measured per task | per your contracts and plans |
| Quotas | managed by us | yours, watched and displayed |
| Path of your data | providers displayed per workflow | the ones you choose |
| Provider outage | we switch over | you decide the policy |
| Mix per provider | yes | yes |
Transparency, in both cases: the list of providers a workflow uses is displayed in the interface. Your code is sent to them; you must know which ones.
06 · What Wharfly does not do
The limits, stated upfront
Better said before the demo than during the first incident.
It does not write your specification
The quality of what comes out depends entirely on the precision of what goes in. A vague specification produces work to throw away.
It does not guarantee atomic multi-repo merges
That does not exist outside a monorepo. What it does guarantee: validate everything before starting to merge, and tell you exactly where it stopped.
It decides nothing that is not written down
Faced with a situation outside your rules, it stops and hands it back. Which means someone has to work that queue.
It does not make a bad model good
It lets you try several and measure which one delivers, on your repositories, at what cost.
Its gates only catch what you asked them to catch
Blocking severities, sensitive paths and acceptance criteria are declared by you. That is a strength, and it is a responsibility.
07
Security and isolation
- One dedicated server per customer. Your code, your working copies and your artefacts stay on it.
- The control plane holds only metadata: states, verdicts, volumes, costs. Never code, never a patch, never your secrets.
- Agents hold no privileged rights. Publishing, merging and deploying are configured actions, executed by the platform under your conditions, never capabilities handed to a model.
- Sensitive paths. You declare what must not be touched without human eyes: migrations, infrastructure, authentication, secret handling, dependencies. A task that touches them goes to exceptions.
- Logs exportable to your SIEM.
- Optional code analysis, on your repositories and on each task's diff, whose findings feed the security audit.
08
Tiers
What really separates the tiers: the number of parallel coders. It is what changes the probability that a hard task lands first time, and it is also what multiplies model consumption. Everything else is comfort.
Starter
99 $ / month
1parallel coder
- 2 simultaneous tasks
- 1 project, 1 repository
- 2 users
- security audit
- rule-based auto-merge
Promost common
199 $ / month
2parallel coders
- 4 simultaneous tasks
- 5 projects, several repositories each
- 10 users
- security + architecture audits
- multi-repo groups
- canary with rollback
- log export to your SIEM
- tests by a non-competing model (option)
Enterprise
On quote
3parallel coders
- custom sizing
- unlimited projects and users
- custom severities
- per-repository model restriction
- code analysis included
- single sign-on
- managed exception-queue option
- specification-writing support
| Criterion | Starter | Pro | Enterprise |
|---|---|---|---|
| Price | 99 $ / month | 199 $ / month | on quote |
| Parallel coders | 1 | 2 | 3 |
| Simultaneous tasks | 2 | 4 | per sizing |
| Projects | 1 | 5 | unlimited |
| Repositories per project | 1 | several | several |
| Users | 2 | 10 | unlimited |
| Dedicated server | yes | yes | yes, sized |
| Audits | security | security + architecture | + custom severities |
| Tests written by a non-competing model | not included | option | yes |
| Multi-repo groups | not included | yes | yes |
| Rule-based auto-merge | yes | yes | yes |
| Canary deployment with rollback | not included | yes | yes |
| Wharfly models or your accounts | yes | yes | yes |
| Per-repository model restriction | not included | not included | yes |
| Code analysis | option | option | included |
| Log export to your SIEM | not included | yes | yes |
| Artefact retention | to be set | to be set | to be set |
| Single sign-on | not included | not included | yes |
| Working the exception queue | you | you | managed option |
| Specification-writing support | not included | option | yes |
| Support | by email | by email | email + phone |
- Model consumption is billed by usage, on top of the tier, unless you use your own accounts.
- A tier caps the number of coders; you remain free to use fewer, task by task.
09
Onboarding
Your server is provisioned
and attached to your account.
Your model access is connected
ours, yours, or a mix.
Your repositories are described
build and test commands, default branch, sensitive paths.
A first workflow is composed
validated by a dry run, then tried on a real task in a sandbox repository.
Typical duration: to be set — after the first onboardings.
10
Frequently asked
Where does my code go?
It is cloned onto your dedicated server and sent to the model providers you chose, for the files the task needs. The control plane never receives code.
Who owns the code produced?
You do. Wharfly produces branches and pull requests in your repositories. There is nothing to retrieve from us, and nothing to migrate if you stop.
Does it merge to the main branch without a human?
Only if you configure it that way, and only when all your declared rules are true. You can require human eyes, or leave merging out of scope.
What if the AI breaks something?
The gates are executed, not declared: build, lint and tests actually run, newly failing tests compared against the starting state, touched files checked against the requested scope, sensitive paths, then canary and automatic rollback at deployment. Those gates only catch what you asked them to catch.
What happens when it doesn't land?
The task stops in the exception queue, with the reason, the committed cost and the evidence. Nothing is abandoned silently.
Which languages, which stacks?
The ones your repository can build and test. You declare the commands. If a criterion cannot be verified by a command, Wharfly cannot make a gate of it.
Does it work on a large existing repository?
Yes. The constraint is not the repository's size, it is a task's scope: a task exceeding the declared cap is refused at the door, with a suggested split.
Do we really have to write specifications?
Yes, and it is most of the effort. An optional scoping interview, which consumes no task, helps turn a vague request into a workable specification.
Are our secrets exposed to the model providers?
Your operational secrets never leave your server and are never in the control plane. Your repositories' contents, however, are sent to the models you chose: if secrets are committed in your code, they go with it. One more reason to enable secret detection, which the code-analysis option covers.
Is our code used to train models?
That depends on each provider's terms and the mode you choose. We cannot commit on a third party's behalf: we display which providers each workflow uses, so you can check their terms and exclude them if they do not suit you.
Can it be installed on our own infrastructure?
The server is already dedicated to your organisation. Hosting on your side is discussed case by case.
What if a model provider goes down or changes its terms?
The catalogue is extensible and routing is configuration: a stage's model is changed without touching your repositories. Fallback policies are declared in the workflow.
How long does a task take?
It depends on the task, the number of coders and how long your tests run. The platform measures and displays those durations for your own tasks; we do not publish an average that would mean nothing.
Are we locked into the platform?
No. The result lives in your git. Your workflow configuration is exportable.
Is there a service-level commitment?
to be set
11 · Contact
Three intentions, three answers
- Request onboarding
- Ask a technical question
- Request an Enterprise quote
- Legal entity
- Olimar Développement inc.
- Sales email
- to be supplied
- Support email
- to be supplied
- Phone
- to supply or omit
- Postal address
- to be supplied