Скил ai-quality — пять столпов, которые удерживают AI-код от дрейфа
Как скил ai-quality в Datarim применяет декомпозицию, тест-первый подход и ревью архитектуры на каждом этапе пайплайна, сокращая число багов на 40–50%.
ИИ-ассистенты пишут код быстро. Проблема в том, что скорость без структуры накапливает долг: методы разрастаются, тесты появляются постфактум, а расплывчатое задание приводит к результату, который решает не совсем ту задачу. Скил ai-quality существует, чтобы предотвратить этот дрейф — пять последовательных ограничений применяются на каждом этапе пайплайна Datarim.
Что он делает
Скил организует AI-assisted разработку вокруг пяти столпов. Первый — декомпозиция: каждый метод не длиннее 50 строк, каждая функция выполняет одну задачу, в рабочей памяти одновременно удерживается не более семи-девяти объектов. Второй столп — тест-первый: тесты пишутся до кода, потому что тесты — главный фильтр от галлюцинированной логики. Третий — архитектура сначала: скелет со стабами проходит ревью до того, как реализован хоть один метод.
Четвёртый столп — сфокусированная работа. Каждое ревью охватывает один метод за раз, а в формулировке задачи явно прописывается, что выходит за рамки — эта граница не даёт расширяться скоупу в ходе долгой сессии. Пятый столп — управление контекстом: требования собираются до начала кодирования, а артефакты Datarim структурируются иерархически, чтобы нужный контекст оказывался доступен в нужный момент.
Помимо столпов, скил содержит конкретные паттерны для сквозных задач. Когда задача меняет формат вывода сразу в многих файлах, применяется паттерн spec-first-with-golden-fixtures: сначала пишется канонический spec, создаются эталонные фикстуры, пишутся регрессионные тесты — и только потом изменение распространяется. Если критерий приёмки утверждает конкретный HTTP-статус, скил требует проследить всю цепочку middleware до фиксации буквального статуса — любой вышестоящий слой может прервать цепочку и вернуть другой код.
Один конкретный пример
Задача — добавить валидацию к эндпоинту API. Без структуры сначала пишется хендлер, потом тесты. Под ai-quality последовательность обратная: сначала определяются критерии готовности и граничные случаи, затем пишутся тесты, покрывающие пустой body и слишком большой payload, и только потом реализуется хендлер. Метод остаётся короче 50 строк за счёт выноса логики валидации в отдельную функцию. Когда запускается /dr-qa, stage-rule mapping подсказывает ревьюверу проверить критерии готовности относительно тестов — а не перечитывать фичу целиком.
Когда загружается
Скил загружается автоматически на каждом этапе пайплайна — /dr-init, /dr-plan, /dr-design, /dr-do, /dr-qa и /dr-archive. У каждого этапа — своё подмножество правил. На /dr-do применяется TDD и лимит 50 строк. На /dr-qa проверяются критерии готовности и ревью идёт по одному методу за раз. На /dr-archive правило итеративной верификации подтверждает, что процесс был соблюдён, — а не только результат.
О более широком контексте — в посте что такое Datarim. Как эти правила применяются на практике — в статье о команде /dr-do.