Duscode
Download Open app
How it works

From a sentence to software that runs.

Reason. Decide. Build.

You say what you want. Dus carries it from a plan to checked code, a merged change, a live release and a watched system. Two moments are always yours: the calls that cost money or can’t be undone, and the first time anything goes live.

The loop, one task at a time.

  1. Reason

    Dus

    Dus reads the project and writes a plan, step by step, with an estimate of what it will cost. Each task goes to a model that can do it at the lowest cost, across the providers you have keys for, and the model is named.

    Leaves: the plan, the model, the estimate

  2. Decide

    Dus, and you for the owner’s calls

    Dus makes the technical decisions itself and says why, with the evidence. Anything that is yours (money, publishing, real people’s data, legal terms, keys) comes to you as an Owner’s Call.

    Leaves: the reasons, and your answers

  3. Build

    Dus

    Dus writes the code in your project’s own framework, with a reason on every change. Each piece of work can run in its own copy of the project on its own branch, so two jobs never edit the same files.

    Leaves: the diffs and their reasons

  4. Checked

    Your project’s own checks

    Dus runs your tests, type checks and builds, and looks at pages in a real browser. The work counts as done only when a check ran after the last change and passed. A project with no checks still works; the proof then says what wasn’t checked.

    Leaves: a Proof of Work

  5. Merged

    You decide what goes into main

    Dus commits, opens the pull request, watches the checks, fixes failures and answers review comments. It merges only when the required checks passed on that exact commit, and only if you allow merging.

    Leaves: check results for the change and the merge result

  6. Live

    First deploy: your call

    Dus deploys to a server you own over SSH, serves it over HTTPS, checks it answers and keeps the previous release, so rollback is one step. The first deploy to a target always waits for you. See Hosting and domains

    Leaves: the release, its health check and the live address

  7. Watched

    Within the limits you set

    While Duscode is running, Watch checks your live system on a schedule: the address, the certificate, the domain, the last deploy and the server. One problem opens one incident, and Dus brings you a fix to approve. Watching with your computer switched off is coming.

    Leaves: readings, incidents and a verified recovery

Some stages are still in beta. Which ones, from the evidence, is in the list below.

Build and ship: what is ready.

Each stage comes from the same record as Capabilities, so the two pages always agree.

Larger work and your issue tracker

Lead mode. For a larger job, Dus plans separate tracks, runs them with specialist helpers on their own branches, reviews each one and merges them in order.

Work from your issues. Pick an issue from GitHub, Linear or Jira and it becomes a new piece of work in its own session. Your tracker’s token never reaches the AI model.

For engineers

Each helper works in its own git worktree with a scope it may not leave. Dus reviews each track before merging, merges in dependency order, and a plan survives a restart. Merges into main rest on checks of the exact commit: the pull request’s head and the prospective merge result, on hosted CI or on Local CI where the branch’s own rules accept it. Branch protection is never changed to get a merge through. Details: Lead mode and Shipping.

Owner’s Calls

Dus asks you, every time, before it:

  • spends money: a paid service, a bigger plan, a domain, raising a budget;
  • publishes: putting your app live, publishing code or a package;
  • reaches real people: sending emails, messages or posts;
  • touches real data: your live database, your customers’ data;
  • accepts legal terms, or uses accounts and keys;
  • changes DNS, runs a database migration or a destructive command on a server.

Each question arrives as one card: what Dus wants to do and why, what happens if you say yes or no, the cost, whether it can be undone, and Dus’s recommendation as the main button. Technical steps stay with Dus, and every one is recorded and can be undone. More in the docs: When Dus needs you.

Proof of Work

Every task that changes or runs something ends with a Proof of Work: what Dus did, what checked it, and what is still open. It is built only from what actually ran: the commands and their exit codes, your checks, the diffs, the browser and the cost. What Dus says it did is never evidence. If no test ran, the proof says Not checked.

The verdict is one of Verified, Partially verified (with what isn’t covered), Failed, Blocked or Not checked. Every claim opens what it stands on. A pull request opened from Duscode starts with the proof, and you can export it as Markdown or a single HTML report.

Where checks run

Checks run where you choose. Nothing has to change in how you work today.

  • On your machine. Dus runs your project’s checks after each change. Local CI can also check each commit and open pull request on your computer, at low priority, and report the result on GitHub, GitLab or Bitbucket.
  • On your server. Local CI runs the same way on a server of yours, with a record of every run.
  • In the CI you already use. Dus watches your existing CI, reads failing logs and fixes what its change broke. If a project has no CI yet, Dus can write the config and asks before adding it.

Branch protection always applies. Dus never bypasses a required check or review, and never weakens a check to get a green result. Details: Shipping in the docs.

When something breaks

Watch opens an incident, Dus finds the cause and the fix goes round the same loop: reasoned, decided, built, checked, merged and live. Recovery counts only when the checks pass again from outside. A failed fix is never retried blindly: Dus stops and tells you what happened.