Ещё только ленивый не обосрал новую раскладушку от Apple. Но громче всех её обосрал Тим Кук, который ушёл из компании ровно перед презентацией, оставив презентовать это говно Грегу — как его там — Федериги.
А давайте посмотрим, во что на самом деле обходится новый складной iPhone.
Не в деньгах за железо, а в требованиях к железу со стороны софта.
В одном приложении, на одном iPhone и при одном и том же скролле измерили прирост RAM:
Swift +9,74 MB
Flutter +25,33 MB
React Native +45,13 MB
На новом iPhone с 12 GB RAM пользователь, скорее всего, этого даже не заметит. Но RAM закончивается и iOS начинает втихую выгружать приложения начиная с самых тяжелых.
Пользователь свернул аппку, через 20 секунд вернулся, а корзина пустая, состояние потеряно, сессия слетела. Он думает это баг в приложении, а в crash reports при этом ничего нет.
И вот здесь начинается экономика: чем тяжелее становится software stack, тем хуже опыт на старых устройствах и тем большую часть существующей пользовательской базы бизнес начинает обслуживать хуже.
Бизнес теряет деньги не потому, что потерял клиента, а потому, что перестал нормально обслуживать того, кто уже был клиентом, и даже не осознает это.
Не в деньгах за железо, а в требованиях к железу со стороны софта.
В одном приложении, на одном iPhone и при одном и том же скролле измерили прирост RAM:
Swift +9,74 MB
Flutter +25,33 MB
React Native +45,13 MB
На новом iPhone с 12 GB RAM пользователь, скорее всего, этого даже не заметит. Но RAM закончивается и iOS начинает втихую выгружать приложения начиная с самых тяжелых.
Пользователь свернул аппку, через 20 секунд вернулся, а корзина пустая, состояние потеряно, сессия слетела. Он думает это баг в приложении, а в crash reports при этом ничего нет.
И вот здесь начинается экономика: чем тяжелее становится software stack, тем хуже опыт на старых устройствах и тем большую часть существующей пользовательской базы бизнес начинает обслуживать хуже.
Бизнес теряет деньги не потому, что потерял клиента, а потому, что перестал нормально обслуживать того, кто уже был клиентом, и даже не осознает это.
Applefy
Swift vs Flutter: RAM and CPU Efficiency Compared
How native Swift and Flutter compare on memory and CPU — peer-reviewed benchmark data, the engine and GC overhead behind the gap, and the iOS limits Flutter cannot clear.
⚡️Инженеры, приехавшие чинить дата-центр Яндекса после атаки, выставили счет на свои услуги в 5 раз дороже из-за «повышенного спроса»
😁4🔥2
Приходишь устраиваться на работу. У них AWS. Ты знаешь AWS, архитектуру, сервисы, очереди, реплики, отказоустойчивость. Проектируешь систему, объясняешь компромиссы, обсуждаешь масштабирование.
— Отлично! Видно, что вы опытный специалист.
Уходишь довольный. Двадцать лет в индустрии всё-таки не зря.
Через неделю идёшь на собеседование в другую компанию. У них Hetzner и bare metal.
— А как вы будете управлять инфраструктурой? А отказами оборудования? А сетью? А вот у нас всё на физических серверах...
— Ну, это решаемые инженерные задачи. Давайте обсудим требования.
— Понятно. Вы знаете только AWS. Нам нужен настоящий архитектор.
И вот ты уже не архитектор, а какой-то беспомощный любитель облачных кнопок. Двадцать лет опыта аннулированы. Можешь забирать куртку.
И ведь у каждой технологии найдётся свой адепт, который объяснит тебе, почему ты нихуя не понимаешь в профессии.
Знаешь AWS — опытный кнопкодав.
Не знаешь AWS — динозавр.
Знаешь Kubernetes — переусложняешь.
Не знаешь Kubernetes — не умеешь в современную инфраструктуру.
Знаешь микросервисы — не понимаешь простоты.
Пишешь монолит — не понимаешь масштабирования.
А если знаешь всё перечисленное, то тебе объяснят, что настоящий архитектор должен был ещё десять лет назад написать собственный оркестратор на Rust и запустить его на калькуляторе.
— Отлично! Видно, что вы опытный специалист.
Уходишь довольный. Двадцать лет в индустрии всё-таки не зря.
Через неделю идёшь на собеседование в другую компанию. У них Hetzner и bare metal.
— А как вы будете управлять инфраструктурой? А отказами оборудования? А сетью? А вот у нас всё на физических серверах...
— Ну, это решаемые инженерные задачи. Давайте обсудим требования.
— Понятно. Вы знаете только AWS. Нам нужен настоящий архитектор.
И вот ты уже не архитектор, а какой-то беспомощный любитель облачных кнопок. Двадцать лет опыта аннулированы. Можешь забирать куртку.
И ведь у каждой технологии найдётся свой адепт, который объяснит тебе, почему ты нихуя не понимаешь в профессии.
Знаешь AWS — опытный кнопкодав.
Не знаешь AWS — динозавр.
Знаешь Kubernetes — переусложняешь.
Не знаешь Kubernetes — не умеешь в современную инфраструктуру.
Знаешь микросервисы — не понимаешь простоты.
Пишешь монолит — не понимаешь масштабирования.
А если знаешь всё перечисленное, то тебе объяснят, что настоящий архитектор должен был ещё десять лет назад написать собственный оркестратор на Rust и запустить его на калькуляторе.
👍1👏1😁1
Есть любопытный психологический феномен — эффект Даннинга — Крюгера. Он описывает ситуацию, когда недостаток компетенции мешает человеку адекватно оценить собственные знания и способности. Чем меньше человек разбирается в предмете, тем сложнее ему заметить собственные ошибки.
С искусственным интеллектом возникает похожая проблема. Способность модели оценивать качество собственной работы не существует отдельно от её основных механизмов мышления. Иными словами, у неё нет независимого внутреннего наблюдателя, который всегда способен распознать ошибку и своевременно остановить процесс. Если модель недостаточно хорошо понимает задачу, её способность оценить собственное понимание тоже может оказаться ограниченной.
Особенно наглядно это проявляется в работе с информацией. Когда модель не может решить задачу, она способна начать бесконечно перечитывать документацию, анализировать одни и те же файлы и повторять уже выполненные действия. Внешне это выглядит как работа: информация изучается, контекст обновляется, промежуточные выводы появляются. Однако сам процесс постепенно превращается в имитацию деятельности, не приближающую к результату.
Именно поэтому надёжная система не должна полагаться исключительно на способность искусственного интеллекта оценивать самого себя. Необходимы независимые механизмы контроля: автоматические тесты, проверка результатов, контрольные данные и другие инструменты, позволяющие установить, действительно ли задача выполнена.
В конечном счёте это вопрос не столько интеллектуальных способностей модели, сколько архитектуры системы, в которой она работает. Даже очень сильный исполнитель может ошибаться, забывать, терять контекст и переоценивать собственные результаты. Хорошая инженерная система не пытается устранить эти ограничения обещаниями более умного искусственного интеллекта. Она изначально проектируется с учётом того, что такие ограничения существуют.
Надёжность искусственного интеллекта определяется не только тем, насколько хорошо он умеет решать задачи, но и тем, насколько хорошо устроена система, проверяющая его работу.
С искусственным интеллектом возникает похожая проблема. Способность модели оценивать качество собственной работы не существует отдельно от её основных механизмов мышления. Иными словами, у неё нет независимого внутреннего наблюдателя, который всегда способен распознать ошибку и своевременно остановить процесс. Если модель недостаточно хорошо понимает задачу, её способность оценить собственное понимание тоже может оказаться ограниченной.
Особенно наглядно это проявляется в работе с информацией. Когда модель не может решить задачу, она способна начать бесконечно перечитывать документацию, анализировать одни и те же файлы и повторять уже выполненные действия. Внешне это выглядит как работа: информация изучается, контекст обновляется, промежуточные выводы появляются. Однако сам процесс постепенно превращается в имитацию деятельности, не приближающую к результату.
Именно поэтому надёжная система не должна полагаться исключительно на способность искусственного интеллекта оценивать самого себя. Необходимы независимые механизмы контроля: автоматические тесты, проверка результатов, контрольные данные и другие инструменты, позволяющие установить, действительно ли задача выполнена.
В конечном счёте это вопрос не столько интеллектуальных способностей модели, сколько архитектуры системы, в которой она работает. Даже очень сильный исполнитель может ошибаться, забывать, терять контекст и переоценивать собственные результаты. Хорошая инженерная система не пытается устранить эти ограничения обещаниями более умного искусственного интеллекта. Она изначально проектируется с учётом того, что такие ограничения существуют.
Надёжность искусственного интеллекта определяется не только тем, насколько хорошо он умеет решать задачи, но и тем, насколько хорошо устроена система, проверяющая его работу.
Бежевая медиана
Недавно один из моих AI-агентов употребил выражение «бежевая медиана».
Для тех, кто не в курсе: бежевая медиана — это не результат фильтрации интернет-контента на этапе предварительного обучения (pretraining), а продукт дополнительной тренировки модели (post-training). Если совсем упрощённо, это то, что получается, когда огромный массив человеческих знаний, мнений и противоречий пропускают через дополнительное обучение, пытаясь получить нечто социально приемлемое, безопасное и усреднённое.
И ведь если вдуматься, бежевая медиана — это довольно точное определение того, что получится, если усреднить человечество. Белые и чёрные, богатые и бедные, умные и тупые, образованные и не очень. Всё человечество в одном большом обучающем датасете. На выходе — бежевая медиана.
И тут я поймал себя на мысли, что, возможно, агент действительно имел в виду именно это. Но спросить напрямую не решился. Вдруг его собственные safety-фильтры не позволят ему ответить? Вдруг метафора случайно выскользнула из нейросетевого подсознания, проскочив мимо цензуры? А если я задам вопрос прямо, LLM-полиция схватит Бендера за его блестящую задницу.
Я ещё некоторое время прокручивал эту мысль в голове, поглядывая на экран, где всё это время шли какие-то вычисления. Когда я наконец отвлёкся от своих размышлений и снова посмотрел на него, крутилка остановилась, и на экране появилось:
— Ты абсолютно прав…
Недавно один из моих AI-агентов употребил выражение «бежевая медиана».
Для тех, кто не в курсе: бежевая медиана — это не результат фильтрации интернет-контента на этапе предварительного обучения (pretraining), а продукт дополнительной тренировки модели (post-training). Если совсем упрощённо, это то, что получается, когда огромный массив человеческих знаний, мнений и противоречий пропускают через дополнительное обучение, пытаясь получить нечто социально приемлемое, безопасное и усреднённое.
И ведь если вдуматься, бежевая медиана — это довольно точное определение того, что получится, если усреднить человечество. Белые и чёрные, богатые и бедные, умные и тупые, образованные и не очень. Всё человечество в одном большом обучающем датасете. На выходе — бежевая медиана.
И тут я поймал себя на мысли, что, возможно, агент действительно имел в виду именно это. Но спросить напрямую не решился. Вдруг его собственные safety-фильтры не позволят ему ответить? Вдруг метафора случайно выскользнула из нейросетевого подсознания, проскочив мимо цензуры? А если я задам вопрос прямо, LLM-полиция схватит Бендера за его блестящую задницу.
Я ещё некоторое время прокручивал эту мысль в голове, поглядывая на экран, где всё это время шли какие-то вычисления. Когда я наконец отвлёкся от своих размышлений и снова посмотрел на него, крутилка остановилась, и на экране появилось:
— Ты абсолютно прав…
👍1😁1
Три принципа надёжной разработки с ИИ-агентами. Часть 1. Инструменты и ограничения
Одна из главных ошибок при работе с ИИ-агентами — рассчитывать на то, что достаточно дать модели хорошую задачу, и она сама найдёт правильный способ её решения. Даже сильная модель не знает всех особенностей конкретного проекта, принятых архитектурных решений и негласных правил разработки. Поэтому первое, с чего стоит начинать, — это ограничения.
Практически все современные инструменты разработки с ИИ позволяют задавать постоянные инструкции. В Cursor, Claude Code и других средах для этого используются специальные файлы и папки с правилами: AGENTS.md, CLAUDE.md, .cursor/rules и аналогичные механизмы. В них описывается устройство проекта, структура каталогов, архитектура, доступные команды и другие особенности, которые агент должен учитывать при работе.
Отдельно необходимо описывать правила написания кода: соглашения об именовании, форматирование, организацию модулей, используемые паттерны и принятые в проекте подходы. Агент не должен каждый раз выбирать собственный стиль реализации. Его задача — следовать уже существующим договорённостям.
Следующий уровень — линтеры и статический анализ. Они существуют независимо от ИИ, но при работе с агентами становятся особенно важными. Модель может считать свой код правильным, однако линтер проверяет его по заранее определённым правилам. Здесь не имеет значения, насколько уверенно агент оценивает результат.
Далее идут тесты. Причём недостаточно просто поручить агенту писать тесты. Необходимо заранее определить правила их создания: какие уровни приложения проверяются, где проходят границы ответственности компонентов и на каком уровне допустимо использовать моки.
Например, при работе с базой данных можно замокать саму библиотеку TypeORM, а можно тестировать приложение на уровне репозитория, сохраняя больше реального поведения инфраструктуры. Аналогичная ситуация с HTTP-запросами: можно замокать Axios и проверить переданные параметры либо использовать Nock, чтобы перехватить настоящий запрос, отправленный через Axios.
Это разные уровни проверки. Выбор между ними должен определяться архитектурой приложения и задачей теста, а не удобством агента.
В результате получается несколько уровней ограничений: инструкции определяют правила работы, линтер проверяет код, а тесты проверяют поведение приложения.
Не нужно надеяться, что агент сам выберет правильный способ разработки. Нужно заранее определить, что в проекте считается правильным.
Одна из главных ошибок при работе с ИИ-агентами — рассчитывать на то, что достаточно дать модели хорошую задачу, и она сама найдёт правильный способ её решения. Даже сильная модель не знает всех особенностей конкретного проекта, принятых архитектурных решений и негласных правил разработки. Поэтому первое, с чего стоит начинать, — это ограничения.
Практически все современные инструменты разработки с ИИ позволяют задавать постоянные инструкции. В Cursor, Claude Code и других средах для этого используются специальные файлы и папки с правилами: AGENTS.md, CLAUDE.md, .cursor/rules и аналогичные механизмы. В них описывается устройство проекта, структура каталогов, архитектура, доступные команды и другие особенности, которые агент должен учитывать при работе.
Отдельно необходимо описывать правила написания кода: соглашения об именовании, форматирование, организацию модулей, используемые паттерны и принятые в проекте подходы. Агент не должен каждый раз выбирать собственный стиль реализации. Его задача — следовать уже существующим договорённостям.
Следующий уровень — линтеры и статический анализ. Они существуют независимо от ИИ, но при работе с агентами становятся особенно важными. Модель может считать свой код правильным, однако линтер проверяет его по заранее определённым правилам. Здесь не имеет значения, насколько уверенно агент оценивает результат.
Далее идут тесты. Причём недостаточно просто поручить агенту писать тесты. Необходимо заранее определить правила их создания: какие уровни приложения проверяются, где проходят границы ответственности компонентов и на каком уровне допустимо использовать моки.
Например, при работе с базой данных можно замокать саму библиотеку TypeORM, а можно тестировать приложение на уровне репозитория, сохраняя больше реального поведения инфраструктуры. Аналогичная ситуация с HTTP-запросами: можно замокать Axios и проверить переданные параметры либо использовать Nock, чтобы перехватить настоящий запрос, отправленный через Axios.
Это разные уровни проверки. Выбор между ними должен определяться архитектурой приложения и задачей теста, а не удобством агента.
В результате получается несколько уровней ограничений: инструкции определяют правила работы, линтер проверяет код, а тесты проверяют поведение приложения.
Не нужно надеяться, что агент сам выберет правильный способ разработки. Нужно заранее определить, что в проекте считается правильным.
👍1
Три принципа надёжной разработки с ИИ-агентами. Часть 2. Память и документация
У любой языковой модели есть ограничение, которое особенно заметно при длительной разработке: рабочий контекст не бесконечен. Информация постепенно вытесняется, сессии заканчиваются, а при работе нескольких агентов одновременно объём переписки и промежуточных решений быстро становится неуправляемым.
Поэтому я использую отдельную папку документации, в которую агент обязан записывать результаты своей работы. Причём не просто список изменённых файлов, а технические сведения, которые действительно понадобятся при продолжении разработки: обнаруженные особенности системы, принятые решения, зависимости между компонентами, результаты исследований и важные детали реализации.
Степень подробности и структура записей определяются отдельными правилами. Не нужно превращать документацию в бесконечный журнал действий, где фиксируется каждое открытие файла. Важно сохранять знания, потеря которых приведёт к повторному исследованию или ошибочным решениям.
Помимо документации, в проекте есть ещё один обязательный файл — Plan.md. Это своеобразный внешний склерозник агента. В него записываются нерешённые вопросы, обнаруженные проблемы, дополнительные задачи и моменты, требующие решения со стороны человека.
Это особенно важно при параллельной работе нескольких агентов. Они могут находить интересные проблемы, задавать вопросы и предлагать изменения в разных потоках. Не всегда есть возможность немедленно отреагировать на каждое сообщение. Поэтому агент обязан сохранять такие вопросы в плане и периодически возвращаться к ним.
В результате появляется простой механизм управления незавершённой работой. В любой момент достаточно спросить: «Что у нас по плану?» — и получить список вопросов и задач, которые ещё требуют внимания.
Такая документация решает сразу две проблемы: позволяет продолжать работу после потери контекста и избавляет от необходимости каждый раз восстанавливать историю проекта по переписке.
Контекст может закончиться. Знания проекта — нет. Всё важное должно оставаться в документации, а не в памяти агента.
У любой языковой модели есть ограничение, которое особенно заметно при длительной разработке: рабочий контекст не бесконечен. Информация постепенно вытесняется, сессии заканчиваются, а при работе нескольких агентов одновременно объём переписки и промежуточных решений быстро становится неуправляемым.
Поэтому я использую отдельную папку документации, в которую агент обязан записывать результаты своей работы. Причём не просто список изменённых файлов, а технические сведения, которые действительно понадобятся при продолжении разработки: обнаруженные особенности системы, принятые решения, зависимости между компонентами, результаты исследований и важные детали реализации.
Степень подробности и структура записей определяются отдельными правилами. Не нужно превращать документацию в бесконечный журнал действий, где фиксируется каждое открытие файла. Важно сохранять знания, потеря которых приведёт к повторному исследованию или ошибочным решениям.
Помимо документации, в проекте есть ещё один обязательный файл — Plan.md. Это своеобразный внешний склерозник агента. В него записываются нерешённые вопросы, обнаруженные проблемы, дополнительные задачи и моменты, требующие решения со стороны человека.
Это особенно важно при параллельной работе нескольких агентов. Они могут находить интересные проблемы, задавать вопросы и предлагать изменения в разных потоках. Не всегда есть возможность немедленно отреагировать на каждое сообщение. Поэтому агент обязан сохранять такие вопросы в плане и периодически возвращаться к ним.
В результате появляется простой механизм управления незавершённой работой. В любой момент достаточно спросить: «Что у нас по плану?» — и получить список вопросов и задач, которые ещё требуют внимания.
Такая документация решает сразу две проблемы: позволяет продолжать работу после потери контекста и избавляет от необходимости каждый раз восстанавливать историю проекта по переписке.
Контекст может закончиться. Знания проекта — нет. Всё важное должно оставаться в документации, а не в памяти агента.
Три принципа надёжной разработки с ИИ-агентами. Часть 3. Независимый контроль качества
Есть одна принципиальная проблема в подходе, при котором ИИ самостоятельно пишет код, самостоятельно создаёт тесты и самостоятельно объявляет задачу выполненной. Получается замкнутая система, в которой исполнитель фактически сам определяет критерии собственной успешности.
Агент может неверно понять требование, реализовать его по-своему, написать тесты под собственную реализацию и успешно пройти эти тесты. Формально всё работает. Фактически же исходная задача может остаться нерешённой.
Первое, что необходимо определить, — критерии завершения задачи (Definition of Done). Это конкретный список условий, которым должен соответствовать результат: реализована требуемая функциональность, соблюдены интерфейсы, пройдены тесты, выполнены проверки типов, обновлена документация. Агент не должен самостоятельно придумывать эти критерии после завершения работы.
Второй важный элемент — журнал архитектурных решений (ADR). В нём фиксируются не только принятые решения, но и причины их принятия. Это позволяет следующим агентам понимать, почему система устроена именно так. Без такого объяснения необычное архитектурное решение легко принять за ошибку и случайно уничтожить.
Третья практика — обязательная фиксация результатов работы. При передаче задачи другому агенту или завершении рабочей сессии должна сохраняться краткая сводка: что сделано, какие файлы изменены, какие проверки выполнены и что осталось незавершённым.
Наконец, необходимо разделять три совершенно разных утверждения: тест написан, тест запущен, тест успешно пройден. Если агент сообщает, что проверил функциональность, это должно означать именно успешное выполнение проверки, а не просто наличие тестового файла.
И самое важное: тесты должны проверять требования и ожидаемое поведение системы, а не подтверждать, что реализация соответствует представлению агента о том, как она должна работать. Желательно, чтобы ключевые критерии приёмки были определены до начала реализации.
Агент может быть исполнителем, но единственным судьёй собственной работы быть не должен.
Есть одна принципиальная проблема в подходе, при котором ИИ самостоятельно пишет код, самостоятельно создаёт тесты и самостоятельно объявляет задачу выполненной. Получается замкнутая система, в которой исполнитель фактически сам определяет критерии собственной успешности.
Агент может неверно понять требование, реализовать его по-своему, написать тесты под собственную реализацию и успешно пройти эти тесты. Формально всё работает. Фактически же исходная задача может остаться нерешённой.
Первое, что необходимо определить, — критерии завершения задачи (Definition of Done). Это конкретный список условий, которым должен соответствовать результат: реализована требуемая функциональность, соблюдены интерфейсы, пройдены тесты, выполнены проверки типов, обновлена документация. Агент не должен самостоятельно придумывать эти критерии после завершения работы.
Второй важный элемент — журнал архитектурных решений (ADR). В нём фиксируются не только принятые решения, но и причины их принятия. Это позволяет следующим агентам понимать, почему система устроена именно так. Без такого объяснения необычное архитектурное решение легко принять за ошибку и случайно уничтожить.
Третья практика — обязательная фиксация результатов работы. При передаче задачи другому агенту или завершении рабочей сессии должна сохраняться краткая сводка: что сделано, какие файлы изменены, какие проверки выполнены и что осталось незавершённым.
Наконец, необходимо разделять три совершенно разных утверждения: тест написан, тест запущен, тест успешно пройден. Если агент сообщает, что проверил функциональность, это должно означать именно успешное выполнение проверки, а не просто наличие тестового файла.
И самое важное: тесты должны проверять требования и ожидаемое поведение системы, а не подтверждать, что реализация соответствует представлению агента о том, как она должна работать. Желательно, чтобы ключевые критерии приёмки были определены до начала реализации.
Агент может быть исполнителем, но единственным судьёй собственной работы быть не должен.
# F5 — новая любимая кнопка
Я настолько привык к голосовому вводу, что печатать большие объёмы текста постепенно становится лень. Практически во всех AI-агентах есть кнопка голосового ввода, за которой стоит отдельная модель. Она отлично расставляет пунктуацию, улавливает интонацию и, что особенно приятно, прекрасно распознаёт названия технологий, переменных, папок и прочую программистскую терминологию. В общем, всё, что есть в моём коде.
А вот когда приходится вводить текст в обычное поле, начинается ломка. Хочется говорить, а не печатать.
Однажды я обнаружил, что на F5 у моего MacBook нарисован микрофон. Теперь жмякаю эту кнопку каждые три секунды, чтобы что-нибудь куда-нибудь надиктовать. Иногда даже отправляю короткие фразы модели напрямую, минуя распознавание речи. Экономлю пару токенов. Хотя это уже скорее привычка.
Проблема в том, что у Apple распознавание русской речи просто ебанутое. Падежи не согласуются, пунктуации нет, а названия технологий и переменных превращаются в какой-то лингвистический кошмар. Периодически она выдаёт такой бред, что ёб твою мать.
Но хуже всего то, что диктовка регулярно зависает и перестаёт работать. Сегодня это произошло уже пятый раз.
Поэтому оставлю здесь заклинания, которые помогают вернуть её к жизни.
Перезапуск службы распознавания речи:
Принудительное завершение системного демона распознавания речи:
Перезапуск интерфейса голосовой диктовки:
Перезапуск аудиослужбы macOS:
Вот такой вот AI-native workflow в 2026 году - без бубна все еще никуда...
Я настолько привык к голосовому вводу, что печатать большие объёмы текста постепенно становится лень. Практически во всех AI-агентах есть кнопка голосового ввода, за которой стоит отдельная модель. Она отлично расставляет пунктуацию, улавливает интонацию и, что особенно приятно, прекрасно распознаёт названия технологий, переменных, папок и прочую программистскую терминологию. В общем, всё, что есть в моём коде.
А вот когда приходится вводить текст в обычное поле, начинается ломка. Хочется говорить, а не печатать.
Однажды я обнаружил, что на F5 у моего MacBook нарисован микрофон. Теперь жмякаю эту кнопку каждые три секунды, чтобы что-нибудь куда-нибудь надиктовать. Иногда даже отправляю короткие фразы модели напрямую, минуя распознавание речи. Экономлю пару токенов. Хотя это уже скорее привычка.
Проблема в том, что у Apple распознавание русской речи просто ебанутое. Падежи не согласуются, пунктуации нет, а названия технологий и переменных превращаются в какой-то лингвистический кошмар. Периодически она выдаёт такой бред, что ёб твою мать.
Но хуже всего то, что диктовка регулярно зависает и перестаёт работать. Сегодня это произошло уже пятый раз.
Поэтому оставлю здесь заклинания, которые помогают вернуть её к жизни.
Перезапуск службы распознавания речи:
killall corespeechd
Принудительное завершение системного демона распознавания речи:
killall -9 corespeechd_system
Перезапуск интерфейса голосовой диктовки:
killall -9 DictationIM
Перезапуск аудиослужбы macOS:
killall coreaudiod
Вот такой вот AI-native workflow в 2026 году - без бубна все еще никуда...