Эпоха «работающего» ИИ подходит к концу

Демки впечатляют. Бенчмарки радуют цифрами. Но давайте честно: индустрия начинает понимать, что функциональность — это только начало разговора.

От «запускается ли?» к «стоит ли брать?»

Представьте себя мейнтейнером. Когда вы смотрите на pull request, корректность — это не достижение, а ожидание по умолчанию. Вам нужна чистота, понятность, аккуратные границы изменений. Вам нужно, чтобы код не заставлял следующего разработчика усомниться в выборе профессии.

И вот тут начинается самое интересное. Появляются новые фреймворки оценки, которые измеряют совсем другое: пропустил бы опытный разработчик этот код в продакшн? Не «работает ли оно», а «хочу ли я это в своём репозитории».

Почему старые бенчмарки не дотягивают

Смотрите на любой рейтинг моделей — и увидите картинку идеального мира. Чистые задачи, чёткие решения. А теперь откройте реальный проект с историей. Там есть legacy-костыли, негласные соглашения, архитектурные решения, которые объяснимы только после трёх лет погружения в код.

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

Ставим планку выше — и это правильно

Дело не в скептицизме. Наоборот. Когда мы требуем большего от ИИ, мы признаём прогресс. Мы говорим: «Окей, кодить умеешь. Теперь покажи, что умеешь кодить хорошо».

Для разработчиков и стартапов это не абстрактная философия. Модель, которая генерирует синтаксически верный Python, но игнорирует ваш style guide — это не ускорение работы. Это фабрика технического долга в чистом виде. Понимание разницы между «выглядит правильно» и «реально полезно» напрямую влияет на скорость разработки и время code review.

Что дальше

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

Модели будущего победят не размером нейросети. Победят те, чей код мейнтейнеры будут рады видеть в своей кодовой базе.