С конца 2025 года я активно использую ИИ в разработке. Осваиваю новый подход к работе, пробую разные инструменты и сейчас хочу сформулировать мысли о своем опыте.
Нейронки не для всех задач
Первая моя оценка — есть ряд задач, которые быстрее и проще выполнить вручную. Я представляю это как прямую, разделенную на три неравные части:
- Легкие задачи, условно: исправить три строчки кода. Для таких задач невыгодно использовать ИИ: нужно долго и подробно описывать требования, потом тщательно проверять результат, плюс учитывать время ответа нейронки.
- Большая часть задач. Это рутина, фиксы багов, разработка новых требований. Тут нейронку применять разумно.
- Большие задачи с кучей описания. У нейронок ограничен контекст, они не могут удержать в «голове» всю информацию для разработки больших задач. Это делает нейронки неприменимыми в лоб. Решение — дробить большую задачу на мелкие, которые нейронка уже может «переварить».
Нейронки генерируют случайный код
Мое примитивное понимание устройства нейронок основано на том, что нейросеть обучена на примерах кода. Каждый раз, когда нужно сгенерировать новый кусок, она просто ищет что-то похожее в своем «опыте». При этом нейронка не дает повторяемый результат. Это превращает ее в черный ящик, который по вашему запросу сгенерирует какой-то код. Если повезет, он будет работать.
Поэтому мы должны встраивать в работу с нейронками механизмы контроля качества кода. И эти механизмы должны быть максимально жесткими: максимально подробные линтеры, детальные гайдлайны, как можно больше тестов.
Документация для копипасты
Когда-то давно я смотрел доклад про работу с документацией в больших командах. Там была мысль, что документация должна включать в себя примеры для копипасты. Идея простая: разработчики будут искать пример решения задачи в коде и копировать его.
Например, у вас есть UI-компонент, и разработчик хочет использовать его на новой странице. Он найдет пример использования компонента и скопирует его. Но код живет, какие-то решения устаревают, какие-то признаются плохими практиками. Поэтому нужно иметь документацию с правильными примерами, чтобы разработчик мог просто скопировать и не тащить устаревший подход.
Нейронка ничем не отличается. Ей нужны примеры решения задач с подробными пояснениями, чтобы она могла их «копировать». И у меня есть подозрение, что наличие таких примеров позволяет использовать более простые и дешевые модели. Хочется попробовать запихнуть эти примеры в скиллы, чтобы нейронка «научилась» работать на их основе. Только снова появляется проблема с контекстом и его размером.
Нейронкам не лень
В разработке есть отличные концепции вроде TDD. Мы часто говорим про актуализацию документации. Эти концепции действительно полезные, они упрощают нам жизнь. Но есть проблема — программистам лень. Лень поддерживать документацию в актуальном состоянии, поэтому мы пытаемся придумать, как работать без нее. Даже комментарии к коду считаются плохой практикой из-за их устаревания. Нам лень писать тесты перед реализацией и тем самым продумывать контракты и сценарии использования заранее.
А нейронке не лень. Нейронка не будет ныть — она обновит документацию. Она напишет тесты на функционал до его реализации. Это позволяет выстраивать идеальный пайплайн разработки, который в обычной жизни, скорее всего, развалился бы. Но нейронки будут его соблюдать и поддерживать.
Артефакты
Я использую GitHub Speckit для разработки фич с нейронкой. Этот инструмент придерживается концепции spec driven development. То есть вы даете нейронке проблему, а она «раскручивает» это требование и получает use cases, requirements и план реализации. По пути она еще проводит исследования: как решить проблему, какие библиотеки использовать, какие аспекты остаются неизвестными. Все эти артефакты сохраняются в репозитории.
С одной стороны, мне нравится идея хранить артефакты аналитики — спецификации, архитектурные решения, ограничения — в репозитории. С другой стороны, мне не нравится, что они сгруппированы по требованиям. Получается, что мы ограничиваем действие спецификации рамками одной задачи, хотя на самом деле это не так. Многие артефакты продолжают жить и за пределами конкретного требования.
Хочется попробовать альтернативы Speckit — возможно, у них организация артефактов будет другой.
SWARM mode?
Стандартный процесс SDD с нейронками примерно такой: придумал проблему → отдал на аналитику → отдал на теханалитику → сгенерировал план реализации → разбил его на таски → отдал таски на реализацию → протестировал → готово. На каждом шаге нужно запустить агента, сформулировать ему команду, подождать, пока он что-то сделает, потом поревьювить, написать, что исправить, и снова ждать агента. Этап реализации еще скучнее: запустил агента на реализацию, подождал, поревьювил. Агент может сам организовать себе ревью и запуск линтеров, поэтому человек уже работает с более-менее нормальным кодом.
Чего мне тут не хватает:
- Я в один момент времени работаю только с одной проблемой. Даже если у меня в голове есть еще куча идей, они не оформлены. Это можно решить через воркспейсы и инициацию спецификаций под каждую идею: не продолжать сразу работать над идеей, а хотя бы зафиксировать ее.
- Я жду, пока нейронка закончит. Да, во время ожидания можно заняться чем-то еще, но хочется максимальной производительности.
- Нет проактивности со стороны агентов. Пока один агент занимается реализацией, другой мог бы заниматься аналитикой. В итоге все эти процессы я должен запускать сам вручную.
- Нет обратного цикла. Проблема превращается в артефакты. Но что, если изменилось существующее поведение? Формально нужно описать это изменение как новую проблему, которая сгенерирует новые use cases. Но хочется наоборот: я меняю существующий use case, и это создает новую проблему. Тогда в истории коммитов будут более логичные и понятные изменения.
Типы агентов
Продолжая идею обучения на примерах и скиллах, я пришел к тому, что нужно делать разные наборы агентов под максимально узкий круг задач. Не один агент «для любого кодинга», а отдельный агент для фронтенда с соответствующим набором скиллов. Отдельный агент для бэкенда. Отдельный — для ревью на соответствие спецификации. Отдельный — для ревью фронтенда. Отдельный — для ревью бэкенда.
Кажется, это поможет решить проблему с контекстом и обучением нейронки специфичным навыкам.
Вопросы вместо итогов
- Как обходить ограниченный контекст нейросетей, когда нужно решать большие, комплексные задачи?
- Как обеспечить ИИ хорошими и актуальными примерами (документацией для копипасты) при ограниченном размере контекста?
- Как организовать артефакты аналитики (спецификации, архитектурные решения, ограничения) так, чтобы они не были жестко привязаны только к отдельным требованиям?
- Как сделать так, чтобы агенты вели себя проактивно и подхватывали связанные задачи (аналитика, реализация) без ручного запуска каждого шага?
- Как выстроить обратный цикл, в котором изменения существующих use cases автоматически рождают новые проблемы и артефакты?
- Как спроектировать набор специализированных агентов так, чтобы компенсировать ограниченный контекст и узкие навыки, не скатываясь в одного неповоротливого «универсального» агента?
- Как сделать разработку SDD менее линейной?