You have just installed HaikoDev and you are looking at an empty board. Here is the whole journey of a request, from the sentence you type to the moment the result goes live — with nothing skipped, and without a line of code to write.

1. Declare the project

In the left-hand column, add a project: its name, the folder where it lives on the machine, and its working repository. It really is the working repository you declare, never the folder that is already published: agents must be able to create branches without disturbing anything that is online.

If the project does not exist yet, HaikoDev can set it up entirely: folder, repository and starter files. It will first ask you for its public address — that address is the one checked at the end of every release.

2. Explain, in plain language

Open the project conversation and write what you want, as you would to a colleague: “the sign-in page is unreadable on a phone”, or “we should be able to export the customer list as a PDF”. No syntax, no keywords.

The orchestrator is the one who answers. It reads back through the conversation, goes and reads what it needs in the project, and proposes a short card. If it hesitates between two readings, it offers both routes rather than picking one behind your back.

3. Approve the card — and only then

The proposed card appears with its title, its description and the thinking level planned for its agent. Until you start it, nothing goes to the engine: a card asleep in “Planned” consumes nothing at all. Your gesture of starting it, and only that, authorises the spending.

You can also give it a start date, so that it runs by itself at night or over the weekend, when quotas are at their widest.

4. Watch the agent work

The card moves to “Running” and the agent begins. It gets a copy of the project and a branch all of its own: two cards started at the same time never tread on each other.

In front of you, it:

  • announces its task list, then ticks it off line by line;
  • reads the files that are genuinely concerned, never guessed from memory;
  • edits, runs the project's tests, and repairs whatever breaks;
  • commits its work and pushes it to its branch.

If it lacks a piece of information, it asks the question and stops: the card waits for your answer, it does not carry on at random. A triangle on the project and a bell in the top bar let you know.

5. Read the report

When the agent has delivered, the card moves to “Done” on its own. Its report is written in plain language, in a fixed order: what it understood and found, what it did, the consequences, the day-to-day impact, the possible next steps and the cost.

The outcome of the checks is in there too, even when they fail. A broken test is never hushed up: that is the rule, and it is what makes the report readable without going to check for yourself.

6. Publish — your gesture

You read it over, and if it suits you, you drag the card into “To deploy”. It joins the batch of ready changes, waiting together. No agent can walk through that door: publishing is a human gesture, always.

When you click “Publish”, the batch is merged, committed, pushed, then released following the project's written procedure. Every step carries its own log, readable in a drawer: you see what is happening, and where it got stuck if it did.

Not sure who is allowed to move what? It is all in Understanding the five columns of the board.