Эксперимент: 20 лет опыта против двух лет и LLM-инструментов
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Автор предлагает провести сравнительный эксперимент, где опытный разработчик без ИИ соревнуется с новичком, активно использующим LLM-агентов. Цель — определить, какой объем инженерного опыта можно компенсировать скоростью генерации кода и в каких задачах человеческий опыт остается критическим.
Ценность: Материал предлагает методологию оценки реального влияния LLM на производительность разработчиков, выходя за рамки простых сравнений скорости написания кода. Это важно для понимания того, как меняется роль инженера и какие навыки остаются незаменимыми в условиях автоматизации.
В технологическом сообществе давно ведется спор о том, способен ли «вайбкодер» с искусственным интеллектом заменить опытного программиста. Автор материала предлагает уйти от абстрактных дискуссий и провести конкретный эксперимент, сравнивающий двух разработчиков на реальной инженерной задаче. Первый участник — специалист с 20-летним коммерческим опытом, которому запрещено использовать LLM и coding agents. Второй — разработчик с двумя годами опыта, имеющий полный доступ к ChatGPT, Codex, DeepSeek и другим ИИ-инструментам. Оба получают одинаковое техническое задание: создать backend-приложение на Python с использованием FastAPI, PostgreSQL и Docker Compose.
Задача заключается в реализации сервиса управления заказами с четкой логикой смены статусов (new, paid, shipped, completed, cancelled). На первый взгляд, это стандартный CRUD, но автор подчеркивает, что сложность начинается с требований к идемпотентности, конкурентности и транзакциям. Например, повторный запрос оплаты не должен создавать дубликат операции, а одновременные действия по оплате и отмене не должны приводить к неконсистентному состоянию базы данных. Также необходимо реализовать фоновые задачи для автоматической отмены неоплаченных заказов и обеспечить корректную работу при большом объеме данных.
Эксперимент состоит из трех раундов. Первый этап — создание работающего MVP. Второй раунд включает скрытые тесты, которые проверяют устойчивость системы к race conditions, SQL-инъекциям и другим уязвимостям безопасности. Третий раунд предполагает изменение требований: участникам нужно добавить функциональность частичного возврата средств. Этот этап позволяет измерить «стоимость изменения» кода, что является ключевым показателем качества архитектуры.
Автор утверждает, что на первой итерации преимущество может оказаться у новичка с ИИ, поскольку LLM-инструменты резко увеличивают скорость генерации и проверки кода. Однако опыт никуда не исчезает: в задачах, связанных со сложным legacy-кодом, распределенными системами и production debugging, 20 лет практики позволяют видеть проблемы до их возникновения. LLM компенсирует недостаток опыта скоростью, но не заменяет глубокое понимание систем.
Истинный вопрос эксперимента — не «кто лучше программирует», а то, какой объем инженерного опыта способен компенсировать хорошо используемый ИИ-инструмент. Автор также предлагает гипотезу о том, что если дать LLM обоим участникам, производительность опытного разработчика умножится, а не заменится. Это меняет парадигму оценки навыков: способность эффективно управлять циклом «задача — генерация — проверка» становится самостоятельным инженерным навыком.