Не замена разработчика, а новая роль

Разговоры об ИИ в программировании часто застревают между двумя крайностями: «разработчики скоро не нужны» и «ничего не изменилось». Эндрю Стеллман из O’Reilly предлагает смотреть спокойнее: ИИ-инструменты действительно меняют работу инженера, но не отменяют опыт, архитектурное мышление и проверку результата.

В статье The Accidental Orchestrator, которую Stack Overflow перепечатал из O’Reilly Radar, он описывает эксперимент с AI-driven development — подходом, где модели пишут код, а человек управляет процессом, ролями инструментов и качеством.

Коротко: разработчик всё чаще становится не только автором кода, но и оркестратором моделей, тестов, контекста и решений.

Что построили

Для эксперимента Стеллман создал Octobatch — Python-систему для пакетной оркестрации LLM-пайплайнов. По его описанию, проект вырос примерно до 21 тыс. строк Python-кода, почти 1000 автоматических тестов и набора спецификаций, интеграционных и регрессионных проверок.

Работа заняла около 75 часов активного времени в течение семи недель. Условия были жёсткие: весь код пишет ИИ, а человек не берёт на себя роль «ручного программиста», а управляет направлением и проверяет результат.

Это важный нюанс. Эксперимент не про «написал промпт и получил продукт». Скорее про то, как разбивать работу, выбирать модель под задачу, не терять контекст и замечать моменты, где уверенный ответ модели оказывается неверным.

Где понадобился человек

Самый показательный эпизод — симуляция Монте-Карло. В задаче про случайные шаги «пьяного матроса» результат оказался неправильным: вероятность падения в воду получилась 77,5% вместо ожидаемых 50%.

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

Стеллман отдельно отмечает ещё одну привычку моделей: они чаще предлагают добавить слой, обходной путь или заплатку, чем удалить лишнее. После простой команды «упрости» качество решений заметно улучшалось. Это хороший урок: иногда лучший промпт для ИИ — не «сделай больше», а «выкинь ненужное».

Оркестрация вместо вайб-кодинга

Автор отделяет AI-driven development от «vibe coding», где человек просто принимает то, что модель сгенерировала. Для небольшого прототипа такой стиль иногда работает. Для системы на десятки тысяч строк — быстро становится опасным.

По ходу проекта роли распределялись между инструментами: Claude использовался для реализации, Gemini — для проверки и поиска ошибок. Позже автор переключался на Cursor с теми же контекстными файлами, и подход продолжал работать. Это важная деталь: дело не только в конкретном вендоре, а в дисциплине работы с ИИ.

Контекст тоже становится частью проекта. Если модель не знает прежних решений, она будет снова и снова открывать уже пройденное. Поэтому заметки, спецификации, тесты и история обсуждений превращаются не в бюрократию, а в топливо для следующей AI-сессии.

Что это меняет

Главный вывод довольно трезвый: ИИ не снижает требования к разработчику автоматически. Он может ускорить реализацию, но отличить рабочий код от правдоподобного всё равно должен человек.

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

В этом смысле новая роль разработчика сложнее, чем кажется. Нужно понимать архитектуру, тестирование, статистику, стоимость API, поведение моделей и пределы автоматизации.

Итог

Статья Стеллмана ценна тем, что уводит разговор от лозунгов к практике. Вместо обещаний «ИИ всё сделает» там есть проект, ошибки, тесты, неверные симуляции и выводы, которые можно проверить. Самый отрезвляющий из них простой: AI-инструменты ускоряют производство кода, но не снимают с человека ответственность за смысл, архитектуру и проверку результата. Хороший разработчик в такой схеме не исчезает. Он становится человеком, который умеет поставить задачу, выбрать инструмент, увидеть неверную статистику, заставить систему упроститься и вовремя спросить: «А это вообще нужно?»

Источник: Stack Overflow Blog