TL;DR: ИИ не заменяет инженерный контроль, но меняет базовую планку разработки. С ним проще удерживать скоуп, тесты, техническое качество и в режиме дедлайна. Главный риск – потерять ownership, поэтому уровень автономности должен зависеть от проекта, стадии и зрелости инженерного процесса.
У меня есть один личный проект, где я полностью автоматизировал разработку и перестал читать код. Всё идёт практически без моего участия: я просто описываю в телеграмме своему боту что нужно сделать, что я хочу получить, а он выполняет, проверяет в цикле, коммитит, деплоит и сам проверяет логи. Единственное, заниматься своим проектом времени мало, потому движение всё равно медленное и хоть бот может сам брать тикеты из гитхаба и выполнять их, я всё же не разрешаю ему пушить код – хочу всё же в конце понимать что он сделал. Но проект я изначально писал сам, и только потом начал изучать как сделать работу автономной.
Всё работает настолько хорошо, что я даже задумался: а не запустить ли новый проект вообще без моего участия? Описать только PRD, проверить сгенерированную документацию и список задач, а на выходе просто принимать готовые фичи. Я даже пробовал запускать так несколько личных проектов (один из них – простенькая игра): формировал всю документацию через ИИ, но на определенных этапах допускал ошибки в планировании и в итоге терял контроль.
Многим это не понравится, но на определённых проектах это работает. ИИ действительно хорошо справляется даже со спрайтами: как заглушки на старте они вполне подходят, а потом их можно перерисовать. Конечно, подготовительная работа требует времени, но на этапе реализации это окупается.
Создание MVP стало реально быстрым. Но любой современный AI-девелопер знает: иногда ИИ заходит в тупик, и без вмешательства продвинуться не выйдет. Часто приходится вообще всё удалять и начинать фичу с нуля, или тратить неделю, чтобы понять, где именно ИИ ошибся в архитектуре проекта.
Что ощущается, когда возвращаешься к коду руками
В своей прошлой статье я сравнивал вайбкодинг с гемблингом и тем самым азартным чувством ожидания. А что я чувствую, когда мне нужно писать код руками? Я чувствую себя лудитом, который внезапно отказался от технологий, интернета и поисковиков. Это похоже на возвращение в начало карьеры: я сижу в банке без внешнего интернета, гуглю ошибки на телефоне и читаю Stack Overflow. Ведь с появлением ИИ потребность исправлять глупые ошибки вроде опечаток в конфигах полностью отпала. Если забыл название класса в какой-то библиотеке, ты больше не идешь в документацию или Google. Без ИИ снова приходится вчитываться в логи самому…
Так вот, выделим основные проблемы НЕ использования ИИ:
Первая проблема – сокращение скоупа задач
Без ИИ приходится резать функционал до минимально полезного для бизнеса. Если с ИИ можно сразу развернуть «взрослый» проект, используя best practices, то руками в жесткие дедлайны для MVP попадаешь, только урезая нефункциональные требования.
Вторая серьёзная проблема – деградация test coverage
Разработчики и без того неохотно пишут тесты, а в условиях дедлайнов на них первым делом не хватает времени. В итоге код становится «дырявым», если только в компании изначально не TDD.
Третья проблема – грязный код и технический долг (Technical Debt)
С ИИ я могу позволить себе быть перфекционистом: на старте выстроить архитектуру, задать строгий кодстайл, разные триггеры, прописать линтинг, arch unit тесты и покрытие обычными unit тестами, превратив это в стандарт, который моя «команда ИИ» будет соблюдать автоматически. Но когда приходится писать руками в жесткие сроки, на это точно нет времени – бизнесу не интересна техническая сторона и maintenance, для бизнеса важна «доставка ценности» любой ценой.
Для личного проекта это может и не критично, но для бизнеса это системная проблема. В команде с живыми людьми я считаю, что чистый код важен, я верю в теорию разбитых окон. В коде она проявляется так: разработчики начинают «класть болт» на читаемость, потому что никому нету дела до этого кода. А мне, как человеку, который большую часть времени читает код, хотелось бы мучить себя поменьше. Конечно, с ИИ есть риск нагенерировать «нейрослопа», что превращает ревью в отдельный вид боли, но без ИИ поддерживать высокую планку в спешке почти невозможно.
У меня есть показательный пример: проект, написанный с упором на Job Security и доставку фич любыми средствами. Каждый новый разработчик, приходя в этот проект, тратил недели две только на локальный сетап. Потом, в лучшем случае, ещё два дня уходило на ресерч бага, после чего единственным безопасным решением казался очередной if – ведь unit-тестов не было, а чтобы проверить результат, нужно было дождаться прогона nightly-тестов, которые шли по 5-7 часов. Был только один вариант: отправить фикс на QA и надеяться, что они выловят регрессию на тестовой среде.
Бизнесу это было не важно: менеджеры менялись, демонстрируя быстрый результат, но в итоге доставка фичи в прод стала занимать полгода, так как деплоя все боялись как огня. Когда я попал на проект, его переписывали уже лет 5, и впереди было еще 2 года работы – и это только благодаря тому, что менеджмент параллельно внедрял LeSS.
Четвёртая проблема – рутина
Мне приходится писать маппинги и подготавливать JSON-данные руками. Это первое, что я делегировал ИИ еще на ранних моделях вроде GPT-3.5, чтобы избавиться от скучной работы. В целом я наловчился делать это быстро в IDEA, но всё равно неприятно.
Но есть и плюсы
Первый плюс – при использовании ИИ велика вероятность потери ownership над решением, а без ИИ работа становится более методичной, в каком-то смысле приятной. Я не веду сразу 3-4 проекта, я просто пишу код. Мне сразу вспомнилось ощущение из школы, когда ты впервые пишешь простую задачу на Паскале. Наверное, так же себя чувствовали люди, переходившие с ассемблера или Си на языки высокого уровня: они говорили, что не контролируют процесс и что новые языки неэффективны. Я сталкивался с таким скепсисом еще в универе, когда старшие коллеги ворчали, что мы слишком полагаемся на эти модные языки высокого уровня, то ли дело они писали программы на всего 640 КБ памяти. Кажется, сейчас с ИИ происходит ровно то же самое.
Второй плюс – меньше «нейрослопа» в кодовой базе, особенно если у вас нет нормальной практики код-ревью. Самый рабочий вариант на данный момент, как уменьшить отчуждение разработчиков от кода при использовании ИИ, – это кросс-ревью, где автор устно рассказывает, что и зачем изменено, своими словами.
Третье – если честно, даже с ИИ все остальные варианты – это производные от первых двух.
Итог
Итог: не использовать ИИ сегодня просто неэффективно. Нужно лишь правильно выбирать режим работы в зависимости от типа проекта и его стадии.
Для личных проектов и MVP отлично подходит обычный вайбкодинг. Для большинства рабочих задач ИИ – это такой же инструмент, как IDEA: код пишешь и ревьювишь ты, но с постоянной помощью модели. Во многих случаях сильные модели справятся не хуже среднего разработчика, но в коммерческой разработке критически важны harness-тесты и выстроенный SDLC. Мне удалось достичь Agentic Engineering (как мне кажется), но это всё еще хрупкий подход. Когда я читаю посты о почти автономных агентных системах, я вижу в этом маркетинг и эксперименты, а не рабочее решение. Так что пока ИИ пузырь не лопнул, ИИ это отличный инструмент за такую цену подписки.
Автор: NickAlister
