Разработка с AI — это отдельная группа навыков и подходов, которые нужно нарабатывать и совершенствовать. Иначе AI никак не поможет работе, и даже сделает хуже.
Генерация кода — задача, с которой LLM давно справляются отлично. Позволю себе заметить, что уже даже лучше людей.
PR от машины смотреть легче и понятнее. Т.к. допускают они меньше совсем нелепых ошибок, ради которых нужно всматриваться внимательно в каждую строчку.
Они могут ошибиться в связях и архитектуре. Но на этом уровне проблемы отслеживать важнее и проще, чем на уровне кода, где нужно утомительно проверять условные отписки. На этом уровне сегодня LLM дают минимум промашек. И сами себя отлично ловят на этапе ревью.
Но "магия" случается, только если:
- Перестать "трястись" за каждую строчку кода;
- Выстраивать понятную архитектуру с чёткими границами;
- Обеспечивать агентам полную автономность, достаточные легкодоступные источники истины, жёсткие ограничения и возможность получать обратную связь о совершаемых действиях.
Из относительно недавнего полезного контента:
- Попался познавательный видеоролик от Дмитрия Березницкого, где доступно рассказываются и показываются основы современной разработки с AI.
——————————————
Основная проблема LLM в том, что без строгого инженерного подхода они чаще всего генерируют мусор (и люди тоже, на самом деле).
Качество достигается за счет управления тем, что именно подается на вход LLM, насколько ей легко получить недостающую информацию и как LLM может проверить, что она действует правильно на каждом шаге.
Это, так называемые, Context Engineering и Feedback Loop.
(и архитектура тоже вносит сильный вклад)
В видео задеты оба аспекта, но больше внимания уделено именно работе с контекстом, как самой базе. Но и без Feedback Loop достичь дзена не получится — а это, возможно, самая трудоёмкая часть.
——————————————
В видео весь процесс разработки разбивается на 4 этапа. И каждый этап проверяется, корректируется и заверяется человеком перед тем, как перейти к следующему.
Этапы:
- Research: AI-агенты сканируют кодовую базу и создают сжатый документ с описанием текущей системы (если такого ещё нет).
- Design: На основе исследования генерируются архитектурные диаграммы (C4, DFD и прочее изобилие mermaid), принятые решения (в т.ч. это могут быть и ADR, про которые уже писал ранее) и планы тестирования.
- Plan: Утвержденный дизайн разбивается на детальный пошаговый план, состоящий из изолированных завершаемых мелких фаз.
- Implementation: Агент выполняет фазы последовательно или параллельно, распределяя их между субагентами: кодер, ревьюер, тестировщик, тех. писатель, безопасник и т.д. в зависимости от проекта, настроек и пожеланий самого агента.
Каждая фаза проходит автоматические проверки: сборка (с Unity тут пролёт), логи, тесты, анализаторы, линтеры и т.д. Пока весь Feedback в текущем Loop полностью не исчерпан, дальше работа не сдвигается.
Это может звучать очевидно и просто, но построить и отладить такую систему — отдельная инженерная задача. Или, под другим углом, современная инженерная задача.
——————————————
Мой процесс устроен схожим образом и представлен на схеме.
Единственное, внутри я стараюсь всё максимально упростить, т.к. мне нужно это интегрировать в разные команды с разным уровнем скептицизма и ai-native'ности. Т.е. предоставить инструмент, которым проще и полезнее воспользоваться, чем отказаться.
Любые универсальные и абстрактные решения в контексте AI — заведомо менее эффективные, чем более конкретные и сфокусированные. Особенно, когда часть команды инертна и до сих пор очень щепетильно относится ко всему багажу накопленных соглашений, низкоуровневых паттернов и подходов.
Поэтому для меня важно предоставлять необходимый минимум, который дальше комфортно и понятно, как уточнить под конкретный проект и использовать.
Можно обратиться к spec-kit, open-spec и прочим готовым фреймворкам общего назначения, но это что-то сродни использованию ассетов с AssetStore: для петов сгодится и в целом лучше, чем ничего. Но для продакшена: расфокус, оверхэд и избыточная сложность, граничащая с желанием подпилить или переписать.
Что в отдельных слоях команды может выливаться в "тупое ИИ делает не так, как я хочу, только зря память дорожает".
——————————————
Подобный подход при работе с AI не только ускоряет получение решений и повышает их качество, но и усиливает общую инженерную культуру в команде, добавляя намного больше осознанности.
Вы начинаете:
- заниматься проработкой тех документации;
- фикисровать все принимаемые решения;
- изучать возможные факапы до начала разработки;
- обсуждать реально важные вещи, а не названия переменных и нюансы переноса строк;
- создавать параллельно разные вариации и выбирать лучшую;
- генерировать кучу тестов и линтеров, которые стабилизируют проект;
- создавать множество вспомогательных инструментов.
Заниматься целый день общением со стейкхолдерами и составлением спецификаций для задачи, не написав ни одной строчки кода, а потом отдать это агенту на несколько часов, переходя дальше к следующей задаче — это уже сегодняшняя реальность, которая может понравиться не всем.
При этом я всё ещё склонен считать, что для этого не нужны Frontier-модели (разве что на этапы подготовки). Даже не очень умный, но очень дешёвый, быстрый и мною любимый, MiniMax может автономно колбасить по 3 часа, выдавая рабочий результат. И это реальные цифры.
Можно заряжать на выполнение Codex или Claude. Но по точно такой же проработанной спецификации и с теми же выстроенными ограничениями (❗️) у них не будет шансов сделать по-другому.
Будут отличия в деталях, которые уже не играют роли. И чем дальше, тем масштаб таких деталей, на которые нет смысла обращать внимание, будет только увеличиваться.
