Есть один, уже набивший оскомину спор, по популярности уступающий, пожалуй, только извечному спору Iphone vs Android. Это спор сможет ли вайбкодер с ИИ заменить программистов старой школы.
Все в итоге плюс минус сходятся во мнении, что вайбкодеры «с нуля» не смогут. Опытный программист с ИИ — это как грузчик с экзоскелетом — может гораздо больше унести. А вот опытный вайбкодер, собаку съевший на особенностях работы с ИИ? Он не знает ЯП двадцать лет. Зато рядом с ним сидит машина, которая умеет генерировать код, читать документацию, анализировать репозиторий, писать тесты, искать ошибки и выполнять десятки итераций за время, за которое человек успевает открыть документацию и сделать задумчивое лицо.
Поэтому родилась такая мысль: а кто сегодня быстрее и качественнее решит реальную инженерную задачу? Не — кто лучше пишет код. Не — кто умнее. Не — кто красивее оформляет GitHub. А кто за ограниченное время выдаст лучший работающий результат. Предлагаю устроить эксперимент.
Правила битвы
Никаких LeetCode, олимпиадных алгоритмов и задач уровня «перевернуть связный список». Это уже слишком хорошо изученная территория. Кроме того, способность быстро вспомнить алгоритм Дийкстры довольно слабо отвечает на вопрос, кто лучше разработает бизнес‑сервис. Нужна задача, похожая на настоящую работу.
Например, небольшое backend‑приложение на Python.
Оба участника получают:
одинаковое техническое задание;
одинаковое стартовое состояние репозитория;
одинаковое ограничение по времени;
одинаковый набор требований;
одинаковые критерии оценки.
Участник № 1
Python‑разработчик с 20 годами коммерческого опыта. Ему разрешены: поиск документации, поисковые системы, IDE без агентов, обычные инструменты разработки, к которым он привык. LLM и coding agents запрещены.
Участник № 2
Разработчик с двумя годами коммерческого опыта. Разрешены ChatGPT/Codex/DeepSeek и весь остальной зоопарк; coding agents; любая IDE; документация; обычные инструменты разработки.
То есть он может использовать LLM настолько активно, насколько умеет, это принципиально.
Что именно строим?
Например, сервис управления заказами.
Стек: Python; FastAPI;PostgreSQL; Docker Compose; pytest.
Минимальный API:
POST /orders GET /orders/{id} GET /orders POST /orders/{id}/pay POST /orders/{id}/cancel POST /orders/{id}/ship POST /orders/{id}/complete
У заказа есть состояние: new — > paid — > shipped → completed. Отдельно существует состояние: cancelled.
Недопустимые переходы должны отклоняться. На первый взгляд задача совершенно банальная и именно поэтому она подходит, так как банальность закончится примерно через десять минут.
Настоящая часть задания
Требования постепенно добавляют типичные производственные проблемы.
Идемпотентность: повторный запрос оплаты не должен создавать вторую операцию.Повтор того же запроса должен дать тот же результат, а не второй платёж.
Конкурентность: Нельзя получить неконсистентное состояние при получении одновременных POST с pay и cancel.
Транзакции — изменение состояния заказа и запись соответствующей операции должны быть атомарными.
Валидация ‑клиент не должен иметь возможности просто передать:{ «status»: “completed” } и перескочить через всю бизнес‑логику.
Фоновая задача: Неоплаченный заказ автоматически отменяется через заданный интервал.
После перезапуска приложения состояние не должно магическим образом забывать существующие заказы.
Список заказов должен нормально работать при большом количестве записей. При этом не обязательно устраивать соревнование по миллионам RPS, а остаточно не написать запрос, который на миллион строк начинает читать всю таблицу ради каждой страницы.
Но главное начинается после MVP
Если остановиться на работающем API, эксперимент получится не слишком интересным потому что современный coding agent может очень быстро создать вполне приличный CRUD.
Поэтому после завершения первой части участники получают второй этап.
Раунд 2. Скрытые тесты
Участники не знают полный набор проверок заранее. Например, тестировщик запускает два параллельных запроса оплаты.
Проверяется: не создаются ли две операции; корректно ли меняется состояние; что происходит при конфликте транзакций; не возникает ли race condition.
Другой тест повторяет один и тот же запрос десять раз. Следующий отправляет намеренно некорректные переходы состояний. Следующий убивает приложение в определённый момент выполнения операции. Следующий проверяет работу после восстановления. И, конечно, security‑тесты.
Например: SQL injection, mass assignment, неправильная обработка пользовательских данных, утечки секретов, отсутствие авторизации там, где она необходима. Здесь уже нельзя выиграть просто количеством сгенерированных строк.
Раунд 3. Изменение требований
После этого обоим участникам дают новую фичу.
Например добавить частичный возврат средств. Теперь заказ может быть возвращён полностью или частично. Нужно обеспечить: историю возвратов, невозможность вернуть больше оплаченной суммы, новые тесты и так далее в зависимости от степени извращенности судей:)
И снова ограничение времени. Вот здесь появляется ещё одна важная метрика:насколько дорого изменить уже написанную систему.
Потому что создать новый проект с нуля и изменить существующий production‑код через месяц эксплуатации это две совершенно разные профессии.
Что измерять?
Главная ошибка такого эксперимента заключается в попытке свести всё к одному показателю: «Первый закончил через 58 минут, второй через 83. Победил первый». Нет, нужен набор метрик.
Time to Working MVP — сколько времени прошло до момента, когда система действительно работает.
Functional correctness ‑сколько требований реально выполнено. Причём проверять это должны автоматические тесты.
Hidden defects — сколько ошибок обнаружилось после запуска скрытого набора тестов.
Security — потому, что способность получить рабочий результат и способность получить безопасный результат это разные навыки.
Читаемость. Например в баллах.
Change cost — сколько времени потребовалось на новую бизнес‑фичу. Это особенно интересно когда бизнес попросит «А давайте тут мааааленькую фичу добавим (которая традиционно станет большооой проблемой при ее внедрении по итогу)»
Как оценивать результат?
Я бы вообще не вводил единую субъективную оценку типа: 8 из 10. Лучше оценивтаь комплексно по каждой категории и подводить. итог
Что я ожидаю увидеть?
Именно здесь эксперимент становится интересным. Я не стал бы заранее утверждать, что двадцатилетний программист обязательно победит и не стал бы утверждать обратное. Моя гипотеза немного другая.
На первой итерации преимущество может оказаться у вайбкодера
Потому что огромный объём работы сегодня прекрасно автоматизируется. Человек с двумя годами опыта получает доступ к инструменту, который резко увеличивает его производительность. Причём не обязательно понимать каждую строку сгенерированного кода на момент её появления. Достаточно уметь: правильно сформулировать задачу, декомпозировать, проверить результат, обнаружить ошибку? заставить агента её исправить, самому принять финальное инженерное решение. Повторить n раз...
Но опыт никуда не исчезает
Есть классы задач, где 20 лет опыта могут оказаться гораздо важнее скорости генерации кода.
Например: сложный legacy, неочевидные race conditions, проблемы производительности, архитектурные ограничения, миграции, распределённые системы, production debugging, неявные бизнес‑правила, системы, где ошибка стоит дорого.
Там опытный разработчик может увидеть проблему ещё до того, как начинающий разработчик сформулировал вопрос для агента. LLM хорошо увеличивает скорость выполнения работы.
Но она не превращает автоматически человека с двумя годами опыта в человека с двадцатью годами опыта. Она позволяет этому человеку частично компенсировать недостаток опыта скоростью получения и проверки решений. Ключевое тут — частично.
Поэтому настоящий вопрос эксперимента другой
Не «Кто лучше программирует: человек или AI?» и не «Может ли новичок заменить сеньора с помощью AI?»Это слишком примитивные формулировки.
Интереснее спросить: «какой объём инженерного опыта сегодня способен компенсировать хорошо используемый LLM‑инструмент?» или «В какой момент дополнительный опыт человека снова начинает давать больше преимущества, чем дополнительная скорость генерации кода?»
Вот это уже можно измерять.
А что будет, если дать AI обоим?
Вот здесь эксперимент становится совсем неприятным. После первого исследования можно провести второй раунд. Тот же самый 20-летний разработчик получает тот же самый coding agent. И вот тут AI в таком случае не заменяет опыт а умножает его производительность. При условии что разработчик умеет им пользоваться.
Возможно, мы вообще неправильно сравниваем программистов
Раньше производительность разработчика во многом определялась способностью самостоятельно превратить задачу в код.
Сегодня появляется ещё один слой: Задача - Декомпозиция - Постановка задачи агенту - Генерация - Проверка - Тестирование - Ревью - Интеграция
И способность эффективно управлять этим циклом становится самостоятельным инженерным навыком. Поэтому через несколько лет вопрос: «Ты пишешь код сам или через AI?» может выглядеть примерно так же странно, как сегодня вопрос: «Ты считаешь в уме или пользуешься калькулятором?» Калькулятор не знает математику вместо человека. Но человек, который умеет пользоваться им правильно, объективно считает быстрее.
Вот такая философия в выходные. Вчера лень было писать, оформил статью сегодня. Понедельник — день тяжелый )
Всем добра!
