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

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

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

Если коротко, процесс выглядит примерно так: сначала думаем — потом пишем.

Сначала думаем — потом пишем
Сначала думаем — потом пишем

Но с приходом ИИ-кодинга всё изменилось.

«Сначала код, потом вопросы»

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

Тут возникает парадокс: если человек не уделял время на размышления до написания кода, ему потом приходится тратить его на то, чтобы понять, что же ИИ вообще сгенерировал.

Сначала пишем — потом думаем
Сначала пишем — потом думаем

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

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

Разница между традиционным и ИИ-кодингом
Разница между традиционным и ИИ-кодингом

Но это не новая проблема. На самом деле мы уже сталкивались с ней раньше — просто теперь она проявилась в новой форме. И её можно описать старым, но точным термином.

Дилемма тимлида

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

При этом почти всегда тимлид — самый опытный человек в команде. У него больше знаний и по предметной области, и по архитектуре, и по инструментам. Но есть проблема: разный уровень опыта сильно влияет на скорость разработки. 

Перед тимлидом встаёт выбор между двумя стратегиями:

  1. Честно делегировать задачи всем, включая младших инженеров — дать им шанс учиться и брать ответственность, но замедлить команду из-за их темпа.

  2. Брать на себя всё сложное, а младшим отдавать только простые задачи — так проект будет развиваться быстро, но команда не начнёт расти.

Второй вариант, как ни странно, работает, особенно на короткой дистанции. Опытный инженер берёт на себя самые трудные задачи и закрывает их одна за другой. Общий прогресс команды впечатляет.

 Опытные инженеры способны брать на себя больше задач
Опытные инженеры способны брать на себя больше задач

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

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

 Избыточный контроль — быстрый успех, потом крах
Избыточный контроль — быстрый успех, потом крах

Решение, как обычно, лежит посередине. Звучит оно примерно так:

Нужно выстроить рабочий процесс так, чтобы команда могла писать надёжный код без бесконечных правок, слаженно взаимодействовать друг с другом и при этом расти профессионально.

Когда я был CTO в Datasine, мы сформулировали это в виде короткого девиза команды:

Learn. Deliver. Have fun. — Учись. Делай. Наслаждайся.

Хороший тимлид умеет подбирать для разработчиков задачи на грани их возможностей — не слишком лёгкие, но и не губительно сложные. При этом он выстраивает процессы, которые позволяют не только ошибаться без серьёзных последствий, но и помогают учиться на своих ошибках.

Классические практики, которые помогают в этом деле, знакомы всем:

  • Code review

  • Инкрементальная поставка

  • Модульный дизайн

  • Test-Driven Development

  • Парное программирование

  • Документация

  • CI/CD

И главный вопрос 2025 года: как адаптировать эти принципы в эпоху ИИ-кодинга?

LLM — это очень быстрые «джуны»

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

Обычные инженеры, по мере накопления опыта, растут сразу по двум направлениям:

  1. Качество: пишут более сложный, надёжный, поддерживаемый код.

  2. Скорость: делают задачи быстрее, с меньшим количеством багов.

Хорошие инженеры развиваются по обеим осям одновременно.

Хорошие инженеры развиваются по обеим осям одновременно.
Хорошие инженеры развиваются по обеим осям одновременно.

Первые LLM были быстры в написании кода, но требовали массу правок, занимающих много времени. Современные модели стали куда умнее: контекстная подача, инструменты, улучшенные промпты — всё это позволило ИИ писать код, который работает с первого раза. Сегодня LLM действительно могут решать задачи уровня близкому к мидл — но до сеньоров им далеко.

Так что можно рассматривать ИИ-кодеров как очень быстрых джунов с двумя ключевыми особенностями:

  1. Они пишут код в сотни раз быстрее любого новичка — без раздумий, без пауз.

  2. Они не учатся. Улучшить их можно только снаружи — с помощью нового контекста или новой модели.

Как и с реальными джунами, можно выбрать один из двух подходов:

  • AI-driven engineering: внедрять лучшие практики, обеспечивать понимание кода, двигаться медленно, но устойчиво.

  • Vibe coding: забить на процессы, выпускать новые фичи любой ценой, жертвуя пониманием ради скорости — до тех пор, пока кодовая база не превратится в хаос.

И, как легко догадаться, vibe-coding заканчивается так же, как и привычка тимлида брать всё на себя: короткий успех, потом катастрофа.

Для небольших проектов и прототипов vibe-coding даже удобен. Если приложение простое, можно дать ИИ «побаловаться» и получить рабочий результат за пару часов. Ограничить сложность задачи — значит использовать сильные стороны модели.

 Vibe-coding работает, пока не нужно включать голову.
Vibe-coding работает, пока не нужно включать голову.

Но стоит системе вырасти — ИИ упрётся в стену сложности, через которую не пройти без человеческого анализа. Да, собирать прототипы стало проще, чем когда-либо. Но если мы хотим ускорить реальную разработку — сложных, безопасных, поддерживаемых систем — нужны новые инженерные практики. Такие, которые позволят людям и ИИ эффективно работать вместе.

Как не попасть в ловушку ИИ-кодинга

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

Чтобы писать рабочее ПО эффективно, нам нужен новый набор правил. Достаточно вспомнить, как мы выстраивали процессы в командах. Если рассматривать LLM как сверхбыстрых джунов, то логика та же: применяем старые добрые практики, но теперь к взаимодействию человека и модели.

ИИ полезен на каждом этапе разработки
ИИ полезен на каждом этапе разработки

ИИ может быть полезен на каждом этапе жизненного цикла разработки:

  • Спецификация. Использовать модели для анализа и уточнения требований, проработки крайних сценариев.

  • Документация. Генерировать и ревьюить документацию заранее, чтобы задать «рельсы» для кода и зафиксировать важные детали проекта.

  • Модульный дизайн. Строить архитектуру, где каждый компонент изолирован и понятен модели.

  • TDD. Генерировать тесты до написания кода — как шаблон и страховку от регрессий.

  • Стандарты кода. Задавать стандарты и проверенные подходы прямо в контексте промпта, чтобы ИИ следовал корпоративным правилам.

  • Мониторинг и анализ. Поручать ИИ разбор логов и выявление причин сбоев или неочевидных зависимостей — он справится с этим быстрее любого человека.

Понимая, что разработка — это гораздо большее, чем просто набор кода, мы можем избежать ловушки ИИ-кодинга и использовать его не как замену, а как помощника — инструмент, который действительно ускоряет путь к работающему, масштабируемому, качественному софту.

Спасибо за внимание, ваш Cloud4Y. Читайте нас здесь или в Telegram‑канале!

Комментарии (3)


  1. Dhwtj
    09.10.2025 13:03

    Задача должна быть поставлена по SMART.

    Как минимум из SMART, задача должна быть понятна и проверяема.

    Остальные задачи не делегируй. Если хочешь, чтобы было хорошо - сделай это сам©

    Я писал про этому поводу https://habr.com/ru/articles/953344/

    А ловушка в том, что LLM не напишет что он что-то не понял или не уверен. Будет врать до последнего.


    1. Einherjar
      09.10.2025 13:03

      А ловушка в том, что LLM не напишет что он что-то не понял или не уверен. Будет врать до последнего

      Выходцы из Индии ведут себя так же в общем то


  1. AlxB
    09.10.2025 13:03

    Что-то мне это напоминает. А, вот что. Я устраиваюсь на 2-3 года на завод, запускаю новое оборудование, чуть допиливаю старое и формирую ассортимент. Под него пишу технологические инструкции.

    Начинаю обучать персонал. Они не хотят понимать. Они ссылки на школьный курс геометрии и физики за 8 класс воспринимают как издевательство (как нужно увеличить разницу давлений в тоннеле, чтобы объëм теплоносителя вырос на 10% - закон Бернулли, школьный курс физики. Как отличить прямоугольник от трапеции - геометрия за 6 класс, померять диагонали).

    Они выполняют инструкции, и всë идëт хорошо.

    Потом нужно снова поменять ассортимент. Потому что прежний устарел.

    Мы начинаем не от достигнутого. Мы просто все инструкции переписываем с нуля. Потому что никакого развития за условные пять лет не было и быть не могло. Потому что никому оно было не нужно.

    Может быть, это и в IT так?

    (Если что, я делаю керамический кирпич лицевой).