Мой процесс разработки с ИИ-агентами

Опишу свой процесс разработки с ИИ-агентами, который я родил за полгода.

1. Философия Unix

Управление проектом строится как набор утилит в духе философии Unix: одна команда - одна задача.

Все детерминированные задачи (сборка, запуск, работа с внешними системами и трекером задач) LLM обязана выполнять через утилиту командной строки, которую сама же и создает.

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

Все команды - подкоманды единой точки входа. Например, у проекта Master of Puppets это mop. Подкоманды разбиты на группы (namespaces). Каждая команда должна поддерживать опцию --help, которая описывает ее назначение и параметры достаточно подробно для вызова.

> 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
    ...

Такой подход работает даже лучше MCP-серверов - современные модели умеют чрезвычайно эффективно работать с CLI.

2. Test-Driven Development

Обязательный Test-Driven Development в стиле XP - то, про что я уже писал. Он позволяет избежать регрессий и проводить рефакторинг так, чтобы все не развалилось. Файлы тестов также выполняют роль документации.

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. Процесс разработки: трекер задач как память агента (RAG-система)

Процесс разработки у агента не должен отличаться от процесса разработки у человека. Точно так же агенты используют GitLab, Jira или другой трекер, меняют статусы задач и записывают туда все свои действия.

Это не только позволяет контролировать их работу, но и дает им постоянную память:

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.

...и так далее. Опишите формально свой процесс разработки. В отличие от кожаных, агенты четко его соблюдают.

4. Автоматическое документирование подсистем

Документация ведется в файлах docs/[ПОДСИСТЕМА].md.

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.

Если мне нужно указать модели на конкретный аспект проекта, я просто пишу это капсом. Например:

Добавь COMMANDLET для доступа к сборке в GitLab, используя ключ из .env.

Проверь фичу на соответствие OOP и KISS.

5. Регулярный рефакторинг

Рефакторинг здесь - не столько борьба с техдолгом, сколько изучение структуры проекта и приведение ее к виду, который умещается в голове. Забил на рефакторинг - потерял понимание проекта. И все, ты больше не ИИ-архитектор, а голимый вайбкодер.

Как показывает практика, соотношение разработки и рефакторинга должно быть примерно 1:1.