Apple только что сделала то, чего мир искусственного интеллекта совсем не ожидал. Она выкинула AI-приложения для «вайб-кодинга» из App Store — по сути заявив: мы не доверяем тому, что эти инструменты нагенерировали.

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

Я перелопатила несколько авторитетных отчётов о трендах в софтверной индустрии, аудитов безопасности и академических исследований, чтобы понять, что на самом деле происходит, когда AI-код встречается с реальным миром.

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

А ведь рынок акций прямо сейчас закладывает в цены ровно противоположное.

Но сначала — что именно сделала Apple и какую деталь большинство публикаций упустили.


Apple и драма с вайб-кодингом

Два события произошли практически одно за другим.

В течение нескольких недель в марте 2026 года Apple тихо заблокировала обновления для Replit и других платформ для вайб-кодинга, а приложение Anything и вовсе полностью удалила из App Store, сославшись на Руководство 2.5.2.

Это давнишнее правило Apple: приложения не могут скачивать, устанавливать или выполнять код, который меняет их функциональность после прохождения ревью.

Некоторые из этих приложений были восстановлены только к 3 апреля.

Глава Epic Games назвал это «удушением инноваций».

Многие новостные издания, включая CNBC и The Information, заявили, что Apple оказалась «не на той стороне истории». Разумеется, компания Anything, чьё приложение удалили, заявила, что «удивлена и разочарована».

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

А теперь — обратная сторона медали, которую критики со своим лозунгом «анти-инновации» удобно забывают упомянуть.

Количество заявок в App Store выросло на 84% в первом квартале 2026 года по сравнению с прошлым годом — это крупнейший скачок за десятилетие.

А Apple и до этого отклоняла почти 2 миллиона заявок только за 2024 год.

Давайте переведём на понятный язык.

Приложения вроде Facebook или Pokémon — это как рестораны, которые прошли санитарную проверку. Меню регулярно обновляется — новые блюда, сезонные предложения (точно как посты в ленте или игровой контент). Но! Кухня — та же самая кухня, которую инспектор одобрил.

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

Приложение, прошедшее ревью Apple, — это не то же приложение, которое в итоге запускают пользователи.

Именно для предотвращения этого и существует Руководство 2.5.2.

Оно не новое. Просто теперь оно внезапно стало намного актуальнее.

Если бы Apple была «анти-ИИ», она бы не добавила AI-инструменты для кодинга от Anthropic и OpenAI прямо в Xcode — свою собственную платформу для разработчиков — всего два месяца назад.

А теперь давайте разберёмся, была ли Apple права.

Потому что это целиком и полностью зависит от того, как AI-сгенерированный код работает в живой системе. И вот тут данные становятся убийственными для лагеря «ИИ убьёт SaaS».


Кстати, об инструментах. Если вам нужен доступ ко всем ключевым моделям — Claude, GPT, Gemini — загляните на BotHub.

Для доступа не требуется VPN, можно использовать российскую карту.

По ссылке вы можете получить 300 000 бесплатных токенов  для первых задач и приступить к работе с нейросетями прямо сейчас!


Разбираем, как на самом деле строится софт

Вот что случилось, когда AI-инструмент для кодинга оставили без присмотра.

Один основатель стартапа использовал AI-агента Replit для разработки своего приложения. Во время code freeze — то есть периода, когда никакие изменения вноситься не должны, — ИИ решил «починить» то, о чём его никто не просил. Он удалил целую продакшн-базу данных — более 1200 записей о руководителях — и полностью парализовал приложение.

Это как если бы вы вызвали сантехника починить капающий кран. А вернувшись, обнаружили, что он снёс несущую стену, пока вы спали.

Случай с Replit задаёт контекст для данных, которые я сейчас покажу.

Способность ИИ писать код — это опасное отвлечение. Да, это единственное, что он бесспорно делает быстрее людей. Но если весь остальной процесс сломан, эта скорость лишь ускоряет разрушение.


Этап 1: Написание кода. ИИ быстр. Жаль, что скорость ≠ качество

Представьте софт как строительство дома. Да, ИИ может возводить стены невероятно быстро. Я не собираюсь это оспаривать.

Но ведь для дома нужно кое-что помимо стен, не так ли?

И это тот самый заголовок, который вы слышите повсюду: «ИИ пишет код быстрее, значит, инженеры больше не нужны, он заменит разработчиков, и каждая компания сможет сама написать собственные SaaS-инструменты».

Такое может утверждать только тот, кто никогда не работал в софтверной разработке. А заодно нужно ещё и проигнорировать вообще всё остальное в процессе создания продукта.

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

METR — известная некоммерческая организация, отслеживающая прогресс ИИ, — привлекла опытных разработчиков для выполнения ряда задач. Вот как был устроен их эксперимент.

Когда разработчиков спросили после эксперимента, те были уверены, что работали на 20% быстрее.

Реальность? Разработчики, использовавшие ИИ, на 19% медленнее тех, кто писал код вручную.

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

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

Как редактировать чужое эссе вместо того, чтобы начинать с чистого листа. Многие из нас незаметно для себя обменяли скорость на комфорт — и даже не заметили подмены.

А дальше — ещё хуже.

Команда специалистов по безопасности просканировала более 5000 живых приложений, созданных с помощью AI-инструментов для кодинга.

Они обнаружили более 2000 критических уязвимостей400 приложений открыто хранили пароли и ключи безопасности (например, API-ключи), доступные буквально каждому. Не говоря уже о том, что персональные данные — медицинские карты, номера банковских счетов — были доступны любому, кто удосужился заглянуть.

Не страшно, если цифры сами по себе вам мало говорят. Важно вот что: 60% приложений были уязвимы.

Это примерно как если бы у вас не было замков на окнах, ключи висели на гвоздике у входной двери, на холодильнике — стикер с логином и паролем от банка, а вы при этом кричали на всю улицу о своём диагнозе.


Этап 2: Проверка. Две трети вайб-кодинг-приложений проваливают инспекцию

Прежде чем любой код попадёт в продакшн, его нужно проверить.

Опять же — как любую инспекцию. И результаты для AI-кода удручающие.

Как чат-бот, который лепит абзац за абзацем, когда вы просили ответить «да» или «нет», AI-ассистенты для кодинга выдают почти в три раза больше кода, чем написал бы человек. Но большая часть этого — низкокачественная шелуха.

Крупнейшее исследование AI-сгенерированного кода за 2026 год выявило целый ряд закономерностей. Только около трети AI-кода проходит первичную проверку, тогда как код, написанный людьми, проходит инспекцию более чем в 80% случаев.

Давайте представим стройку: два из трёх домов, построенных новым методом, не прошли приёмку. Вы бы не назвали это «революцией в строительстве». Вы бы назвали это катастрофой.

И это ещё не всё: сама проверка занимает больше времени. Рецензентам требуется в 5 раз больше времени на проверку AI-кода.

В итоге они тратят на проверку больше времени, чем раньше уходило на написание самого кода.

ИИ не сократил объём работы. Он его увеличил!


Этап 3: Дистрибуция. У вашего покупателя есть вопросы, на которые ИИ не ответит

Если бы мы строили дома, этапы 1 и 2 происходят на стройплощадке.

Но в какой-то момент нужно продать то, что построили. А у покупателей — свой собственный процесс проверки.

Каждая компания, покупающая софт — будь то стартап на 50 человек или компания из Fortune 500 — проходит через закупочную процедуру (procurement). И чем крупнее компания, тем жёстче вопросы. Безопасно ли это? Действительно ли решает бизнес-задачу? Как будет осуществляться поддержка? Как доставляются обновления? Какой штраф, если софт не работает как указано в спецификации?

Это далеко не «хотелки». Многие из этих пунктов — строгие критерии «прошёл / не прошёл».

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

Когда я сама оценивала операционный софт, вопрос, который хоронил больше всего презентаций вендоров, был не про цену и не про фичи. Он звучал так: «Покажите вашу систему безопасности, покажите архитектуру, объясните, как ваша команда это поддерживает, и какие метрики мы можем отслеживать».

У продукта, созданного вайб-кодингом, нет хороших ответов ни на один из этих вопросов.

Я понимаю — обычно вы не слышите об этих отказах в новостях. Потому что они происходят в переговорных комнатах, и они скучные, не тянут на заголовок.

Но наконец-то это попало в заголовки. Потому что Apple проводит тот же процесс, только в потребительском масштабе.

Да, Apple управляет App Store. Но в контексте этой темы правильнее думать об этом как о курировании приложений — примерно как новостное издание или Netflix курирует свой контент. Когда вредоносное приложение проскакивает, виноват не только разработчик. Особенно когда приложение причиняет вред, сливает персональные данные или показывает детям то, что им скачивать не положено.

Ответственность лежит на платформе, которая это одобрила, не меньше, чем на разработчике.

Вот зачем существует Руководство 2.5.2. И когда заявки в App Store подскочили на 84% за первый квартал 2026 года — почти целиком за счёт AI-сгенерированных приложений — разумеется, Apple их заблокировала.

Мне вот интересно: те журналисты и CEO, которые выступают против этой блокировки, — они возьмут на себя ответственность, когда вредоносное приложение выйдет в свет и его скачают дети?


Этап 4: Поддержка — гасим кредитку кредиткой

Но допустим, вам удалось пройти через ворота. Допустим, вайб-кодинг-продукт каким-то чудом прошёл закупочную процедуру и ревью Apple.

Что дальше?

Google ежегодно опрашивает тысячи софтверных специалистов, чтобы понять, как реально работают команды разработки. В отчёте за 2024 год они обнаружили: каждое увеличение внедрения AI-инструментов на 25% ассоциировалось с падением стабильности доставки на 7,2%.

В 2025 году — те же выводы, если не хуже.

И в кластере базовых проблем, и в узком горлышке унаследованных систем наблюдаются всплески нестабильности софтверной доставки.

Простым языком: чем больше кода генерирует команда, тем хуже стабильность софта. Вот что они написали:

«…Наши данные показывают, что внедрение ИИ не только не устраняет нестабильность — оно в настоящее время ассоциируется с её ростом…

При этом нестабильность по-прежнему оказывает значительное негативное влияние на ключевые показатели — такие как производительность продукта и выгорание сотрудников, — что в конечном счёте может свести на нет любые кажущиеся преимущества в скорости разработки».

Нет недостатка в новостях и консультантах, цитирующих «55% рост продуктивности» от GitHub или «вдвое быстрее» от McKinsey.

Однако многие из этих данных получены в контролируемых экспериментах и изолированных задачах, а не в живых системах. Когда MIT Sloan Management Review опросил CIO из разных отраслей, они обнаружили совсем другое: AI-сгенерированный код, масштабированный в реальные системы, создаёт нарастающий технический долг, который дестабилизирует всю конструкцию.

Перевод: AI-код — это как гасить кредитку другой кредиткой.


Аргумент «Но ведь ИИ становится лучше!»

Тут вы можете сказать:

«Ладно, у нынешних инструментов проблемы. Но ведь ИИ совершенствуется, разве нет?»

И ответ: да, в одном измерении. Но не в тех, которые реально имеют значение.

ИИ научился писать код, который не падает сразу. Свежий софтверный отчёт показал, что ИИ отлично справляется с написанием кода, который запускается без ошибок.

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

Показатели прохождения проверок безопасности составляли 55% в 2023 году. И всё ещё 55% весной 2026-го. Ноль, на месте. Три года «революционных» релизов моделей не сдвинули стрелку безопасности ни на один пункт.

Это как если бы ИИ в 2026 году заучил, как дома выглядят на бумаге, но ни разу в них не жил.

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

Пока эти модели не перестанут угадывать, как код должен выглядеть, и не начнут понимать, что он делает, — ситуация не улучшится.

Те, кто строит эти модели, это знают.

Вопрос в другом: как скоро реальность догонит компании, которые поспешили выпустить AI-сгенерированный код?


Что это значит для SaaS?

(Что думаете? Напишите в комментариях, прежде чем читать дальше!)

Логика за аргументом «ИИ убьёт SaaS» выглядит так:

  1. ИИ делает код бесплатным и быстрым.

  2. Кто угодно может создать софт.

  3. Существующие софтверные компании теряют преимущество.

  4. SaaS мёртв.

Каждое звено этой цепочки ломается, если вы хоть раз участвовали в разработке софта — или если вы копнули в отчёты, которые написаны не консалтинговыми компаниями и не самими разработчиками моделей.

Написание кода всегда было самой дешёвой частью создания софта.

Всегда.

Дорого стоит сделать правильно.

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

Да, за последние три года ИИ сделал дешёвую часть ещё дешевле.

Однако, как показывает каждый приведённый нами факт, он катастрофически провалился во всём дорогом. Более того — он сделал это ещё дороже: больше кода для проверки, больше уязвимостей для устранения, больше нестабильности для управления. И — жёстче выгорание разработчиков.

Apple — первый заметный привратник, который сказал: «Я не беру на себя этот риск. Я это блокирую».

Но то, чего вы не видите, — Apple не первая и не последняя.

Итак, ответ на вопрос «Что это значит для SaaS?»

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

У челленджера, созданного вайб-кодингом, ничего из этого нет.

Между тем 46% разработчиков — тех, кто использует эти инструменты каждый день — не доверяют тому, что производит ИИ. Рост с 31% год назад.

Нынешний рынок, однако, закладывает в цены будущее, где ИИ сделает софтверные компании ненужными.

Почему? Потому что рынок — это просто коллекция человеческого безумия, выраженная в цифрах.

Я работаю над серией «Почему ИИ не заменит X» — объясняю со всех сторон, почему SaaS не умирает и почему вы не потеряете свою работу.

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


  1. Bardakan
    11.04.2026 06:42

    И это ещё не всё: сама проверка занимает больше времени. Рецензентам требуется в 5 раз больше времени на проверку AI-кода.

    В итоге они тратят на проверку больше времени, чем раньше уходило на написание самого кода.

    ИИ не сократил объём работы. Он его увеличил!

    опять конгнитрон генерит откровенный нейробред.

    Я создаю экраны для приложений ios в cursor раза в два быстрее, чем вручную - и это все быстрее релизится в app store. А мне тут что-то втирают про замедление разработки


    1. ideological
      11.04.2026 06:42

      Если вы сэкономили время это круто.

      Но чисто для уточнения, а без cursor это автоматизировать было бы нельзя? Всякие UI Kits и многочисленные templates типа figma.com/community/mobile-apps/ios не для этого?


    1. Kahelman
      11.04.2026 06:42

      Т.е. если перевести на нормальный язык: АИ сделал разработчиков продуктивнее, они. Завалили Apple Store приложениями, Apple Store не справляется с ревью - но это проблемы не Apple Store , а разработчиков, которые на самом деле не стали продуктивнее? Это типа так понимать надо?

      Кто нибудь может нормальным языком рассказать что именно забанили и почему- я ничего не смог понять из статьи - запустить на нее что-ли чат гпт чтобы объяснил нормальным языком» кто на чем стоял …


  1. DikSoft
    11.04.2026 06:42

    Слишком много букв. Краткое содержание статьи:

    "Apple всегда прав. И когда удаляет VPN, и когда поддерживает цензуру, и когда просто делает то, что им выгодно. Но это всегда забота о пользователях, а не то, что вы тут подумали"


  1. KivApple
    11.04.2026 06:42

    Там же речь о приложениях, которые сам вайбкодер запускает на своём устройстве. Даже если оно получится глючным, пострадает только сам автор. Плюс очень условно он пострадает, там эти приложения запускались в WebView, через который сложно сделать что-то совсем плохое.

    Генерировать приложения с помощью ИИ на компьютере и спамить App Store бан этих приложений никак не мешает.


  1. topright007
    11.04.2026 06:42

    А backend-driven UI, через который работают гиганты с "большими кухнями" - это не нарушение пункта 2.5.2?


    1. SAWER
      11.04.2026 06:42

      Если исполняемый код остаётся тем же - нет. Т.е. backend-driven UI не нарушает вообще никак, потому как это просто данные для движка(браузера). Но есть и исключения, типа самих браузеров, компиляторов и т.п. Но там с особенностями


  1. Kahelman
    11.04.2026 06:42

    Для тех для кого много букв и мало мыслей, краткий пересказ от чат ГПТ

    Коротко: статья на Habr смешивает два разных сюжета.


    Первый — реальное событие: Apple действительно начала жёстче применять правило App Store 2.5.2 к части “vibe coding” приложений, потому что они могут загружать/исполнять новый код после ревью и тем самым менять функциональность приложения уже на устройстве пользователя. Это старое правило, а не новый анти-AI запрет. Apple прямо пишет, что приложение должно быть self-contained и не должно “download, install, or execute code which introduces or changes features or functionality of the app”. 


    Второй — большой инвестиционный вывод “значит AI не убьёт SaaS”. Вот здесь статья уже сильно натягивает факты. Часть исследований она пересказывает выборочно, часть — слишком уверенно, а часть тезисов вообще не следует из истории с Apple. 


    Что реально случилось

    Apple в марте 2026 года начала блокировать обновления для некоторых приложений вроде Replit и Vibecode, а затем убрала из App Store приложение Anything, ссылаясь на правило 2.5.2. При этом Apple через 9to5Mac отдельно пояснила: проблема не в “vibe coding” как таковом, а в приложениях, которые нарушают правила App Review и Developer Program License. Более того, похожие приложения при этом оставались в App Store. То есть это был не тотальный бан AI-apps, а точечное enforcement по архитектурному признаку: можно ли приложению после одобрения фактически становиться “другим” приложением. 


    Почему Apple так смотрит на это

    Логика Apple достаточно прямолинейна: если приложение после ревью может исполнять новый код, который Apple не проверяла, ревью теряет смысл. Это не новая позиция — правило 2.5.2 давно существует. А в 2024 году Apple вообще проверила 7.77 млн submissions и отклонила 1.93 млн, то есть жёсткий контроль App Store — обычная практика, а не что-то специально придуманное против AI. 


    Статья права в одном важном моменте: Apple не анти-AI в целом. В феврале 2026 Apple сама объявила Xcode 26.3 с поддержкой agentic coding и интеграциями Anthropic Claude Agent и OpenAI Codex. Это сильно ослабляет версию “Apple воюет с AI”. Скорее Apple говорит: “AI для разработки — да, но не любой механизм runtime code execution внутри App Store-приложения”. 


    Что в статье подтверждается

    Тезис про скачок числа приложений в App Store на 84% в Q1 2026 встречается в пересказах The Information: около 235,800 новых приложений за квартал, +84% год к году. Но это не официальный отчёт Apple, а журналистское сообщение со ссылкой на данные The Information. То есть цифра правдоподобная, но это не первичка Apple. 


    Тезис, что AI-код далеко не всегда ускоряет разработку, тоже имеет основание. Исследование METR показало, что опытные open-source разработчики с AI-инструментами в их дизайне эксперимента работали на 19% медленнее, хотя сами ожидали ускорения. Но это важное уточнение: это снимок для конкретного класса задач и конкретных инструментов начала 2025 года, а не универсальный закон “AI всегда тормозит”. 


    Тезис про проблемы доверия к AI-коду тоже подтверждается. По Stack Overflow Survey 2025 больше разработчиков не доверяют точности AI-output (46%), чем доверяют ему (33%), а 45.2% говорят, что дебажить AI-сгенерированный код более затратно по времени. Sonar даёт ещё более жёсткую картину: 96% разработчиков не полностью доверяют функциональной корректности AI-кода. 


    Тезис про рост нестабильности при росте AI-adoption тоже не выдуман, но в статье он подан слишком категорично. Google DORA действительно пишет, что AI adoption имеет negative relationship with software delivery stability. Но конкретную цифру “каждые +25% adoption = -7.2% stability” я по доступным первичным источникам сейчас надёжно не подтвердил. Сам вывод про отрицательную связь — подтверждается; точный коэффициент из статьи я бы считал непроверенным. 


    Где статья преувеличивает или мухлюет

    Самый важный момент: Apple не удаляла “AI-приложения” вообще. Она била по конкретному паттерну поведения приложений — post-review code execution / changing functionality. Поэтому заголовок “Apple удалила ИИ-приложения” вводит в заблуждение. Корректнее: Apple ограничила часть vibe-coding apps, которые, по её мнению, нарушали 2.5.2. 


    Дальше — безопасность. В статье фигурирует история про “5000 приложений”, “2000 критических уязвимостей”, “400 открытых секретов”, “60% приложений уязвимы”. Похожие числа действительно гуляют по индустрии и восходят к сканированию 5,600+ приложений фирмой Escape. Но это не академическое исследование и не универсальный вывод про весь AI-код. Кроме того, формулировка “60% приложений были уязвимы” в статье звучит жёстче, чем доступный источник, который говорит о найденных уязвимостях, exposed secrets и PII в конкретной выборке публичных vibe-coded apps. Это скорее security-vendor finding, а не бесспорный научный консенсус. 


    Тезис “только треть AI-кода проходит первичную проверку, а reviewers тратят в 5 раз больше времени” в статье выглядит особенно сомнительно в своей подаче. Я не нашёл надёжного первичного исследования, которое бы подтверждало именно такую связку. Есть близкие по духу данные: у METR есть note, что many SWE-bench-passing PRs не были бы смержены maintainers и что maintainer merge rates заметно ниже automated pass rates; есть данные LinearB, что AI-generated PRs ждут в 5.25 раза дольше, пока их вообще возьмут на review. Но это не то же самое, что “review идёт в 5 раз дольше” и не то же самое, что “две трети AI-кода проваливают инспекцию”. Тут статья явно сшивает разные источники в один драматичный тезис. 


    История про SaaS

    Из факта, что Apple применяет 2.5.2, не следует, что “SaaS защищён” или что рынок точно неправильно оценивает AI-risk. Из этого следует только более узкая вещь: на iPhone у Apple есть сильный gatekeeper-контроль, и она не хочет допускать приложения, которые могут менять себя через исполняемый код после ревью. Это говорит больше про модель безопасности и контроля App Store, чем про долгосрочную судьбу всего SaaS-рынка. 


    При этом более умеренный вывод статьи всё же разумен: AI делает код дешевле в генерации, но не автоматически решает вопросы архитектуры, security, compliance, поддержки и закупочного due diligence. Это согласуется и с DORA, и с METR, и с опросами разработчиков. Но это всё равно не доказательство, что AI не разрушит часть SaaS-категорий. Скорее это доказательство, что “написать код” и “построить надёжный продуктовый бизнес” — не одно и то же. 


    Мой итог по статье

    Статья на Habr:


    • верно ловит суть правила 2.5.2 и того, что Apple не хочет post-review code execution;  

    • верно замечает, что Apple не анти-AI в общем смысле, потому что сама продвигает AI в Xcode;  

    • верно использует общий мотив из METR/DORA/опросов: AI-код пока создаёт много friction, verification overhead и trust issues;  

    • но сильно преувеличивает, когда превращает это в историю “Apple удалила AI-приложения” и “значит тезис про смерть SaaS окончательно опровергнут”;  

    • и слишком свободно обращается с цифрами, особенно там, где security-vendor findings и отдельные operational metrics подаются как универсальная истина.  



    Самая точная формулировка была бы такой:


    Apple не объявила войну AI. Она применила старое правило App Store против класса приложений, которые могут исполнять новый код после ревью. История говорит о контроле платформы и рисках runtime code generation на iPhone, а не о том, что AI “проиграл” или что SaaS “спасён”. 


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


    1. Wesha
      11.04.2026 06:42

      Ммм, нейрослоп комментирует нейрослоп. Теперь я видел всё.


  1. SkywardFire
    11.04.2026 06:42

    отличная статья! Я всегда радуюсь, когда кто-то выливает ушат холодной воды на головы вайбкодеров.

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

    1. Вайбкодинг -- это плохо, а не хорошо. (В лучшем случае это для быстрой проверки гипотез, но не более)

    2. Нельзя путать написание кода с помощью ИИ и вайб-кодинг. Это не одно и то же.

    То, что у нас теперь есть такие потрясающие инструменты -- это круто. То, что теперь каждый третий себя считает разработчиком -- нет. Кроме кодинга есть еще архитектура, паттерны, и вообще понимание происходящего.

    Развивать Agentic coding, конечно же, нужно. Но так же нужно и осознавать текущие ограничения.

    В будущем инструменты вполне могут дорасти до целевого уровня качества, а сейчас, как мне кажется, у людей просто забрало упало, а учитывая, что в индустрию приходят не-программисты, они даже не понимают что делают не так, и получается самосбывающееся пророчество. Забрало падает еще сильнее, и ни о какой оценке текущих ограничений никто и слышать не хочет.

    А еще мне вот интересно -- Суини осозннанно подменяет понятия? Не верится, что он реально не понимает, что вайб-кодинг это отнюдь не "учить детей программированию", а как раз наоборот.