Об искусственном интеллекте в разработке обычно говорят на языке производительности: сколько задач он помогает закрыть, сколько кода способен написать и насколько быстрее команда может выпустить новую функцию. Вокруг ИИ сформировался общий фон неизбежности. Компании внедряют AI‑агентов, руководители требуют повышать скорость, разработчики делятся конфигурациями и промптами. Вайбкодинг подается почти как следующий естественный этап профессии: достаточно описать желаемый результат, принять сгенерированное решение и двигаться дальше. Возникает ощущение, что писать код самостоятельно уже немного стыдно. Будто это устаревшая привычка людей, которые не научились пользоваться современными инструментами. Но за разговорами о производительности почти теряется другой вопрос:
Что происходит с самим разработчиком, когда значительную часть процесса создания программы берет на себя ИИ?
Эта статья не попытка доказать, что ИИ бесполезен, а ручной кодинг священен. Это скорее рассуждение о том, куда меняется профессия, почему многие разработчики неожиданно перестают получать удовольствие от работы и почему внешнее ускорение может сопровождаться внутренним выгоранием.
Является ли программирование творчеством?
Не каждое действие программиста носит творческий характер. Создать очередной DTO по готовому шаблону, добавить типовой обработчик или перенести существующий компонент в соседний модуль — в основном рутина. Для таких операций ИИ подходит прекрасно. Но программирование нельзя свести только к повторению шаблонов. Почти любую нетривиальную задачу можно решить множеством способов. Разработчик выбирает:
-
как разделить ответственность между компонентами;
-
где провести границы модулей;
-
какие состояния сделать явными;
-
что обобщить, а что оставить специализированным;
-
какую сложность принять;
-
чем пожертвовать ради простоты;
-
как система должна вести себя при ошибках.
У задачи может быть один ожидаемый результат, но путей к нему много. Поэтому точнее будет сказать:
Программирование — это инженерное ремесло с неизбежной творческой составляющей.
Код отражает не только знание синтаксиса. Он показывает, как разработчик думает о системе. Один человек стремится к маленьким функциям и явным зависимостям. Другой предпочитает более крупные, но линейные участки логики. Кто‑то быстро выделяет абстракции, а кто‑то ждет нескольких реальных повторений. Один делает ставку на строгие типы, другой — на простые структуры данных. Код в этом смысле похож на почерк. Не потому, что каждый разработчик должен навязывать проекту личный стиль, а потому, что в структуре решения остается след его рассуждений. Командные соглашения, линтеры и архитектурные ограничения этот почерк сдерживают, но не уничтожают. Ограничения лишь задают пространство, внутри которого человек принимает решения.
Написание кода — часть мышления
Сторонники максимальной автоматизации часто говорят, что написание кода — чистая механика. Будто разработчик сначала полностью придумывает решение, а потом лишь переносит его из головы в редактор. В реальной работе все происходит несколько иначе. Разработчик придумывает верхнеуровневое решение, пишет несколько строк, запускает код, замечает неудобство, меняет интерфейс, переносит ответственность и снова проверяет результат. Иногда только во время реализации становится понятно, что исходная декомпозиция была неправильной. Возникает цикл:
предположение → код → обратная связь → переосмысление → новое решение.
Код здесь выступает не только результатом мысли, но и инструментом мышления. Удовольствие приносит не набор символов и не расстановка скобок. Оно появляется, когда неясная идея постепенно превращается в работающую систему. Когда сложная задача раскладывается на понятные части. Когда находится удачная абстракция. Когда несколько разрозненных компонентов складываются в целое. Автоматизируя написание кода, можно убрать и часть процесса, в котором рождается само решение.
Когда ИИ помогает, а когда забирает процесс
Представим первый подход. Разработчик сам декомпозировал задачу, определил архитектуру и создал generic‑компоненты. Он понимает созданный API, ограничения и возможные сценарии повторного использования. Теперь нужно сделать несколько реализаций по готовому образцу. Это хорошая задача для ИИ: Вот существующий компонент. Создай три аналогичные реализации. Не меняй публичные интерфейсы и не вводи новые абстракции. В этом случае ИИ устраняет рутину. Он ускоряет репликацию уже найденного решения, но не забирает у человека проектирование. Разработчик остается автором системы.
Во втором подходе разработчик описывает требуемое поведение и основные правила проекта, но не определяет внутреннее устройство решения достаточно подробно. Оставшиеся пробелы заполняет ИИ: он выбирает, куда поместить логику, какие существующие компоненты использовать, нужно ли создавать новые сервисы и где провести границы ответственности. Чем больше неопределенности остается в постановке задачи, тем больше инженерных решений модель принимает вместо человека. Человеку остается прочитать результат работы агента. Формально время на написание кода сэкономлено. Фактически теперь нужно восстановить чужой ход мысли:
-
почему появилась эта абстракция;
-
какие предположения сделала модель;
-
зачем ответственность разделена именно так;
-
нет ли в проекте уже готового решения, могла ли модель его пропустить;
-
что сломается при следующем изменении требований.
Когда мы пишем код сами, его структура формируется вместе с нашей ментальной моделью. Когда код генерирует ИИ, эту модель приходится строить задним числом. Вместо создания начинается reverse engineering только что появившегося решения. В реальности подготовка подробного промпта может занимать время, сопоставимое с самостоятельной реализацией, а проверка и доведение сгенерированного кода до production‑качества — требовать еще больше сил. Главным источником напряжения является непредсказуемость результата: каждое изменение приходится воспринимать как потенциально ошибочное и перепроверять. Цикл работы меняется:
сформулировать запрос → получить генерацию → прочитать → найти проблему → уточнить запрос → снова прочитать.
Интеллектуальная нагрузка не исчезает. Но вместо исследования и созидания разработчик получает контроль качества чужих решений.
Вайбкодинг как новая норма
Сам по себе вайбкодинг может быть полезен. Он позволяет быстро собрать прототип, проверить идею, написать одноразовый скрипт или создать небольшой личный проект. Не каждый фрагмент кода заслуживает глубокого проектирования. Проблема начинается, когда экспериментальный подход переносят на долгоживущие системы и объявляют универсальной моделью разработки.
От разработчика начинают ожидать, что он будет формулировать намерение, передавать агенту доступ к проекту и оценивать готовый результат. Чем меньше человек вмешивается в реализацию, тем более современным и продуктивным он выглядит для руководства. Но между прототипом и production‑системой есть существенная разница. Прототип должен показать, что идея в принципе работает. Production‑код должен оставаться понятным, изменяемым, наблюдаемым и предсказуемым спустя месяцы и годы. Вайбкодинг хорошо оптимизирует момент появления первой работающей версии. Он гораздо хуже отвечает на вопрос, кто будет понимать эту версию после десятков следующих изменений.
Почему нельзя полностью доверять даже лучшим моделям
Топовая модель может быть сильнее среднего разработчика в отдельных задачах. Она способна быстро обработать много файлов, заметить повторения и предложить решение, до которого человек дошел бы значительно медленнее. Но высокая способность не равна гарантии корректности. Модель видит только переданный ей контекст. Она может не знать исторических причин архитектуры, неописанных доменных правил, будущих требований и договоренностей команды. Она способна создать убедительное решение, основанное на неверном предположении или вовсе проигнорировать описанные требования проекта.
Даже сами разработчики передовых моделей признают, что галлюцинации остаются нерешенной проблемой: более сильные модели ошибаются реже, но уверенные неправильные ответы не исчезают полностью. В коде такая ошибка может выглядеть правдоподобно:
-
несуществующий API;
-
неверная транзакционная граница;
-
тест, который ничего не проверяет;
-
нарушение архитектурного инварианта;
-
локально правильное изменение с системными последствиями;
-
обработанный happy path и забытый сценарий отказа.
Проверка другой нейросетью не создает абсолютной гарантии. Две модели могут использовать одинаковые предположения или не заметить одно и то же пропущенное требование. Автоматические тесты тоже проверяют только то, что в них было сформулировано. ИИ следует рассматривать не как источник истины, а как очень способного, быстрого и при этом не полностью предсказуемого участника разработки. Ответственность за принятое решение все равно остается у человека и команды.
Мы начинаем забывать, как работали без ИИ
Еще несколько лет назад разработчик, столкнувшись с задачей, читал код, документацию, ставил точки останова, строил гипотезы и проводил эксперименты. Теперь первым действием все чаще становится запрос к модели. Это удобно, но привычка быстро превращается в зависимость. Человек еще способен решить задачу самостоятельно, однако перестает доверять собственному рабочему процессу. Пустой файл начинает вызывать дискомфорт. Незнакомая ошибка сразу отправляется в чат. Вместо попытки проследить поток данных разработчик просит агента объяснить систему.
Мы не обязательно мгновенно теряем навык. Сначала мы просто перестаем его использовать. Затем исчезает уверенность, что без ИИ мы справимся достаточно быстро. После этого самостоятельная работа начинает восприниматься как неоправданно медленная, даже если именно она дает более глубокое понимание проекта. Особенно опасно это в новом проекте. Чтобы эффективно работать, разработчику нужно понять две стороны системы:
-
функциональную — что происходит с точки зрения пользователя и бизнеса;
-
техническую — как данные и управление проходят через код.
Если сразу поручать задачи агенту, можно быстро начать закрывать тикеты, не построив собственной модели проекта. ИИ найдет файлы, изменит несколько модулей и запустит тесты. Но разработчик может так и не узнать, где проходят реальные границы домена, почему архитектура сложилась именно так и какие инварианты не описаны в документации. Возникает продуктивность без погружения в предметную область. ИИ в таком случае полезнее сначала использовать как навигатор:
-
Проследи путь запроса от API до базы данных.
-
Найди места, где изменяется статус заказа.
-
Объясни назначение этих интерфейсов.
-
Не предлагай изменений.
После этого выводы нужно проверять по исходному коду, а первые изменения полезно выполнять самостоятельно. Объем делегирования стоит увеличивать вместе с пониманием проекта, а не вместо него.
Почему выгорание кажется внезапным
Человек редко выгорает в тот момент, когда впервые использует AI‑агента. Сначала все выглядит как освобождение. Задачи выполняются быстрее, рутины становится меньше, сложные технологии кажутся доступнее. Проблема накапливается постепенно.
Исчезает чувство авторства
Разработчик видит работающую функцию, но не переживает процесс ее создания. Он не обнаруживал закономерность, не выбирал форму решения и не проходил через последовательное уточнение модели. Вместо удовлетворения от найденного решения остается облегчение от того, что генерация наконец прошла тесты.
Созидание заменяется проверкой
Читать и проверять чужое решение часто сложнее, чем создавать собственное. Нужно одновременно понять намерение, восстановить модель и найти потенциальные ошибки. Разработчик может писать меньше кода, но уставать сильнее.
Пропадает состояние потока
Самостоятельная работа дает непрерывную связь между мыслью, действием и результатом. Вайбкодинг разработка часто состоит из ожидания, чтения больших изменений, переключения между файлами и повторных запросов. Вместо погружения появляется фрагментированное внимание.
Перестает ощущаться рост мастерства
Навык развивается, когда человек принимает решения и видит их последствия. Если ключевые решения постоянно передаются модели, становится сложнее понять, в чем именно вырос сам разработчик. Он лучше управляет агентом, но не всегда чувствует, что лучше проектирует системы.
Ускорение становится обязанностью
Освободившееся время редко остается свободным. Если раньше разработчик закрывал пять задач, а с ИИ может закрывать восемь, восемь быстро становятся новой нормой. Он получает не больше времени на архитектуру, а больше генераций, больше переключений контекста и больше кода для проверки. Снаружи все выглядит успешно: задачи закрываются, скорость растет, руководство довольно. Внутри человек все меньше чувствует связь с результатом. Поэтому выгорание кажется резким. Еще недавно разработчик был продуктивен, а затем внезапно потерял интерес к работе. Но сама потеря происходила постепенно: через уменьшение авторства, постоянную проверку, рост темпа и ощущение, что профессия превращается в управление чужими решениями.
Бизнес получает скорость. Что получает разработчик?
Для бизнеса программное обеспечение — средство достижения цели. Компании нужны функции, интеграции, автоматизация и сокращение расходов. Проблема не в этом. Проблема возникает, когда любую ручную работу объявляют бессмысленной только потому, что ее можно автоматизировать. Не всякая деятельность, которую способен выполнить ИИ, бесполезна для человека. Самостоятельное написание кода поддерживает:
-
понимание системы;
-
инженерный вкус;
-
навык отладки;
-
память о структуре проекта;
-
чувство авторства;
-
профессиональную идентичность.
Производительность легко измерить количеством задач и pull request. Гораздо сложнее измерить понимание системы командой, стоимость будущих изменений и потерю интереса к профессии. ИИ немедленно улучшает видимые показатели. Негативные последствия могут проявиться только через месяцы.
Это не призыв отказаться от ИИ
ИИ способен сделать разработку интереснее. Он хорошо убирает boilerplate, помогает изучать новые технологии, ускоряет прототипирование, ищет связанные участки кода и выполняет механический рефакторинг. Вопрос не в том, пишет ли модель код. Вопрос в том, какую роль оставляет себе человек. Здоровая модель выглядит примерно так:
Человек определяет:
-
доменную модель;
-
архитектурные границы;
-
ключевые абстракции;
-
инварианты;
-
критерии корректности.
ИИ помогает:
-
повторять известные паттерны;
-
искать нужный контекст;
-
создавать заготовки;
-
предлагать альтернативы;
-
выполнять механические изменения;
-
находить потенциальные ошибки.
После завершения задачи разработчик должен быть способен без помощи модели:
-
объяснить устройство решения;
-
изменить его под новое требование;
-
назвать основные сценарии отказа;
-
диагностировать проблему в production.
Если это невозможно, код формально принят, но фактически еще не стал частью инженерного знания команды.
Куда мы катимся?
Возможно, профессия действительно движется к тому, что человек будет все меньше писать код и все больше управлять автономными агентами. Это не обязательно плохо. Профессии меняются вместе с инструментами. Сейчас важно понимать, что происходит. Мы не просто избавляем разработчика от механической работы. Мы меняем саму форму его участия в создании программ. Вместе с рутиной можно случайно автоматизировать исследование, обучение, авторство и удовольствие от найденного решения. Мы теряем удовольствие от кодинга не тогда, когда ИИ пишет за нас отдельные строки. Мы теряем его тогда, когда перестаем участвовать в рождении решения и остаемся только контролерами результата. Поэтому главный вопрос звучит не так:
Какую часть кода способен написать ИИ?
Гораздо важнее спросить:
Какую часть процесса мы готовы ему отдать, не потеряв понимание, мастерство и удовольствие от работы?
ИИ может быть инструментом, который помогает быстрее реализовать наш замысел. А может превратить нас в людей, бесконечно проверяющих замыслы машины. Разница между этими сценариями определяется не возможностями модели, а границей, которую проводит разработчик, его команда и бизнес.
Автор: dmitrykologrivko
