Twelve questions, answered honestly

Result and flow

What do I get at the end?

A repository with history instead of a text block someone copies code out of: every completed work step leaves its own commit. In the hosted service the result arrives where review happens anyway — as a draft pull or merge request against the main branch, in a private repository. There is nothing to import.In detail: Integrations: the result is a repository

Which languages and frameworks are supported?

That is the wrong question — there is no list, there is a contract. Language, framework, architecture, version pins, conventions and check commands are stored as a profile; that is an optional feature. Once set up, it acts up front as a condition in every prompt, and the counter-check at the end is separately optional. The most well-trodden path is Java with Spring Boot in hexagonal architecture; other stacks take the same road, they are just less travelled.Why no list: Frameworks: what a stack profile contains

What if the result is no good?

There are two places for that, one inside the run and one after it. Inside, a consistency pass over the whole stands at the end. It is built so that a missing or disturbed measurement never waves anything through: it reports red and sends the affected work steps into capped repair rounds. The measurement itself is optional and not yet switched on in the hosted service; an additional build-and-test pass over the full state is optional and switched on there. Afterwards the draft pull request sits in your review tool: a comment on it becomes the requirement of an incremental follow-up run — an optional channel, switched on in the hosted service.The flow as a whole: How it works: phases and slices · Integrations: the feedback channel on the pull request

Does this replace my review?

No. A system that checks every step against the same invariants produces consistent code — not necessarily correct code. Whether the requirement itself is right, whether the domain cut holds, whether the solution fits the problem remains a human decision. The handover point is built for exactly that: in the hosted service the result arrives as a draft pull request, and a human merges it to the main branch.What guardrails do and do not do: Guardrails: what they do not do

Trust, data and control

Who sees my code?

In the hosted service every access to the factory carries its tenant: one organisation’s data does not exist for members of another, and the result sits in a private repository. What goes into the prompt is seen by the model provider — that is a question of model choice, not of where the service runs. And where generated code is built and tested in the hosted service, it happens in an unprivileged, throwaway pod instead of the coordinator.The boundaries in detail: Security: the boundaries

Does it run in Switzerland?

Operations run on the Infomaniak Public Cloud in Switzerland. The models themselves naturally live with their providers — that caveat is the answer, not an appendix. Which provider runs is a deployment decision; the connection is interchangeable and covers local models via Ollama.Where the data lives: Security: where the data lives

Can I use my own model keys?

Yes — on the Claude paths the service even requires it: without your organisation’s key it rejects the request with 401. For OpenAI-compatible providers, the organisation’s key overrides a configured default. This does not depend on the plan — each organisation sets its key itself, and whoever stores one settles directly with the provider.How it is stored and what it costs: Security: your organisation’s key · Pricing: what comes on top

How do I keep control?

How much supervision you keep is a per-project setting: from every action needs a release to only the consequential ones — but without a set level, the order runs through; the release levels are a per-project feature, not a default. What holds either way: in the hosted service the result arrives as a draft pull request, and a human merges it to the main branch.Why that is the real question: For product teams: hand over the execution, keep the decision

Getting started, connectivity and cost

How do I start?

In four steps, of which only the first is a form: create an account; connect the organisation, i.e. store GitHub access; register a project, which binds the project key to a repository — only registered, active projects run, and no YouTrack is needed for that: a project can just as well be created with its own internal tracker; then give the order. There is no start button: the ticket triggers the run — an optional channel, switched on in the hosted service.What the system docks onto: Integrations: the order comes from the ticket · Pricing: the five plans

Do I need YouTrack?

No: a project can be created entirely without YouTrack, with its own internal tracker — epics, stories and their states then live in the service’s own data store, with no external system involved. Whoever wants YouTrack anyway needs no instance of their own either: a shared default instance can be configured that a tenant without one falls back to. And you do not have to work in the ticket in any case: the second path is a comment on the pull request — an optional channel, switched on in the hosted service — which becomes an incremental follow-up run.Both channels side by side: Integrations: the paths in · Integrations: the shared default instance

What does it cost?

Five plans from $0 to from $2000 per month, per organisation and month. A plan is not a feature list but a setting: the model tier an organisation’s runs work with — in the hosted service the Haiku, the Sonnet or the Opus class. What a run consumes at the model provider comes on top and is recorded per run. The pricing page is preliminary and says itself what is not part of a plan today.The plans and their status: Pricing: the five plans · Pricing: status of this page

What does a mishap cost me?

As much as you cap. One ceiling for the organisation, one per project, one per run: each can be set, and of the three levels the tightest stops the run. Without a set amount, none applies — the default is unlimited. If one is set, the service adds up what organisation and project have already cost in the running month before starting; the run that breaks the ceiling itself is stopped on the way.How the three levels work: Operations: what can be capped

Your question is not here

Then it is probably the more interesting one. The twelve here are the ones asked most often — not the ones we have the best answers to.

Questions about operations, data sovereignty and billing resolve faster in a conversation than on a page that would have to anticipate every case. Questions about the flow are usually answered better by a real story from your backlog than by any text.