Команда AI for Devs подготовила перевод статьи о том, как быстро растущие AI-ассистенты меняют саму природу разработки. Их код выглядит безупречно — но всё чаще решает не ту задачу, что стоит перед нами. Где проходит граница между ускорением и самообманом, и какую новую ответственность это накладывает на инженеров?


В начале 1950-х Грейс Хоппер ввела термин «компилятор» и создала одну из первых его версий — систему A-01. Появившиеся позже компиляторы скрывали машинный код и позволяли программистам сосредоточиться на более высокоуровневой логике, а не на низкоуровневых деталях железа. Сегодня AI-ассистенты для программирования2 запускают похожую трансформацию: они позволяют инженерам сосредоточиться на задачах более высокого порядка, генерируя код из запросов на естественном языке. И большие технологические компании, и хорошо финансируемые стартапы сейчас борются за то, чтобы занять место в этой новой волне. Вчера Google анонсировала Antigravity — своего нового AI-ассистента для кодинга, а позавчера AWS объявила о доступности своего инструмента Kiro. На прошлой неделе Cursor, самый яркий стартап в этой области, привлёк $2,3 млрд в раунде серии D при оценке в $29,3 млрд.

В пресс-релизе Cursor мне бросились в глаза две строки. Первая:

Мы также перешли отметку в $1 млрд годовой выручки в пересчёте на год, обслуживая миллионы разработчиков.

Этот факт означает, что Anysphere Inc. (материнская компания Cursor) стала самой быстрой компанией в истории, достигшей $1 млрд годовой регулярной выручки (ARR). Да, быстрее, чем OpenAI, и быстрее, чем Anthropic3.

 Источник: Ючэн Цзин, Twitter/X, 2025
Источник: Ючэн Цзин, Twitter/X, 2025

Инженеры пробуют каждый новый AI-инструмент для написания кода. В результате рынок AI-инструментов для разработки растёт экспоненциально (в 5 раз всего за год с небольшим). Но это всё ещё ранняя стадия. Как я писал в Why Some AI Wrappers Build Billion-dollar Businesses, компании тратят сотни миллиардов долларов в год на разработку ПО, и AI способен дать прирост производительности на всём этом объёме.

У пяти крупнейших компаний мира по рыночной капитализации — а это все технологические компании, по состоянию на октябрь 2025 года — разработчики составляют примерно 30% сотрудников. Инструменты для разработки, которые повышают продуктивность даже на несколько процентов, создают ценность в миллиарды долларов.

На мой взгляд, зарождающийся рынок начинает делиться по трём типам пользователей.

 Источник: Command Lines, wreflection.com, 2025
Источник: Command Lines, wreflection.com, 2025

С одной стороны — ручное кодирование (Handcrafted Coding). Это инженеры, которые принципиально отказываются использовать LLM — либо из-за скепсиса к качеству, либо из-за желания полностью контролировать каждый кусочек кода. Они утверждают, что принятие AI-подсказок создаёт технический долг, который вы не увидите, пока всё не сломается в продакшене. Этот сегмент постепенно сокращается по мере того, как качество AI-моделей для кодинга растёт.

На противоположном конце — Vibe Coding. Это обычно не инженеры, которые используют AI, чтобы создавать концепции и прототипы. Они дают модели запрос, рассчитывая на полностью готовое решение, принимают результат практически без ревизии и верят, что оно работает. Пользователь описывает, чего хочет, а модель сама разбирается с реализацией.

Посередине — архитектор + AI-кодинг (Architect + AI Coding). Инженер использует AI/LLM как напарника: исследует архитектурные решения, анализирует модели данных, просматривает детали API. Если задача новая или требует аккуратной ручной работы, программист по-прежнему пишет эти части самостоятельно. Но всё шаблонное — boilerplate, установки пакетов, типовые UI-компоненты и любой код, который легко найти в интернете, — они поручают модели4. Инженер сохраняет контроль над важным и делегирует всё второстепенное.

Разделение рынка

Опираясь на типы пользователей, я считаю, что рынок AI-инструментов для написания кода делится на два направления.

 Источник: wreflection.com по оценке SemiAnalysis, 2025
Источник: wreflection.com по оценке SemiAnalysis, 2025
  1. Hands-off. Не инженеры (продакт-менеджеры, дизайнеры, маркетологи, сотрудники внутренних команд) используют такие инструменты, чтобы «vibe-кодить» ранние продуктовые концепции. Они смотрят на AI как на ведущего инженера, который по их запросу собирает концепты и прототипы приложений, сайтов и инструментов. Сюда подходят Lovable, Vercel, Bolt, Figma Make и Replit5. Код таких пользователей, по крайней мере сейчас, обычно не попадает в прод.

  2. Hands-on. Профессиональные инженеры используют эти инструменты в существующем рабочем процессе, чтобы выпускать продакшен-код. Они используют AI как ассистента: писать boilerplate, рефакторить существующие сервисы, связывать новые функции или UI-экраны, разбирать баги в кодовой базе. В эту категорию попадают Cursor, Claude Code, OpenAI Codex, GitHub Copilot, Cline, AWS Kiro. Эти продукты находятся там, где происходит работа, и вписываются в привычный рабочий процесс инженера. И это, по крайней мере сейчас, более крупный сегмент рынка.

Чтобы посмотреть оценку всех основных AI-инструментов для кодинга на рынке, загляните в обзор Питера Янга, автора рассылки Behind The Craft.

И это подводит меня ко второй строке из пресс-релиза Cursor, которая мне запомнилась:

Наши собственные модели теперь генерируют больше кода, чем почти любые другие LLM в мире.

Хотя я и не убеждён в этом утверждении6, но убеждён в другом: Cursor продолжает расти, несмотря на прежнюю зависимость от базовых моделей. Из Why Some AI Wrappers Build Billion-dollar Businesses:

Но Cursor и другие подобные инструменты почти полностью зависят от доступа к моделям Anthropic, OpenAI и Gemini до тех пор, пока Open source модели с открытыми весами и внутренние модели не сравняются с передовыми по качеству или не превзойдут их. На форумах разработчиков полно жалоб на ограничения по скорости у платящих подписчиков. В моих собственных проектах я исчерпал кредиты Claude в Cursor в середине работы и, несмотря на предпочитаемый мной интерфейс и дизайн Cursor, мигрировал в Claude Code (и теперь плачу в десять раз больше, чтобы избежать лимитов). Интерфейс может быть лучше, но доступ к модели решает всё.

Новая внутренняя модель Cursor — Composer-2, которая вышла только в прошлом месяце, — хороший пример того, как развивается конкуренция «модель против приложения». Cursor утверждает (хотя, замечу, без внешних бенчмарков), что Composer-2 почти так же хороша, как frontier-модели, но при этом в 4 раза быстрее. Пока рано говорить, насколько это верно. Open source модели пока не приблизились к лидерам ни в SWE-bench verified, ни в приватных оценках7.

 Источник: Introducing Claude Sonnet 4.5, Anthropic, 2025.
Источник: Introducing Claude Sonnet 4.5, Anthropic, 2025.

Для меня качество модели — решающий фактор в этих AI-войнах за кодинг. И, на мой взгляд, именно поэтому Claude Code уже обошёл Cursor, а OpenAI Codex идёт почти следом, несмотря на то, что оба появились примерно на год позже.

 Источник: SemiAnalysis, 2025
Источник: SemiAnalysis, 2025

Несмотря на то что новички вроде Cursor, Claude Code и OpenAI Codex сегодня на слуху в мире разработчиков, крупные игроки — Microsoft с Github Copilot, AWS с Kiro и Google с Antigravity — могут использовать свои устоявшиеся отношения с клиентами, включать новые продукты в существующие пакеты и/или просто делать их параметром по умолчанию в своём технологическом стеке. Например, Cursor берёт с пользователей $20–$40 в месяц за продуктивное использование, тогда как Google Antigravity вышел сразу бесплатно и с щедрыми лимитами для индивидуальных пользователей. Github Copilot по-прежнему лидирует на этом рынке, что снова подтверждает: корпоративные пакеты и широкое распространение дают структурные преимущества. Это классическая динамика Microsoft Teams против Slack8.

Один из способов для стартапов конкурировать — завоевать отдельных пользователей, которые могут начать пользоваться инструментом для кодинга с одобрением компании или без него, а затем стать его евангелистами внутри организации. Такой органичный интерес и рост аудитории в итоге вынуждают команды IT и безопасности официально рассмотреть инструмент и со временем дать разрешение на его использование.

Но даже по мере того, как новые инструменты всё активнее занимают место в умах разработчиков, сам рынок инструментов для разработчиков меняется. И IDE, которые выбирают программисты, и источники, к которым они обращаются, претерпели резкий сдвиг. StackOverflow, который когда-то был местом по умолчанию для программистов, застрявших на задаче, столкнулся с резким падением трафика и числа вопросов после запуска ChatGPT — и это говорит о том, что ИИ уже заменяет часть привычных ресурсов для разработчиков.

 Источник: Developer Tools 2.0, Sequoia, 2023
Источник: Developer Tools 2.0, Sequoia, 2023

Точно так же, как компиляторы когда-то освободили программистов от необходимости писать на ассемблере, инструменты на базе ИИ освобождают разработчиков от рутины — написания шаблонного и однообразного кода — и позволяют сосредоточиться на задачах более высокого уровня. В какой-то момент ИИ может стать настолько хорош, что будет генерировать приложения по запросу и самостоятельно создавать целые программные экосистемы. И инструменты ИИ, работающие «вручную» или «автопилотом», и крупные игроки, и новички видят себя дорогой к этой полностью автономной генерации софта, пусть и идут они к цели разными путями. Победителями станут те, кто сможет обеспечить высочайшее качество модели, стабильно выдающей работающий код, глубоко проработать возможности, которые базовые модели просто не в состоянии достаточно точно воспроизвести, и стать настолько незаменимыми, что пользователи не уйдут, даже когда смогут.

Русскоязычное сообщество про AI в разработке

Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!

Комментарии (1)


  1. nikulin_krd
    29.11.2025 09:28

    Их код выглядит безупречно — но всё чаще решает не ту задачу, что стоит перед нами.

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