Представьте себе: вы наблюдаете, как кто-то «пишет код». На экране — редактор, пара открытых вкладок, мигает курсор. Но человек почти не печатает. Он просто сидит и задумчиво смотрит в одну точку.
Нет, он не ленится. Просто программирование — это не про набор текста, а про решение задач. Как в кроссворде: большая часть работы происходит в голове, а не на клавиатуре.

В жизненном цикле разработки код — это лишь заполненные клеточки кроссворда. Самое интересное — в размышлениях: изучение предметной области, уточнение требований, продумывание архитектуры, поиск компромиссов, поэтапное тестирование и отладка.
Если коротко, процесс выглядит примерно так: сначала думаем — потом пишем.

Но с приходом ИИ-кодинга всё изменилось.
«Сначала код, потом вопросы»
Инструменты вроде Claude Code позволяют писать код молниеносно — без контекста, без долгих раздумий. Однако реальное ПО не живёт в вакууме. Оно существует в сложных системах, и пока LLM-модели не умеют держать весь контекст проекта в памяти, человеческая проверка и тестирование никуда не денутся.
Тут возникает парадокс: если человек не уделял время на размышления до написания кода, ему потом приходится тратить его на то, чтобы понять, что же ИИ вообще сгенерировал.

Вот в этом и есть разница между рекламными обещаниями — «ИИ ускоряет разработку в 10 раз!» — и реальностью, где прирост производительности в продакшене ближе к 10%.
Ещё неприятный побочный эффект: разработчики всё больше занимаются только исправлением генераций. ИИ с лёгкостью штампует код, а для людей остаются скучные задачи: тестирование, устранение дублей, документация, деплой, инфраструктура. Реального «кодинга» — того, ради чего большинство разработчиков вообще пришли в профессию — остаётся всё меньше.

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

Но расплата приходит позже: знания концентрируются у одного человека, отчего поддерживать систему становится всё труднее. Со временем весь рабочий процесс начинает держаться только на одном тимлиде.
Итог предсказуем — перегруз, выгорание, увольнение, кризис. Команда остаётся без того единственного человека, который понимал, как всё работает.

Решение, как обычно, лежит посередине. Звучит оно примерно так:
Нужно выстроить рабочий процесс так, чтобы команда могла писать надёжный код без бесконечных правок, слаженно взаимодействовать друг с другом и при этом расти профессионально.
Когда я был CTO в Datasine, мы сформулировали это в виде короткого девиза команды:
Learn. Deliver. Have fun. — Учись. Делай. Наслаждайся.
Хороший тимлид умеет подбирать для разработчиков задачи на грани их возможностей — не слишком лёгкие, но и не губительно сложные. При этом он выстраивает процессы, которые позволяют не только ошибаться без серьёзных последствий, но и помогают учиться на своих ошибках.
Классические практики, которые помогают в этом деле, знакомы всем:
Code review
Инкрементальная поставка
Модульный дизайн
Test-Driven Development
Парное программирование
Документация
CI/CD
И главный вопрос 2025 года: как адаптировать эти принципы в эпоху ИИ-кодинга?
LLM — это очень быстрые «джуны»
Сегодня многие разработчики оказались в роли, до боли знакомой каждому тимлиду: рядом талантливый, но непредсказуемый «младший инженер». ИИ-модели поражают скоростью, но нуждаются в жёстком контроле. И управлять ими нужно иначе, чем людьми, потому что природа их «продуктивности» совсем другая.
Обычные инженеры, по мере накопления опыта, растут сразу по двум направлениям:
Качество: пишут более сложный, надёжный, поддерживаемый код.
Скорость: делают задачи быстрее, с меньшим количеством багов.
Хорошие инженеры развиваются по обеим осям одновременно.

Первые LLM были быстры в написании кода, но требовали массу правок, занимающих много времени. Современные модели стали куда умнее: контекстная подача, инструменты, улучшенные промпты — всё это позволило ИИ писать код, который работает с первого раза. Сегодня LLM действительно могут решать задачи уровня близкому к мидл — но до сеньоров им далеко.
Так что можно рассматривать ИИ-кодеров как очень быстрых джунов с двумя ключевыми особенностями:
Они пишут код в сотни раз быстрее любого новичка — без раздумий, без пауз.
Они не учатся. Улучшить их можно только снаружи — с помощью нового контекста или новой модели.
Как и с реальными джунами, можно выбрать один из двух подходов:
AI-driven engineering: внедрять лучшие практики, обеспечивать понимание кода, двигаться медленно, но устойчиво.
Vibe coding: забить на процессы, выпускать новые фичи любой ценой, жертвуя пониманием ради скорости — до тех пор, пока кодовая база не превратится в хаос.
И, как легко догадаться, vibe-coding заканчивается так же, как и привычка тимлида брать всё на себя: короткий успех, потом катастрофа.
Для небольших проектов и прототипов vibe-coding даже удобен. Если приложение простое, можно дать ИИ «побаловаться» и получить рабочий результат за пару часов. Ограничить сложность задачи — значит использовать сильные стороны модели.

Но стоит системе вырасти — ИИ упрётся в стену сложности, через которую не пройти без человеческого анализа. Да, собирать прототипы стало проще, чем когда-либо. Но если мы хотим ускорить реальную разработку — сложных, безопасных, поддерживаемых систем — нужны новые инженерные практики. Такие, которые позволят людям и ИИ эффективно работать вместе.
Как не попасть в ловушку ИИ-кодинга
ИИ-агенты поражают продуктивностью, но ничего не знают о вашем бизнесе, архитектуре или планах по развитию. Если модель не направлять, она с радостью сгенерирует тысячи строк кода без малейшего внимания к дизайну, консистентности или поддерживаемости. Задача инженера теперь — быть тимлидом для ИИ: задать рамки, стандарты и процессы, чтобы превратить сырую скорость в устойчивую поставку.
Чтобы писать рабочее ПО эффективно, нам нужен новый набор правил. Достаточно вспомнить, как мы выстраивали процессы в командах. Если рассматривать LLM как сверхбыстрых джунов, то логика та же: применяем старые добрые практики, но теперь к взаимодействию человека и модели.

ИИ может быть полезен на каждом этапе жизненного цикла разработки:
Спецификация. Использовать модели для анализа и уточнения требований, проработки крайних сценариев.
Документация. Генерировать и ревьюить документацию заранее, чтобы задать «рельсы» для кода и зафиксировать важные детали проекта.
Модульный дизайн. Строить архитектуру, где каждый компонент изолирован и понятен модели.
TDD. Генерировать тесты до написания кода — как шаблон и страховку от регрессий.
Стандарты кода. Задавать стандарты и проверенные подходы прямо в контексте промпта, чтобы ИИ следовал корпоративным правилам.
Мониторинг и анализ. Поручать ИИ разбор логов и выявление причин сбоев или неочевидных зависимостей — он справится с этим быстрее любого человека.
Понимая, что разработка — это гораздо большее, чем просто набор кода, мы можем избежать ловушки ИИ-кодинга и использовать его не как замену, а как помощника — инструмент, который действительно ускоряет путь к работающему, масштабируемому, качественному софту.
Спасибо за внимание, ваш Cloud4Y. Читайте нас здесь или в Telegram‑канале!
Комментарии (3)
AlxB
09.10.2025 13:03Что-то мне это напоминает. А, вот что. Я устраиваюсь на 2-3 года на завод, запускаю новое оборудование, чуть допиливаю старое и формирую ассортимент. Под него пишу технологические инструкции.
Начинаю обучать персонал. Они не хотят понимать. Они ссылки на школьный курс геометрии и физики за 8 класс воспринимают как издевательство (как нужно увеличить разницу давлений в тоннеле, чтобы объëм теплоносителя вырос на 10% - закон Бернулли, школьный курс физики. Как отличить прямоугольник от трапеции - геометрия за 6 класс, померять диагонали).
Они выполняют инструкции, и всë идëт хорошо.
Потом нужно снова поменять ассортимент. Потому что прежний устарел.
Мы начинаем не от достигнутого. Мы просто все инструкции переписываем с нуля. Потому что никакого развития за условные пять лет не было и быть не могло. Потому что никому оно было не нужно.
Может быть, это и в IT так?
(Если что, я делаю керамический кирпич лицевой).
Dhwtj
Задача должна быть поставлена по SMART.
Как минимум из SMART, задача должна быть понятна и проверяема.
Остальные задачи не делегируй. Если хочешь, чтобы было хорошо - сделай это сам©
Я писал про этому поводу https://habr.com/ru/articles/953344/
А ловушка в том, что LLM не напишет что он что-то не понял или не уверен. Будет врать до последнего.
Einherjar
Выходцы из Индии ведут себя так же в общем то