В The New Stack вышла колонка Ankit Jain с тезисом, который еще год назад звучал бы как провокация, а теперь все больше похож на дорожную карту: каждая IT-компания постепенно становится компанией, которая строит инструменты для разработчиков. Как пишет The New Stack, логика проста: если значительную часть софта скоро будут собирать машины, то главный дефицит смещается от ручного набора кода к среде, где этот код можно задать, проверить и безопасно довести до продакшена. Для русскоязычных инженерных команд это важный сигнал: рынок начинает ценить не очередной AI-плагин, а качество внутренней платформы.
Jain, сооснователь и CEO Aviator, по сути описывает смену роли разработчика. Инженер здесь нужен не меньше, чем раньше, просто его работа все меньше похожа на непрерывную печать в IDE и все больше — на проектирование фабрики разработки: спецификаций, критериев приемки, правил доступа, тестовых контуров, журналов изменений и автоматической верификации. Иначе говоря, ценность уходит от вопроса «кто быстрее пишет фичу» к вопросу «кто лучше строит систему, в которой машины пишут фичу без лишнего мусора, с понятными ограничениями и проверяемым результатом».
Это не отдельный выпад в адрес классической разработки, а продолжение линии, которую Jain ведет весь 2026 год. В июньском материале он называл code review новым узким местом: ИИ генерирует код быстрее, чем человек способен его прочитать. В конце июня он предложил идею реестра AI-slop-ошибок и привел конкретный эксперимент: агент сгенерировал около 6000 строк кода, после чего второй агент сверил результат с 65 критериями спецификации за шесть минут; 60 пунктов прошли проверку, четыре провалились, один оказался частично выполнен. А в тексте от 19 июля Jain напоминал, что сам pull request как главный ритуал проверки не так уж стар: по его оценке, внутри Google системная практика ревью оформилась лишь около 2006 года. Сигнал прозрачный: меняется не только скорость написания кода, но и сама точка, где команда принимает инженерные решения.
Из этой логики и вырастает формула про то, что любая софтверная компания превращается в производителя собственных инженерных инструментов. Если основным исполнителем все чаще становится агент, продукту мало быть удобным для человека на экране. Ему нужно быть удобным и для машины: с понятными API, явными контрактами, предсказуемыми ошибками, хорошей документацией, правами доступа, аудитом действий и окружением, в котором можно надежно прогнать проверку. Отсюда меняется и язык product management: в центре уже не просто экран и пользовательский сценарий, а примитивы, которыми можно безопасно оперировать извне, источник истины для данных и ясное определение успешного результата. Для B2B-сервисов это особенно неприятная мысль. Если ваш продукт плохо разговаривает с агентом через API, webhooks, CLI или машинно-читаемую документацию, он начинает проигрывать не дизайном интерфейса, а качеством инженерного интерфейса. В такой картине инструменты для разработчиков перестают быть вспомогательной статьей расходов и становятся внутренним ядром бизнеса.
Для российского и вообще русскоязычного IT-рынка этот тезис неприятен именно своей практичностью. Он ломает удобную схему: купим еще один умный редактор, дадим команде доступ к кодогенерации, и производительность magically вырастет сама. Не вырастет, если ownership размыт, тестовые среды нестабильны, документация устаревает быстрее релизов, а CI/CD живет как отдельная республика. ИИ в таком случае не лечит хаос, а масштабирует его. Поэтому вместе с интересом к кодогенерации растет вес платформенной инженерии, DevEx, внутренних каталогов сервисов, policy-as-code и всего, что раньше считалось скучной инфраструктурной гигиеной. Важно и то, чего в тезисе Jain нет: речь не о том, что каждой компании придется срочно писать свой IDE, свой Git-hosting или свою модель. Речь о другом уровне мышления: банк, маркетплейс, логистический сервис или SaaS-вендор теперь вынуждены относиться к собственной платформе разработки как к продукту с живыми пользователями — разработчиками и агентами.
На уровне процессов это уже выглядит не как футурология, а как нормальная инженерная перестройка.
- Спецификация становится исходником. Хороший ticket, критерии приемки и ограничения важнее еще одной пары быстрых рук.
- Проверки выносятся из головы ревьюера в систему. Повторяющиеся замечания превращаются в правила, тесты, политики и автоматические валидаторы.
- Платформа начинает продавать скорость внутри компании. Кто быстрее и надежнее дает командам контекст, среду и проверку, тот и выигрывает по циклу поставки.
Рынок подталкивает туда же и без колонок. Anthropic недавно сообщила, что на май 2026 года более 80% кода, попадающего в ее основную кодовую базу, было написано Claude, а во втором квартале 2026-го типичный инженер там мержил в восемь раз больше кода в день, чем в 2024-м. Эти цифры не означают, что ручная разработка исчезает завтра. Зато они хорошо показывают, где теперь возникает дефицит: не в наборе символов, а в постановке задачи, качестве контекста, надежности проверок и праве последнего инженерного решения. Отсюда и кадровый сдвиг: выше ценятся не только сильные coding skills, но и люди, которые умеют формализовать намерение, собирать критерии приемки из разговора с бизнесом, строить guardrails и видеть, где автоматизацию надо ограничить. Проще говоря, спрос будет расти не только на модели, но и на инструменты для разработчиков, которые удерживают этот поток кода в рамках здравого смысла.
Поэтому главный вопрос для CTO, тимлида и продакта уже не в том, сколько строк команда напишет сама. Важнее другое: кто быстрее построит у себя маленькую фабрику разработки — с понятными спецификациями, надежной верификацией и интерфейсами, пригодными и для людей, и для агентов. Если этот сдвиг закрепится, спор о том, заменит ли ИИ программиста, быстро станет второстепенным. Гораздо важнее окажется, какая компания сумела первой превратить собственную инженерную кухню в масштабируемый продукт.