Разработка логотипа с помощью нейросети ни при чём: джун с ИИ против сеньора в битве за код

Канал «Вайбкодер» предложил эксперимент, который наконец переводит спор «ИИ против опытного разработчика» из плоскости мнений в плоскость измеримых результатов, и 3 июня 2025 года опубликовал полный протокол такой битвы с правилами, раундами и метриками.

Споры о том, заменят ли нейросети программистов, стали фоновым шумом индустрии. Автор эксперимента из канала «Вайбкодер» решил перевести разговор в формат, где есть условия, таймер и объективные критерии. Задача намеренно приближена к реальному продакшену: не олимпиадный алгоритм, а бэкенд-сервис с бизнес-логикой, конкурентностью и требованиями безопасности.

Кто участвует и на каких условиях?

Два участника получают одинаковое техническое задание, одинаковый репозиторий и одинаковое время.

• Участник 1: Python-разработчик с 20 годами коммерческого опыта. Ему доступны документация, поисковики, IDE без агентов. LLM (большие языковые модели, те самые нейросети, которые генерируют текст и код) и ИИ-агенты (программы, способные самостоятельно выполнять цепочки действий: писать код, запускать тесты, исправлять ошибки) запрещены.
• Участник 2: разработчик с двумя годами опыта. Разрешено всё: ChatGPT, Codex, DeepSeek, любые ИИ-агенты, любая IDE. Он может использовать нейросети настолько активно, насколько умеет.

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

Что именно строят?

Сервис управления заказами. Стек: Python, FastAPI, PostgreSQL, Docker Compose, pytest.

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

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

• Идемпотентность (защита от дублей): повторный запрос оплаты не должен создавать вторую операцию
• Конкурентность: одновременные запросы «оплатить» и «отменить» не должны привести к противоречивому состоянию
• Атомарные транзакции: изменение статуса и запись операции происходят вместе или не происходят вовсе
• Валидация: клиент не может просто передать «статус: завершён» и перескочить бизнес-логику
• Фоновая задача: неоплаченный заказ автоматически отменяется через заданный интервал
• Устойчивость: после перезапуска приложение помнит все заказы
• Пагинация (постраничный вывод): список заказов работает и на миллионе записей без чтения всей таблицы

Три раунда, которые отделяют прототип от продукта

Если остановиться на работающем API, эксперимент окажется неинтересным: современный ИИ-агент способен быстро сгенерировать приличный CRUD (набор базовых операций «создать, прочитать, обновить, удалить»). Поэтому после MVP участников ждут два дополнительных раунда.

Раунд 2. Скрытые тесты. Участники не знают полный набор проверок заранее. Тестировщик запускает два параллельных запроса оплаты, повторяет один запрос десять раз, отправляет некорректные переходы состояний, убивает приложение в момент операции и проверяет восстановление. Отдельно идут тесты безопасности: SQL-инъекции (атака, когда злоумышленник подсовывает команду базе данных через поле ввода), mass assignment (подмена полей, которые не должны меняться извне), утечки секретов, отсутствие авторизации.

Раунд 3. Изменение требований. Обоим дают новую функцию: частичный возврат средств. Нужна история возвратов, проверка, что нельзя вернуть больше оплаченного, и новые тесты. Снова ограничение по времени.

Создать проект с нуля и изменить существующий продакшен-код через время эксплуатации, как отмечает автор, это две разные профессии.

Шесть метрик вместо одного секундомера

Автор эксперимента прямо предупреждает: главная ошибка подобных сравнений в попытке свести всё к одному показателю. Вместо этого предлагается набор:

1. Time to Working MVP: сколько времени до момента, когда система действительно работает
2. Functional correctness: сколько требований выполнено, проверка автоматическими тестами
3. Hidden defects: сколько ошибок нашлось после запуска скрытого набора тестов
4. Security: безопасный результат и работающий результат это разные навыки
5. Читаемость: оценка в баллах
6. Change cost: сколько времени потребовалось на новую бизнес-функцию

Что делать с этим прямо сейчас?

Автору Дзена и копирайтеру. Этот формат эксперимента можно повторить для своей ниши. Возьмите типовую задачу, например, разработка логотипа с помощью нейросети: дайте одинаковое задание дизайнеру и человеку с Midjourney, измерьте время, качество, стоимость правок. Такой контент собирает вовлечение, потому что снимает абстрактный спор конкретным результатом.

Маркетологу. Если вы нанимаете разработчиков или заказываете разработку, этот протокол можно использовать как шаблон тестового задания. Он покажет не только скорость, но и качество кода, устойчивость к нагрузке и способность менять продукт.

Предпринимателю в РФ. Все перечисленные инструменты (ChatGPT, DeepSeek, Codex) доступны через VPN или напрямую. Из российских аналогов для генерации кода можно попробовать GigaCode от Сбера. Но главное в эксперименте не конкретные инструменты, а методология: если вы решаете, нужен ли штатный сеньор-разработчик или достаточно джуниора с ИИ, проведите такой тест на своей задаче.

Ты senior Python-разработчик. Вот ТЗ на сервис заказов.
Сгенерируй структуру проекта: модели SQLAlchemy,
роутеры FastAPI, конечный автомат состояний заказа,
Dockerfile и docker-compose.yml.
Требования: идемпотентность оплаты, атомарные транзакции,
пагинация курсором.

Формат эксперимента ценнее любого его исхода: шесть метрик вместо секундомера, три раунда вместо одного, реальная бизнес-задача вместо олимпиадной головоломки. Кто бы ни победил, выиграет тот, кто первым проведёт такой тест на своём проекте и опубликует честные данные.