My development process with AI agents

Here's the development process I've come up with over six months of working with AI agents.

1. The Unix philosophy

Project management is built around a set of utilities in the Unix tradition: one command, one task.

The LLM must perform every deterministic task (building, running, interacting with external systems and the issue tracker) through a command-line utility that it creates itself.

MUST Run everything through mop [subcommand].
MUST A missing capability is a new commandlet in mop/cli/, never a workaround from outside.

All commands are subcommands of a single entry point. In Master of Puppets, for example, that's mop. The subcommands are organized into groups (namespaces). Every command must support --help, describing its purpose and parameters in enough detail to use it.

> mop --help
mop <group> <verb>, mop <group> alone for the verbs
    dev        the developer's own commands: the project's tracker, CI and checks, not the pool
    driver     node driver: in what a puppet lives
    ...

This works even better than MCP servers. Modern models are extremely good at using a CLI.

2. Test-Driven Development

Mandatory XP-style Test-Driven Development is something I've written about before. It helps prevent regressions and lets you refactor without everything falling apart. Test files also double as documentation.

Strict TDD protocol is MANDATORY for every bug fix and feature. The only exceptions are purely mechanical edits (renames, formatting, documentation text) and static marketing/landing content.

Write a failing test FIRST, in the module's tests.rs next to the code under test.

Verify it fails for the right reason (cargo test -p [crate] [name]). If it passes, the test is wrong.

Implement the minimal fix. Track reasoning in test-file comments (HYPOTHESIS:, SOLUTION:, RESULT:) and undo every wrong-hypothesis change - no dead exploratory code in the tree.

Verify green (the tests for this change) and leave STATUS: FIXED in the test.

3. The development process: an issue tracker as the agent's memory (a RAG system)

An agent's development process should be no different from a human's. Agents use GitLab, Jira, or another tracker, update issue statuses, and record everything they do there, just as people do.

That lets you keep an eye on their work and gives them persistent memory:

Work lives in GitLab issues. The coordinates come from the working copy's git origin.

MUST Use mop dev bug for every interaction with the tracker.
MUST Issue titles, bodies and comments are in Russian; code, branch names and commits stay in English.
MUST Every unit of work is an issue before the fix, in the fixed report format: steps to reproduce, expected result, actual result, evidence, the root cause (only when confirmed) and what to do.
MUST One issue = one defect: split a compound issue and cross-link the parts.
MUST Search for a duplicate before opening an issue (mop dev bug list --all -t ...): the criterion is the fix, not the wording - if one change closes both, it is one issue.

...and so on. Write down a formal description of your development process. Unlike the meatbags, agents actually follow it.

4. Automatic subsystem documentation

Documentation lives in docs/[SUBSYSTEM].md files.

MUST A new subsystem is a docs/NAME.md file, one UPPERCASE word.
SHOULD When the user types a bare UPPERCASE word (BUS, DRIVER), read docs/[WORD].md.

When I need to point the model at a particular aspect of the project, I just write it in caps. For example:

Add a COMMANDLET to access the build in GitLab, using the key from .env.

Check the feature against OOP and KISS.

5. Regular refactoring

Refactoring here is less about fighting technical debt and more about studying the project's structure and getting it into a shape you can hold in your head. Stop refactoring and you lose your grasp of the project. At that point, you're no longer an AI architect, you're a plain old vibe coder.

In practice, the ratio of development to refactoring should be about 1:1.