Pepper-orchestrator built three packages in 1 hour 52 minutes with no manual coding

A single AI agent can build a decent prototype as long as the whole project fits in a human's head. After that comes a familiar pain: an API change affects a neighboring repository, two executors edit a shared file, and the tests confirm exactly the assumptions the code was written with. Maxim Nikitin of the ITSalt studio proposes solving this not by enlarging the prompt, but by dividing responsibility.

His pepper-orchestrator plugin for Claude Code and Codex turns a large goal into a program of small work packages. Each package gets its own context, branch or working copy, permitted paths, dependencies, and verifiable acceptance criteria. The orchestrator itself does not write module code: it holds the overall picture, determines the launch order, and passes the result to an independent reviewer.

What it looks like in a simple case

The demonstration required building an application for a procurement specialist. The user uploads text contracts and gets a table with the number, supplier, amount, and delivery deadline. The documents deliberately contained traps: an advance payment sat next to the price, the limit "no more than 600,000 rubles" looked like the total amount, and the payment term could be mistaken for the delivery term.

The orchestrator split the work into three packages: a document-parsing engine, an interface using a design system, and an explanatory note. The independent parts went to separate copies of the repository. Shared files had to be changed sequentially, so overlaps became visible before work began rather than during merging.

After 1 hour 52 minutes, all three packages were formally closed. The author did not write code by hand, but made product decisions and resolved disputed actions. This is an important clarification: this is not an autonomous software factory, but a system in which the human remains the owner of the program and controls permissions, merging, and publication.

Why green tests were not enough

The first version of the engine passed its own tests, but an independent reviewer restated the contract terms in different words and found three confident errors. The advance was taken as the full amount, the limit as the contract price, and the payment term as the delivery term. The package was sent back for rework, after which doubtful values began to be flagged as needing review.

The product was then checked by three separate "customers": a loyal user, a deliberately careless user, and a competitor looking for edge cases. The last one found two more errors in the interpretation of the amount and of a valid supplementary agreement. A clean deployment revealed timeouts that did not appear on the developer's machine, and six unclear passages in the instructions.

The main engineering idea here is simple: an agent's "done" message is a claim, not proof. The executor and the reviewer should not share the same context, otherwise the second inherits the first's assumptions. It is worth checking not only the code but also the product's behavior: on paraphrased data, on a clean machine, and in scenarios with users of different intentions.

Where the approach is genuinely useful

Orchestration is justified when a task touches several modules or repositories, the work can be divided by files, and the result is described by observable criteria. For a small fix, such a setup only adds logging, repository copies, and the cost of extra agent sessions.

There is also a limit to the evidence: the figures were obtained by the plugin's author on his own case, without comparison to ordinary development and without an independent quality measurement. Therefore 1 hour 52 minutes cannot be considered a universal speedup metric.

The practical takeaway for a team: first fix one goal, the package boundaries, and the dependencies; then separate execution from verification; leave irreversible actions to a human. An orchestrator is useful not for the number of agents, but because it makes state, responsibility, and acceptance criteria explicit.