Серия колонок сооснователя Aviator Анкита Джайна в The New Stack сводится к неприятному для многих выводу: с приходом ИИ выигрывает не команда, которая просто купила ещё один генератор кода, а та, что превратила собственную платформу разработки в продукт. Для русскоязычных инженерных команд это практичный сигнал: узкое место уходит от набора кода к спецификациям, проверкам и среде, через которую изменения доходят до релиза.
Тезис вырос из серии материалов, а не из одного анонса
Здесь важна точность. Речь не об одной колонке с громким лозунгом, а о серии текстов Джайна в The New Stack от 9 июня, 26 июня, 7 июля и 19 июля 2026 года. Во всех он повторяет одну и ту же мысль: ИИ ускорил написание кода, но не убрал хаос вокруг кода. Поэтому центр тяжести смещается вверх по процессу — к формулировке задачи, ограничениям, критериям приёмки и автоматической проверке.
Есть и полезный дисклеймер. Джайн — не внешний аналитик, а сооснователь Aviator, а его публикации в The New Stack выходят как спонсорские авторские материалы. Это не отменяет аргументы, но объясняет угол зрения: автор продвигает не очередную модель, а инфраструктуру вокруг разработки.
Проверка кода дорожает быстрее, чем его написание
Самый показательный пример Джайн привёл в тексте от 26 июня. Команда сначала подробно описала задачу и критерии приёмки, затем отдала реализацию агенту. На выходе получилось около 6 тыс. строк кода, а второй агент сверил результат с 65 пунктами спецификации за шесть минут: 60 пунктов прошли, четыре провалились, один выполнился частично. Сам Джайн формулирует вывод жёстко: «Вы уже не просто пишете ПО, вы строите машину, которая пишет ПО».
Отсюда и главный практический вывод. Если требования размыты, тестовые контуры нестабильны, права доступа описаны кое-как, а документация устаревает быстрее релизов, ИИ не лечит систему, а размножает её дефекты с промышленной скоростью. Поэтому классический запрос на слияние кода, который человек читает постфактум, начинает проигрывать проверке намерения до начала реализации.
Anthropic показал, как быстро смещается дефицит
Эта логика неплохо бьётся с данными Anthropic Institute. В материале от 6 августа 2026 года компания пишет, что к маю 2026-го более 80% кода, который попадает в её основную кодовую базу, написал Claude. Во втором квартале 2026 года типичный инженер добавлял в основную кодовую базу в восемь раз больше строк кода в день, чем в 2024-м. Anthropic отдельно оговаривает, что строки кода — плохая мера качества, и это важная оговорка без лишнего хайпа. Но сама тенденция ясна: дефицит возникает уже не в скорости печати, а в качестве постановки задачи, контексте и надёжности проверок.
Для рынка России и СНГ это история про внутреннюю платформу
Практический смысл этой истории не в том, что банку, маркетплейсу или SaaS-вендору срочно понадобятся своя IDE, свой Git-хостинг или собственная модель. Речь о более приземлённой вещи: выигрывать будут те, кто оформит спецификации, сервисные каталоги, тестовые среды, машинно-читаемую документацию, API, CLI и автоматические проверки в единый продукт для разработчиков и агентов.
Если же у продукта слабый API, много ручных согласований и критичные знания живут «в головах», ИИ станет не ускорителем, а дорогим усилителем беспорядка. Поэтому платформенная инженерия и удобство разработки из вспомогательной статьи расходов быстро превращаются в часть бизнес-модели.
Следующий этап выглядит довольно прозаично: компании будут меньше спорить о том, заменит ли ИИ программиста, и больше вкладываться в среду, где люди и агенты могут выпускать изменения без лотереи.
Исходные материалы: , , , , .