Ручное программирование после появления ассистентов уже воспринимается не как базовый режим, а как шаг назад, считает автор колонки на Habr. Для русскоязычной IT-аудитории это важный сигнал: ИИ в разработке перестал быть игрушкой для демо и все заметнее влияет на сроки MVP, качество тестов и саму роль инженера в команде.
Поводом стала колонка на тему того, как меняется ощущение от работы без AI-инструментов: автор описывает личный проект, где разработка почти полностью автоматизирована через бота в Telegram. По данным Habr / Карьера, бот умеет принимать задачи, выполнять их в цикле, коммитить, деплоить и проверять логи. При этом финальный push автор все же не доверяет машине: хочется понимать, что именно уехало в кодовую базу. Этот нюанс здесь ключевой. Речь не о фантазии про «разработчика без разработчика», а о попытке нащупать рабочую границу между автоматизацией и инженерной ответственностью.
Самое интересное в этой истории не технический трюк с телеграм-ботом, а изменение базовой планки. Автор прямо говорит: без ИИ приходится резать функциональность, экономить на нефункциональных требованиях и мириться с более грязной реализацией. С AI-помощником, по его опыту, проще сразу поднимать «взрослый» каркас проекта: линтинг, code style, архитектурные ограничения, unit-тесты, базовые проверки. Иными словами, ИИ в разработке работает не только как ускоритель набора кода, но и как дешевый способ удержать техническую дисциплину там, где дедлайн обычно побеждает здравый смысл.
Это наблюдение болезненно точное для многих российских команд, особенно тех, кто живет между MVP и бесконечным «надо было вчера». Когда у команды нет сильного процесса, тесты становятся первой жертвой сроков, а кодовая база быстро превращается в склад компромиссов. В колонке есть характерный пример проекта, где новый разработчик тратил около двух недель только на локальный setup, затем еще пару дней уходило на исследование бага, а безопасным решением казался очередной if, потому что unit-тестов не было. Проверка изменений зависела от nightly-прогонов длительностью 5-7 часов, после чего фикс отправляли на QA почти на удачу. Для любого CTO или тимлида это не абстрактная «плохая инженерия», а прямой счет в сроках релиза, цене изменений и выгорании команды.
Где ИИ помогает, а где начинает мешать
Автор не рисует AI-инструменты как серебряную пулю, и это делает текст полезнее большинства восторженных тредов про агентные системы. Он признает: модель нередко заводит проект в тупик. Иногда фичу проще снести и начать заново, чем неделю разбираться, где именно генерация сломала архитектуру. Этот риск особенно заметен, если запускать проект почти с нуля, когда у человека еще нет собственной карты системы в голове. В личных экспериментах с новыми проектами, включая простую игру, автор пробовал строить документацию и задачи через ИИ, но на отдельных этапах ошибался в планировании и терял контроль. Это важная оговорка для всех, кто уже готов объявить рождение полностью автономной разработки.
По сути, спор здесь идет не о том, пишет ли модель код достаточно быстро. Спор о другом: кто владеет решением. Пока инженер понимает устройство проекта, может задать рамки, проверить результат и остановить неудачный ход, AI остается очень мощным инструментом. Но если ownership растворяется, скорость быстро превращается в шум. Отсюда и главный практический вывод: уровень автономности должен зависеть от типа проекта, его стадии и зрелости инженерного процесса. Для личного MVP можно позволить себе больше «вайбкодинга». Для коммерческой системы с деньгами, клиентами и SLA нужен совсем другой режим, где ИИ помогает, но не заменяет контроль, тестовый контур и нормальный SDLC.
Отдельно автор подмечает вещь, которую разработчики обычно обсуждают в курилках, а не в публичных текстах: после ИИ ручная работа снова начинает раздражать своей мелочностью. Маппинги, JSON-заглушки, поиск нужного имени класса, правка конфигов, копание в логах из-за банальной опечатки. Все это стало тем самым фоном, который уже не хочется делать руками, если рядом есть инструмент, способный снять рутину за минуты. В этом смысле ИИ в разработке действует как новый слой абстракции. Когда-то похожий спор был вокруг языков высокого уровня: старшее поколение считало, что контроль теряется, младшее просто брало более удобный инструмент и двигалось дальше. Сейчас почти тот же сюжет разыгрывается вокруг генеративных моделей.
Что это значит для команд и рынка
Для бизнеса вывод не самый уютный, но довольно прямой. Если не использовать AI-инструменты совсем, команда с высокой вероятностью будет либо медленнее конкурентов, либо будет выпускать более сырой продукт в тех же сроках. При этом без нормального ревью и тестов внедрение ИИ может дать противоположный эффект: код станет расти быстрее, чем способность команды его понимать. Автор предлагает довольно земной способ снизить риск «нейрослопа»: кросс-ревью, в котором инженер своими словами объясняет, что именно изменено и зачем. Это не модный ритуал, а проверка того самого ownership. Если разработчик не может устно собрать причинно-следственную цепочку по собственному diff, значит, команда уже отдала слишком много власти генератору.
Любопытно и то, как меняется норма профессии. В опросе под публикацией приняли участие 69 пользователей. 22 человека ответили, что вообще перестали писать код руками, 20 сказали, что по-прежнему пишут вручную, 17 используют AI-режим ask вместо Google, еще 9 в основном пишут сами. Выборка маленькая и не претендует на исследование рынка, но она хорошо передает расклад в профессиональной среде: отказ от ИИ уже выглядит не принципиальной позицией, а осознанным снижением производительности. Вопрос теперь не в том, нужен ли AI разработчику, а в том, где именно провести границу между автоматизацией и ответственностью за результат.
Следующий этап для индустрии, похоже, будет связан не с еще более громкими обещаниями «автономных агентов», а с более скучной, но полезной настройкой процессов вокруг них. Победят не те команды, которые первыми перестанут читать код, а те, которые сумеют встроить ИИ в разработке так, чтобы скорость не съела понимание системы. И если ручной код и правда перестает быть нормой, то новой нормой становится не генерация сама по себе, а умение держать руль, пока машина едет быстрее человека.