Глава 25. Сколько полировать

Самый частый практический вопрос после первого месяца работы. Агент выдал результат. Прогнал ревью, он нашёл замечания. Исправил. Прогнал снова, нашёл ещё. Исправил. И так до посинения.

Когда останавливаться?

Прямой ответ практика Один из самых опытных участников разговора ответил коротко: спецификацию полирую долго, а код не читаю вообще, он проверяется в бою.

Развёрнутый вариант выглядит так. Требования оформляются как поведенческие описания, код пишется от тестов. Дольше и дороже по расходу, зато не будет отчёта о готовности там, где половина кода даже не проверена.

С оговоркой, которую он же и произнёс: это по-прежнему лучший конвейер, но только если ревьюер слепой. То есть если проверяющий не видит, как код создавался, и судит по результату.

ГЛАВНОЕ ПРО КОНВЕЙЕР Строгий конвейер покупает тебе ровно одну вещь: ты не получишь доклад о готовности там, где ни хуя не проверено. Сам по себе код он лучше не делает. Он делает невозможным незаметный самообман. За это и платят временем и токенами.

Возражения, которые надо знать Универсальных схем не бывает, и в разговоре тут же прозвучали три возражения.

Экономическое. При текущем расходе лимитов хочется схему полегче: интеграционные проверки только на основные функции, остальное чинить по мере появления проблем.

Архитектурное. Когда полный набор функций ещё не ясен и архитектура не устоялась, прибивать её тестами не хочется. Каждое изменение решения означает переписывание тестов.

Историческое, самое едкое. Именно так баги и заезжали в продакшн до всякого ИИ. А потом это стало нормой, и всем стало похуй.

Сколько полировать

ТРИ ПОЗИЦИИ О ДОСТАТОЧНОСТИ Строгая. Требования, исполняемые спецификации, код от тестов. Для системы с живыми пользователями и дорогой ошибкой. Умеренная. Интеграционные проверки на главные сценарии, детали по мере появления проблем. Для развивающегося продукта, где архитектура ещё едет. Быстрая. Воспроизвели, починили, проверили локально, поехали. Для прототипов и внутренних инструментов, где цена ошибки около нуля. Что определяет выбор. Не вкус, а две величины: цена ошибки и зрелость архитектуры.

Одного прогона не хватает никогда Наблюдение, общее для всех трёх позиций.

Сколько ни готовься, после большого прогона нужна перепроверка в чистой сессии. Недоработки она находит всегда, бля буду.

Практики описывают это так: слой за слоем, за две-три сессии доводится до полного выполнения. Ни одна модель не вывозит это идеально с первого раза, и надо сделать много итераций, чтобы понять, какого объёма задачи вообще имеет смысл давать.

Это не пессимизм, а рабочая настройка ожиданий. Ты не ждёшь чуда, ты закладываешь пару часов на доводку.

Где полировка начинает вредить А теперь про обратную сторону, о которой говорят реже.

Честное признание практика, прошедшего этот путь: раньше после каждой задачи полировал пятнадцатью итерациями ревью и фиксов, и это раздувало проект вместо того, чтобы чинить то, что реально надо было починить.

Механика понятная. Ревьюер обязан что-то найти, иначе зачем он тут. Очевидные проблемы кончились, и он начинает доёбываться до неочевидного: добавить проверку, обработать краевой случай, вынести в отдельную функцию. Каждое замечание по отдельности разумно. Вместе они превращают простой код в хитровыебанный.

ЧТО ПРОИСХОДИТ С ПРОЕКТОМ ПРИ ИЗБЫТОЧНОЙ ПОЛИРОВКЕ

Простое решение Замечания ревью Защитные проверки Сложное решение

работает все разумные ветвления растут сопровождать дороже

Причина, названная автором, не в скиллах и не в инструментах: слишком маленькая пропорция между вникнуть и делегировать. Не вникаешь, значит не отличишь нужное замечание от формального и примешь все подряд.

Сколько полировать

Признаки, что пора остановиться

ПЯТЬ ПРИЗНАКОВ, ЧТО ПОЛИРОВКА КОНЧИЛАСЬ 1. Новые замечания касаются стиля, а не поведения. 2. Замечания повторяют друг друга другими словами. 3. Исправление одного замечания рождает новое в соседнем месте. 4. Ты не можешь сформулировать, что сломается, если оставить как есть. 5. Объём кода растёт, а число закрытых требований стоит на месте.

Пятый признак самый надёжный и легко меряется. Между итерациями прибавляется код и не прибавляется закрытых требований, значит ты полируешь, а не улучшаешь.

Обязательный шаг схлопывания Приём, который решает проблему раздувания и который почти всегда проёбывают.

После нескольких итераций полировки делается отдельный проход с обратной задачей: убрать то, что наросло. Дублирование, защитные проверки, ставшие ненужными, обходные пути, потерявшие смысл.

Формулировка запроса тут решает всё: не улучши, а сожми без потери поведения. Иначе агент опять начнёт нахуевертить сверху.

Есть более радикальная версия того же приёма, которая заодно улучшает качество: попросить сжать результат в несколько раз, сохранив функциональность. Практики отмечают, что при таком запросе код выходит заметно продуманнее, потому что модели приходится думать, а не наращивать.

Переусложнение как отдельный диагноз Смежное наблюдение, которое стоит держать рядом.

Больше написать не значит больше решить. Модель по умолчанию тянет к развесистым решениям: слои, абстракции, конфигурируемость на случай будущих требований, которых не будет никогда, бля буду.

Полезный сигнал, замеченный практиками: если самые сильные модели два раза подряд находят в твоём решении настоящие проблемы, скорее всего задача переусложнена. И, возможно, для неё уже есть готовое проверенное решение, которое дешевле поискать.

ГЛАВНОЕ ПРО ОСТАНОВКУ Правило, которым можно пользоваться: полируй, пока замечания меняют поведение. Как только они начали менять форму, останавливайся и делай проход схлопывания. И держи в голове, что универсального ответа на этот вопрос у практиков нет. Одно из мест, где опыт правилом не заменяется.

Сколько полировать

Что запомнить Спецификацию полируй долго. Код проверяй, а не читай, если есть чем проверить.

Строгий конвейер покупает не качество, а невозможность незаметного самообмана.

Выбор схемы определяется ценой ошибки и зрелостью архитектуры, а не вкусом.

Одного прогона не хватает никогда. Закладывай перепроверку в чистой сессии.

Полировка начинает вредить, когда замечания меняют форму, а не поведение.

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

И если сильные модели дважды находят настоящие проблемы, проверь, не переусложнена ли задача.

Модуль 7. Автономность Четыре главы про работу без человека рядом.

Как готовить ночной прогон, с хуя ли агент уезжает с рельсов, что на самом деле делает автономный режим и чем постоянно работающий агент отличается от рабочего инструмента.

Модуль про то место, где обещания расходятся с практикой сильнее всего.

← Детерминированные проверки вместо уговоров · оглавление · Ночной прогон →

Спросить книгу может любой, кто вошёл в Neuraldeep Hub: агент ищет ответ по тексту и приводит цитату со ссылкой на главу.