Почему генерация ускоряет результат, но не гарантирует рост инженера?
Под первой частью самым популярным оказался комментарий: «Статью похоже тоже навайбкодили». Заслужил. Но рядом прозвучало замечание намного важнее: дело не в самом вайбкодинге, а в опыте человека, который им занимается.
Опытный инженер тоже может открыть Cursor, Claude Code, Copilot или Codex, сформулировать задачу и принять большой кусок сгенерированного кода. Иногда он вообще будет печатать руками меньше новичка. Поэтому противопоставление «настоящая разработка против AI» быстро перестало описывать реальность. Граница проходит в другом месте. Один человек получает правдоподобный ответ и видит готовую фичу. Другой видит гипотезу, которую нужно проверить: где проходит trust boundary, что произойдет при повторном запросе, кто владеет данными, как откатится миграция, что попадет в метрики и какой сценарий сломается первым.
Скрытый текст
AI не уравнивает новичка и опытного инженера. Он убирает разницу в скорости набора кода и делает заметнее разницу в качестве суждения.
И здесь возникает вопрос, который в комментариях оказался интереснее исходной статьи: если начинающие разработчики получают правильноподобный результат до того, как научились разбирать собственные ошибки, откуда через пять лет возьмутся люди, способные этот результат проверять?
Ниже не будет призыва запретить AI или заставить всех снова писать сортировку пузырьком в блокноте. Речь о другом: как сохранить тренировочный контур профессии, когда производственный контур меняется быстрее учебных программ.
1. Один и тот же инструмент, две разные профессии
Представим двух разработчиков, которым дали одинаковую задачу: добавить авторизацию и разделить данные клиентов в B2B‑сервисе.
Первый пишет: «Сделай авторизацию через Supabase». Агент создает таблицы, middleware, форму входа и несколько политик доступа. Локально все работает. Один пользователь видит свои записи. Значит, задача закрыта.
Второй начинает с того же запроса, но его работа начинается после генерации. Он спрашивает, где заканчивается authentication и начинается authorization. Проверяет RLS для каждой таблицы. Пробует подменить tenant_id. Разбирает refresh и revoke токенов. Кто вырастит будущих сеньоров, если код теперь пишет AI? 3 Смотрит, какие endpoints доступны анонимному ключу. Добавляет негативные тесты и аудит административных действий.
Внешне оба использовали AI. Более того, первый мог получить результат быстрее. Но второй выполнил инженерную работу: сформулировал инварианты, обнаружил границы доверия, построил проверку и взял на себя решение о выпуске. Раньше часть этой разницы была видна в самом коде: senior писал быстрее, знал библиотеки, помнил синтаксис и узнавал типичные ошибки. Теперь синтаксическая фора уменьшается. Ценность смещается к тому, что трудно увидеть на демо:
умению превратить размытое пожелание в проверяемые требования
способности заметить отсутствующее условие, а не только противоречие
пониманию failure modes, данных, безопасности и эксплуатации
калиброванному недоверию, то есть знанию, что и насколько тщательно проверять
готовности остановить релиз, когда интерфейс уже выглядит готовым
Это не романтизация стажа. Двадцать лет работы сами по себе ничего не гарантируют. Но опыт, накопленный через решения, ошибки, инциденты и review, создает библиотеку паттернов, которую невозможно заменить общим промптом «проверь все».
2. Парадокс хорошего промпта
В обсуждении первой части один читатель описал агентный workflow, который второй день отказывался продолжать, пока автор не устранит противоречия в правилах фичи. На это ему ответили коротко и точно: ключевые слова здесь — «которые я ему задал». Чтобы агент нашел противоречие, человек сначала должен знать, какие правила вообще существуют. Отсюда парадокс генеративной разработки: чем меньше разработчик понимает предметную область, тем сложнее ему сформулировать хороший запрос. А чем лучше он понимает предметную область, тем меньше магии остается в запросе. Хороший промпт превращается в компактную техническую спецификацию. Для атомарного счетчика мало написать «увеличивай count безопасно». Нужно определить конкурентные записи, транзакционную границу, семантику повторной доставки, допустимость lost update, поведение при retry и источник истины. Для платежа мало попросить «не списывать дважды». Нужны idempotency key, состояние операции, срок хранения ключа, правила reconciliation и ответ на вопрос, что делать после timeout неизвестного исхода. Спецификация без противоречий при этом может быть полностью неправильной. Можно безупречно описать систему, которая теряет деньги. Модель способна проверить соответствие кода тексту, но ей труднее сообщить о требовании, которого нет ни в тексте, ни в контексте.
Скрытый текст
Чтобы задать AI правильный вопрос, часто нужно уже знать значительную часть ответа
Поэтому prompt engineering не заменяет предметную экспертизу. Он делает ее интерфейсом. Если за интерфейсом пусто, модель получает красиво сформулированную неопределенность
3. Модель может знать правило и нарушить его в следующем сообщении
Самый наглядный пример из комментариев был почти лабораторным. Разработчику понадобилось атомарно обновлять счетчик. Модель корректно объяснила подход. Затем получила собственное объяснение как спецификацию и сгенерировала реализацию с ошибкой. Проблема обнаружилась только потому, что человек открыл код и прочитал его.
Эта сцена разрушает удобную рекурсию «пусть AI проверит AI». Независимый прогон действительно полезен: другая модель, другой контекст, статический анализатор и тесты ловят часть дефектов. Но несколько вероятностных ответов не превращаются автоматически в доказательство корректности.
У проверки есть уровни:
синтаксис: запускается ли код
локальная логика: делает ли функция то, что написано в тесте
контракт: совместима ли реализация с соседними компонентами
инварианты: сохраняются ли деньги, права и данные при конкуренции и сбоях
намерение: ту ли задачу вообще решает система
эксплуатация: можно ли понять, что она ошиблась, и безопасно восстановиться
AI особенно силен на первых уровнях, где обратная связь формализована. Чем ближе проверка к бизнес‑намерению и редким failure modes, тем больше требуется человеческого контекста. Не потому, что модель «глупая», а потому, что часть правильности находится вне репозитория: в договорах, процессах, истории инцидентов и негласных ограничениях бизнеса.
4. AI убирает трение. Но часть трения была обучением
Традиционный путь junior‑разработчика был неэффективным в буквальном смысле. Он читал документацию, ошибался в индексе массива, час искал причину race condition, получал замечания на review, переписывал миграцию и однажды узнавал, что backup без проверенного restore — не backup.
Никто не обязан ностальгировать по бессмысленным страданиям. Большая часть рутины действительно заслуживает автоматизации. Но вместе с рутиной AI может убрать причинно‑следственную связь между решением и результатом.
Когда человек сам построил неверную модель и увидел ее разрушение, у него появляется диагностическая память. Когда он получил готовый код, увидел зеленые тесты и пошел дальше, опыт может не сформироваться вообще. Он завершил задачу, но не обязательно увеличил способность завершить следующую без подсказки.
Исследования пока не дают простого приговора. В контролируемом эксперименте 2023 года с 69 начинающими участники с Codex лучше выполняли задания на написание кода, а их результаты на последующих тестах без генератора не ухудшились. Авторы отдельно отметили, что больше выгоды получили участники с более сильной исходной подготовкой [2].
Кто вырастит будущих сеньоров, если код теперь пишет AI? 6 Более свежий мета‑анализ 2026 года пришел к осторожному выводу: coding assistants в среднем повышают продуктивность, но убедительного переноса в устойчивые учебные результаты пока не видно; заметный выигрыш чаще сохраняется, когда AI доступен и во время самой оценки [8]. Это не доказывает «отупление». Это показывает, что выполненная задача и приобретенный навык — разные метрики.
5. Скорость вообще оказалась сложнее, чем кажется
Даже вопрос «ускоряет ли AI разработчика?» не имеет одного числа. В эксперименте GitHub 2022 года участники с Copilot завершили изолированную задачу по написанию HTTP‑сервера примерно на 55% быстрее. В исследовании METR начала 2025 года 16 опытных open‑source‑разработчиков решали реальные задачи в знакомых крупных репозиториях и с AI в среднем потратили на 19% больше времени. При этом они ожидали ускорения и после эксперимента продолжали считать, что ускорились.
Важно не превратить второе число в вечный аргумент против AI. В обновлении 2026 года METR прямо пишет, что новые инструменты, вероятно, ускоряют разработчиков сильнее, но измерение стало труднее: активные пользователи не хотят работать без AI, выбирают для эксперимента другие задачи и параллельно запускают нескольких агентов. Новые оценки оказались слишком смещенными для уверенного вывода.
55% | 19% | 46% |
быстрее в лабораторной задаче | медленнее в знакомых OSS‑репозитория | разработчиков не доверяют точности AI |
GitHub, 2022 | METR, 2025 | Stack Overflow, 2025 |
Три числа не противоречат друг другу. Они измеряют разные задачи, эпохи инструментов и контексты. Лабораторный endpoint, двухчасовой issue в миллионной кодовой базе и развитие инженера на горизонте пяти лет — не одна и та же продуктивность.
DORA в отчете 2025 года использует удачную формулу: AI является усилителем организационной системы. Он увеличивает преимущества сильной платформы, понятных стандартов и быстрого feedback loop, но так же масштабирует слабые процессы и неясную ответственность.
6. Исчезает не профессия junior. Исчезает безопасная простая работа
Раньше команда могла дать начинающему разработчику ограниченную задачу: добавить CRUD, написать адаптер, перенести форму, обновить набор тестов. Ценность была двойной. Компания получала небольшой результат, а junior учился читать кодовую базу, соблюдать контракт и проходить review.
Кто вырастит будущих сеньоров, если код теперь пишет AI? 7 Теперь агент делает такую задачу за минуты. Для бизнеса возникает рациональный вопрос: зачем тратить senior‑время на постановку и review учебной работы, если тот же senior может попросить AI и сразу получить результат?
Если ответом станет просто сокращение входных позиций, отрасль создаст отложенный дефицит. Senior — не человек, прочитавший больше документации. Это человек, который много раз связывал техническое решение с последствиями. Без участия в реальной работе такая связь не появляется.
Но сохранять старую пирамиду искусственно тоже бессмысленно. Нельзя поручать человеку механический boilerplate только ради воспитательного эффекта, если инструмент делает его дешевле и надежнее. Значит, меняется единица обучения.
Junior будущего должен получать не «маленький кусок кода», а маленький контур ответственности:
восстановить намерение задачи по issue и разговорам
предложить инварианты и негативные сценарии до генерации
дать агенту реализовать ограниченную часть
объяснить каждое значимое решение в diff
провести тест, rollout и наблюдение метрик
разобрать расхождение между прогнозом и реальностью
Такой процесс дороже, чем просто принять AI‑output. Но это инвестиция не в скорость текущего коммита, а в способность команды принимать решения через год.
7. Human in the loop — это не кнопка Approve
Фраза human in the loop успела стать почти ритуальной. Иногда она означает, что человек видит гигантский diff после сорока минут автономной работы агента и нажимает accept, потому что разбирать уже дороже, чем переписать.
Настоящий человеческий контур устроен иначе: ответственность включена на каждом переходе, а задача разбита так, чтобы review оставался когнитивно возможным.
Хороший цикл начинается до промпта. Человек фиксирует инварианты и критерии приемки. AI предлагает план. План сравнивается с архитектурой. Реализация идет небольшими порциями. Тесты проверяют не только happy path. После деплоя результат наблюдается в метриках. Если реальность расходится с ожиданием, обновляется не только код, но и модель задачи.
Кто вырастит будущих сеньоров, если код теперь пишет AI? 8 Это напоминает зрелое pair programming: быстрый участник может печатать почти все, но navigator удерживает направление, замечает пропущенное и решает, когда остановиться. Только AI‑партнер не разделяет с вами ответственность и не устает звучать уверенно.
Опрос Stack Overflow 2025 года хорошо показывает калибровку отрасли: 46% разработчиков скорее не доверяют точности AI‑инструментов, доверяют 33%, а среди опытных специалистов доля сильного недоверия выше. Осторожность растет вместе с ответственностью не случайно: опыт дает больше способов представить, как правдоподобный ответ может быть неверным.
8. Как использовать AI так, чтобы компетентность росла
Запрет не нужен. Нужна разница между производственным режимом, где мы оптимизируем delivery, и тренировочным, где мы оптимизируем понимание. Один и тот же человек может переключаться между ними в течение дня.
В исследовании DORA и UC Berkeley 2026 года студенты сами описывали похожие ограничения: сначала пытались решить задачу без AI, проверяли код построчно, чередовали работу с инструментом и без него. Их тревога была не про академическую чистоту, а про потерю способности думать самостоятельно.
Для практики я бы ввел семь правил:
Сначала прогноз, потом генерация. До обращения к модели записать ожидаемое решение, риски и результат теста. Иначе невозможно понять, чему именно вы научились после ответа.
Просить не код, а варианты и trade‑offs. Пусть модель предложит три подхода, условия применимости и способы опровержения. Выбор остается за человеком.
Объяснять diff своими словами. Если автор не может защитить изменение на review без фразы «так предложил агент», изменение еще не готово.
Периодически работать без AI. Не ради аскезы, а как контрольный замер: какие части компетенции принадлежат человеку, а какие существуют только при подключенном сервисе.
Давать задачи на диагностику. Разбор чужого дефекта, инцидента или медленного запроса обучает лучше, чем еще один зеленый CRUD, потому что требует строить и проверять гипотезы.
Оценивать не количество закрытых задач. Важно, стал ли разработчик точнее предсказывать риски, формулировать инварианты, уменьшать размер diff и находить дефекты до CI.
Оставлять человеку последствия. Автор изменения участвует в rollout, смотрит метрики и разбирает сбои. Без обратной связи опыт не замыкается.
Режим | AI делает за человека | AI усиливает обучение |
Постановка | Получает короткую команду | Предлагает вопросы и конфликты |
Реализация | Генерирует крупный diff | Работает малыми проверяемыми шагами |
Проверка | Сам подтверждает свой ответ | Помогает построить независимые проверки |
Результат | Задача закрыта | Человек может объяснить и воспроизвести решение |
9. Что придется изменить командам
Проблема будущих senior‑специалистов не решается личной дисциплиной junior‑разработчика. Если организация вознаграждает только скорость закрытия тикетов, AI закономерно превратится в фабрику непроверенных diff. Учебный контур должен быть частью системы.
Code review нужно вернуть к намерению. Вопрос «работает ли код?» теперь часто закрывают тесты и агенты. На review важнее обсуждать: какой инвариант защищает изменение, почему выбран этот trade‑off, что произойдет при сбое и как мы узнаем о проблеме.
Размер задачи должен ограничиваться проверяемостью. Агент способен за один запуск изменить десятки файлов. Но пропускная способность человека на содержательное review почти не выросла. Большие диффы превращают human in the loop в театральную декорацию.
Нужны design review и post‑implementation review. Первый проверяет решение до генерации. Второй сравнивает первоначальную модель с тем, что реально произошло в разработке и эксплуатации.
Менторство становится более, а не менее ценным. Senior теперь не обязан показывать, как набрать код. Он показывает, что проверить, какие вопросы задать, где искать неявный контракт и почему зеленый тест иногда ничего не доказывает.
Инциденты должны становиться учебным материалом. Обезличенный postmortem, replay трассировки и восстановление цепочки решений формируют инженерную интуицию быстрее, чем коллекция идеальных туториалов.
В итоге команда перестает измерять развитие объемом самостоятельного кодинга. Более честный показатель — насколько человек способен увеличивать область ответственности, не теряя калибровки.
10. Новая лестница компетенций
Если генерация кода становится базовой возможностью, уровни профессии можно описать иначе
Уровень | Ключевая способность | Типичная ошибка |
Исполнитель | Получить работающий результат по четкой задаче | Считать demo доказательством готовности |
Проверяющий | Найти дефект в коде и тестах | Проверять только то, что уже сформулировано |
Проектировщик | Задать инварианты, контракты и failure modes | Оптимизировать локально, не видя систему |
Владелец решения | Связать технику, бизнес‑риск и эксплуатацию | Перепутать скорость выпуска с ценностью |
Инженерный лидер | Создать среду, где правильные решения масштабируются | Надеяться на героизм отдельных senior |
На такой лестнице junior не исчезает. Он просто раньше начинает работать с требованиями и проверкой, а не годами остается человеком, которому доверяют только синтаксис. Это повышает планку входа, но одновременно делает обучение ближе к реальной профессии.
11. Так откуда все‑таки возьмутся будущие сеньоры?
Они появятся не вопреки AI и не благодаря одному лишь доступу к нему. Они появятся там, где AI используют для расширения практики, а не для ее сокрытия.
Начинающий разработчик с агентом может за год увидеть больше архитектурных вариантов, прочитать больше чужого кода и попробовать более сложные проекты, чем раньше за три года. Это реальное преимущество. Но оно реализуется только тогда, когда человек остается автором гипотез, проверок и выводов.
Если же процесс оптимизирован исключительно под количество принятых строк, возникает другой специалист: быстрый оператор генерации с широкой поверхностью действий и узкой областью понимания. Пока система работает, разница незаметна. Она проявляется в момент, когда требования противоречат друг другу, тест подтверждает неверное поведение, агент уверенно меняет не тот слой, а production возвращает событие, которого никто не предусмотрел.
Мы не конкурируем с AI в скорости написания кода. Мы отвечаем за то, какой код вообще должен существовать.
Поэтому зрелая команда продает не ручной набор символов и не секретные промпты. Она продает способность принимать решения при неполной информации, проверять их несколькими независимыми способами, наблюдать последствия и менять курс до того, как ошибка станет стоимостью бизнеса.
AI резко подешевел производство ответа. Теперь главным дефицитом становится хороший вопрос, независимая проверка и человек, который готов подписаться под результатом. Именно на этих навыках и придется выращивать следующую генерацию инженеров.
Перед тем как принять AI‑generated change
Я могу своими словами объяснить намерение изменения и его границы
До генерации были записаны инварианты и негативные сценарии
Diff достаточно мал, чтобы его действительно прочитать
Тесты проверяют сбои, повторы, конкуренцию и права, где это применимо
Есть независимая проверка, не основанная только на ответе той же модели
Понятно, какие метрики подтвердят корректность после релиза
Есть безопасный rollback или другой план восстановления
Автор изменения участвует в наблюдении результата
Если AI недоступен, команда все еще понимает, как устроено решение
Не обязательно писать каждую строку руками. Обязательно понимать каждое решение, которое вы выпускаете в production.
Источники и исследовании
GitHub Research. Quantifying GitHub Copilot's impact on developer productivity, 2022
METR. Measuring the Impact of Early-2025 AI on Experienced Open‑Source Developer Productivity, 2025
METR. We are Changing our Developer Productivity Experiment Design, February 2026
DORA / UC Berkeley. Managing AI dependency: How students are establishing guardrails with AI, 2026
