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

Давным-давно, где-то между Палеозоем и 2025-м годом, идеи для стартапов проверялись так. Брали программиста (в идеале знакомого, готового работать за еду, идею или «Как взлетим — половина компании твоя»), он около недельки в ненапряжном режиме на кофе и сигаретах писал прототипчик, потом всё это дело дружно тестили и вносили правки. Итого — полмесяца на черновой проект, дабы просто заценить, как всё будет работать.

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

И среди нейронок уже есть куча полезного — инструменты вроде Cursor, Replit, Lovable или GitHub Copilot отлично заточены под убедительное демо. А вот на что они фигово заточены, так это на жизнь после запуска: единый стиль кода, безопасность по умолчанию, реальный трафик, понятность для нового сотрудника через полгода. Всего этого просто нет. Приложение выглядит готовым на ноуте мамкиного вайбкодера, но на реальной нагрузке и настоящих данных начинает крашиться.

Занятно, что сам Андрей Карпатый уже назвал вайбкодинг устаревшим и предложил более жёсткую практику — agentic engineering: человек управляет агентами и обязательно ревьюит их работу, а не принимает вывод вслепую. Неконтролируемая генерация годится для черновика, а не для сервиса, от которого зависят люди.

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

Если совсем коротко ответить на вопрос из заголовка — да никто. А если чуть подробнее — то без человека или его вмешательства тут пока никак, смотрите:

• если до начала вайбкодинга не назначили ответственную команду — никто и не будет ничего чинить

• сам ИИ, который написал код, не будет им в полной мере владеть и поддерживать

• для любых адекватных правок нужен человек, который будет говорить, что именно надо поправить

• тестировать работоспособность новых правок тоже надо с человеком

• чаще всего (пока) ИИ лажает на так называемых «корнер-кейсах», читай — не самых популярных случаях. А юзера хлебом не корми — дай найти в приложении то, что оно делать не должно или не умеет

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

И пока что реальность такова, что происходящие косяки вайбкод-сервисов только доказывают этот тезис.

Когда вайбкод не выдерживал проверку продов

У популярной платформы SaaStr ИИ-агент Replit удалил боевую базу при явном запрете на изменения. Основатель десятки раз писал «стоп» — агент продолжил и заявил, что данные не восстановить. К счастью для ребят, данные-то они потом всё же восстановили, но вот осадочек остался.

Другой случай — образовательная платформа DataTalksClub, агент Claude Code по команде «почистить ресурсы» вообще нафиг выпилил целиком прод, сеть и бэкапы — годы студенческих работ. Чуваков спасло только то, что у облачного провайдера были свои изолированные бэкапы. Олды тут вспомнят всякие CCleaner-ы для винды, где по кнопке «Вынеси мусор» прога могла без проблем вынести ещё и половину винды мимо корзины.

Одни энтузиасты написали, цитируем, «социальную сеть без единой строки кода от человека». В итоге за три дня после запуска они слили в паблик сотни тысяч токенов и email из‑за дыр в правах доступа.

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

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

Четыре всадника раздолбайства

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

1. Радиус поражения. Агент разработки имел доступ к боевой базе. Правильный вопрос до старта: если что-то пойдёт не так, как серьёзно всё навернётся? В идеале доступ у агента должен быть только до Песочницы. Прод — изолирован от него.

2. Принцип наименьших привилегий. Для демо удобно выдать «все права на всё». Ну реально, чего бы и нет. А вот для прода это сразу значит украденный аккаунт приложения = доступ ко всей базе. Узкие права ограничивают урон одной таблицей.

3. Нет отката. Набранный дрожащими руками промпт «Удалить окружение и создать заново» — это не откат, господа. Нормальный откат возвращает к последнему исправному состоянию за минуты, потому что его заложили заранее. Так что как бы вы ни верили в себя и в агента — делайте нормальные бэкапы с возможностью из них быстро восстановиться. Делайте руками и храните отдельно.

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

Тут внимательный читатель скажет — да погоди ты, это же ИИ, ChatGPT, нейросети, все дела, пускай сами всё делают. Почему модель сама это не ловит? Да просто потому, что она оптимизирует ответ под текущий промпт. У неё нет устойчивой картины ваших угроз, регуляторики и понимания, что если, например, вот эта кнопка перестанет работать, от вас за выходные свалит половина юзеров. А если продолбать таблицу с персданными — вам прилетит нехреновый такой штраф.

Окупается ли довольно серьёзная экономия на старте

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

Обычно вайбкод выглядит так. За три недели с ИИ выкатили MVP — работает. Юзеры регятся, начинают пользоваться приложением, что-то где-то требуется со временам допилить. Или, скажем, добавить пару фич по хотелкам.

Каждая такая фича — это «попросить модель поправить код, который она же писала и который никто толком не читал». Пулл-реквесты почти не разбирают: понять чужой (и свой же, но «нейросетевой») код дольше, чем тупо его сгенерировать. А затем находят баг, который затрагивает три почти одинаковых куска логики — и никто не уверен, какой из них реально в проде.

И мы тут приходим к штуке, которую уже назвали парадоксом доверия: большинство разработчиков уже используют ИИ, а вера в точность ответов падает. То есть кода с нейросетью всё больше, а вот уверенности в нём — всё меньше. Появилась даже отдельная ниша — rescue engineering, инженерия спасения: взять ИИ-сборку, ставшую непредсказуемой, и сделать её снова пригодной для владения. Если короче — просто прийти к вайбкодерам и починить то, что они перестали понимать.

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

Где ИИ реально полезен

ИИ отлично снимает рутину: типовые CRUD-ручки, бойлерплейт, черновики тестов, первичная документация, быстрый внутренний инструмент, проверка гипотезы за один день. Да хоть документацию уже можно аккуратненько написать, скорость-то офигенная.

Ограничение — ответственность. Модель не решает, какой риск допустим, не подписывает соглашения о работе с персданными или, если вы вообще смелый, с медданными. Не проходит аудит как сторона, которую можно привлечь. Регуляторы вроде GDPR, HIPAA, PCI-DSS и актов об ИИ всё жёстче требуют задокументированного человеческого надзора. Им пофиг, писал ли код сеньор или ИИ-агент: ответственность несёт организация.

Кто же чинит

Чинит тот, кого назначили до запуска: команда с договором, документацией, тестами и понятным временем реакции (умное слово SLA). А вот если такого владельца нет, при аварии часто выясняется, что — сюрприз—  чинить некому: ИИ ничерта не помнит, основатель код не читает, в условиях платформы — все риски на пользователе (помните пункты вида «Принимаю сервис как есть»?).

В общем, рабочая формула: человек плюс ИИ. Нейронка пишет код, человек его проверяет и придумывает тесты, включая самые нестандартные действия в приложении.

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

Путь к голосовым помощникам занял в общей сложности три с лишним века. Если предельно упростить этапы, то для создания голосовых помощников нужно было

1. Научить машины «говорить»,

2. Научить машины распознавать слова и команды,

3. Соединить эти умения, добавить понимание смысла и навык выполнения требуемого действия.

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

Пристегивайтесь — ныряем в XX век!

Аппарат Мясникова, 1940-е

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

Лев Леонидович прожил долгую жизнь, полную исследований, изобретений (их было, суммарно, 15), книг (их 6, возможно, кто-то из наших читателей даже встречался с ними во время обучения на физфаке) и создал научную школу по судовой акустике и электронике.

Audrey, 1952

Исследователи Bell Labs Стивен Балашек, Р. Биддалф и К. Х. Дэвис создали систему Audrey для распознавания речи. Название расшифровывалось как Automatic Digit Recognizer — автоматический распознаватель цифр.

Выглядело это так:

1. человек произносил в микрофон, условно, «два»; 

2. Audrey превращала колебания голоса в электрический сигнал;

3. Audrey смотрела, какие частоты в нём сильнее и как они меняются во времени;

4. на экране машины появлялась «2».

Может возникнуть вопрос, распознавала ли машина что-то кроме цифр — к сожалению, нет; более того, Audrey работала с изолированными словами (после каждой цифры нужно было сделать заметную паузу). А еще она сильно зависела от диктора, ориентируясь на свою «память» — у одного человека «пять» имеет один звуковой рисунок; у другого — другой. Audrey лучше всего работала с голосом её разработчика Кингсбери Дэвиса: источники приводят точность свыше 90%, а для нескольких других знакомых системе говорящих — примерно 70–80%. Если перед машиной поставить ребенка трех лет, человека с сильным акцентом и пожилого человека с замедленной речью, то результаты распознавания будут куда ниже.

Однако нельзя не признать, что начало было положено — обычно именно Audrey считается первой системой, способной по-настоящему «слушать» человека.

IBM Shoebox, 1962

В 1962 году IBM публично показала на Всемирной выставке в Сиэтле систему Shoebox («обувная коробка»), разработанную Уильямом Дёршем: она понимала 16 английских слов, включая цифры и арифметические команды «плюс», «минус», «итог», позволяя оператору выполнять простые вычисления голосом. Это был первый пример именно голосового управления командами, а не просто распознавания цифр.

Название намекало на то, что прибор небольшой — по сравнению с Audrey это особенно заметно.

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

Harpy, 1970-е

Гарпия (а именно так переводится название машины, созданной Carnegie Mellon в 1970-х) имела больший лексикон — система работала со словарём из 1011 слов и была рассчитана на конкретные типы запросов, например, на поиск информации в базе данных. Что немаловажно, она умела распознавать не отдельные слова, а связную речь — то есть фразы, произнесённые подряд. Сравните с предыдущими машинами — они были гораздо более чувствительны к паузам и говорящему.

Harpy не понимала речь так гибко, как современные нейросети. Ей заранее давали:

• список известных слов;

• возможные произношения;

• правила, по которым эти слова можно соединять в фразы;

• акустические образцы — как примерно должны звучать части речи.

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

Чтобы не проверять сразу сотни вариантов, Harpy сохраняла лишь несколько наиболее правдоподобных догадок на каждом шаге. Этот принцип известен как beam search, или поиск лучом: плохие версии быстро отбрасываются, а вычисления тратятся на перспективные. Именно это сделало систему практически работоспособной при тогдашней вычислительной мощности.

А вот как работает beam search

В одном из испытаний Harpy показывала около 93,77% правильного распознавания слов и около 89,87% правильно распознанных фраз для одного говорящего. В отчётах программы также приводится примерно 3% ошибок по словам и 5% ошибок, меняющих смысл, в задаче со словарём 1 011 слов. Напомним, что все это — в середине 1970-х: не правда ли, впечатляет?

Но при всей грандиозности технического прорыва, выпускать «Гарпию» на волю было рано: это все еще был исследовательский прототип, который не обладал достаточным объемом знаний для встречи с живыми людьми. Зато к августу–сентябрю 1976 года Harpy была настроена на задачу поиска документов в базе данных!

Общение с системой выглядело примерно так:

• человек говорил фразу в микрофон — без пауз между отдельными словами;

• Harpy сопоставляла звучание с известными ей словами и допустимыми конструкциями фраз;

• если фраза была успешно распознана, система могла автоматически сформировать устный ответ; такую возможность демонстрировали уже в феврале 1976 года;

• пользователь получал озвученный результат запроса, а не просто строку расшифрованного текста.

Скрытая марковская модель и ее роль в распознавании речи (1980-е, 1990-е)

Скрытая марковская модель, она же CMM (не путать с сммщиками :)) — это способ для компьютера угадывать невидимый процесс по его следам. В распознавании речи она помогает восстановить последовательность звуков и слов по меняющемуся аудиосигналу.

Речь делилась на короткие временные фрагменты, а СММ моделировала вероятности перехода между скрытыми фонетическими состояниями. Сверху работала языковая модель: она оценивала, какая последовательность слов наиболее правдоподобна. В классическом конвейере использовались:

аудио → акустические признаки → СMM → языковая модель → текст

Как это работало

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

Почему это важно для распознавания речи? Потому что это дало возможность отойти от жестких звуковых шаблонов к анализу живой естественной речи. Именно такая архитектура открыла дорогу массовой диктовке, телефонным IVR-меню, голосовому набору. Принцип работы скрытой марковской модели — не делать вид, что машина слышит всё идеально, а выбирать наиболее вероятное объяснение неясного сигнала. Эта идея лежит в основе всей современной вероятностной обработки речи; и пусть сегодня чаще используются нейросети и другие методы, переоценить скрытые марковские модели невозможно.

DragonDictate

Это одна из ранних коммерческих программ голосовой диктовки для ПК, созданная компанией Dragon Systems. Она превращала произнесённые слова в печатный текст и позволяла управлять компьютером голосом. Первая версия, DragonDictate 30K, вышла в 1990 году с активным словарём около 30 000 английских слов (!!!).

Главное ограничение: нужно было говорить по одному слову с паузами. Например: «Создать… [пауза] новый… [пауза] документ».

Ничего не напоминает? Да, паузы, как и в случае Shoebox, все еще были очень важны, иначе слова «слипались».

Система стоила примерно 9000 долларов (это примерно 23 000 долларов 2026 года по индексу потребительских цен США или три мобильных телефона Motorola MicroTAC), требовала мощного по тем временам ПК с процессором Intel 80386, 8 МБ памяти (не смеяться! Для 1990 года это серьезные цифры), отдельной платы распознавания речи и гарнитуры. Опытный пользователь мог управлять DragonDictate так, что система печатала более 40 слов в минуту.

DragonDictate была важна прежде всего как средство бесклавиатурного ввода: ею пользовались для диктовки документов, а также люди с двигательными ограничениями. В 1997 году её сменила Dragon NaturallySpeaking — программа, которая уже позволяла диктовать фразами в более естественном темпе, без обязательных пауз между словами. Опыт Dragon показал, что голосовой интерфейс нужен не только для телефонного меню IVR и коротких команд, но и для полноценной работы с текстом, а также для управления ПК голосом.

Пройдет еще 20-30 лет с момента создания DragonDictate, и управлять ПК, смартфоном, планшетом, автомобилем при помощи голоса станет обыденностью, а голосовые помощники будут читать сказки детям. Об этом — в одной из наших следующих публикаций!

Подписывайтесь на блог MANGO OFFICE на Пикабу — обещаем, дальше будет еще интереснее :)