Разработчик под ником на Habr описал эксперимент: он попросил большую языковую модель собрать интерфейс для бронирования консультаций. Через десять минут получил работающее приложение на Next.js с поиском экспертов, страницей профиля, календарём слотов, формой брони, историей бронирований, админ-страницей, скелетонами, пустыми состояниями и тостами. Всё собралось с первого раза, ошибок типов не было. Руками на это ушло бы несколько дней, и то при готовом дизайне и описании бизнес-процессов.
Потом автор начал печатать в поле поиска. При вводе «мар», «марк», «марке» уходили три запроса. Ответы приходили в том порядке, в каком отвечал сервер, а не в том, в каком их отправляли. Если ответ на «мар» задерживался и приходил последним, он перезаписывал результаты для «марке». В поле — одно, в списке — другое. Это классическая гонка запросов, багу столько же лет, сколько хуку useEffect, и он описан в документации React отдельным разделом. Модель про него знает: на прямой вопрос «нет ли здесь гонки?» отвечает правильно и сразу. Но повода спросить себя об этом у неё не было — попросили поиск, поиск и сделали.
Рядом ещё одна проблема: setExperts вызывается после того, как пользователь ушёл со страницы. Отменять запросы никто не собирается, поэтому при быстром наборе в полёте висит по пять штук. Автор приводит альтернативный код на react-query, где гонки нет не потому, что её починили, а потому, что она стала невозможной: результат привязан к ключу запроса, а не к порядку ответов. И вот это — узнавать не конкретную ошибку, а место, где целый класс ошибок можно сделать ненаступаемым — автор считает главным навыком в работе с генерацией кода.
В поиске экспертов возникла классическая гонка запросов: ответ на «мар» приходил после «марке» и перезаписывал результаты.
Контекст: разговоры о замене разработчиков идут волнами. Сначала их должны были заменить визуальные конструкторы, потом no-code, потом low-code, потом автогенерация CRUD, потом Copilot. Теперь — большие языковые модели, которые за вечер выдают backend, frontend, Docker Compose, миграции, OpenAPI, Kafka, PostgreSQL, Redis, авторизацию, тесты и README. В соцсетях регулярно появляются истории про SaaS за двадцать минут и приложение, написанное нейросетью. Автор не спорит с тем, что ИИ хорошо пишет код. Он спорит с выводом, что профессия исчезнет.
Показательный момент: коллега автора после демонстрации сгенерированного приложения сказал «через год нас тут не будет». Автор не стал спорить, но задумался, где именно ломается эта логика. Код был написан неплохо, придраться к качеству не получалось. Тогда он взял похожую задачу и проверил на себе. Промпт был подробный: стек, структура папок, состояние сервера в react-query, формы на react-hook-form с zod, правила сборки компонентов. Модель справилась. Но стоило начать печатать в поиске, как проявилось то, чего в промпте не было.
Это не история про то, что ИИ тупой. Это история про границу между тем, что модель делает за разработчика, и тем, что остаётся на нём. Модель выполняет задание буквально: просишь поиск — получаешь поиск. Она не задаёт уточняющих вопросов о сценариях, которые не описаны, и не проверяет, не возникнет ли гонка при быстром вводе. Разработчик, по мнению автора, нужен именно на этом стыке — не чтобы писать код, а чтобы видеть места, где целые классы ошибок можно сделать ненаступаемыми по построению.

