Как навайбкодить приложение — и что с ним делать дальше
Собрать работающее приложение из описания сегодня может любой сотрудник. Разбираем, как это делается, где ломается и что с этим делать компании.
Коротко
Коротко
- Вайбкодинг реально работает на утилитах и прототипах. Разница между «работает» и «можно отдать людям» — это ревью, права, данные и владелец.
- Главная проблема не в качестве генерации, а в невоспроизводимости: тот же промпт завтра даст другой код, и никто не помнит, почему сделано так.
- В компаниях вайбкодинг уже происходит без разрешения. По оценкам 2026 года две трети тех, кто им пользуется, не разработчики.
- Запрет не работает — работает контур, в который самодельные приложения можно легально принести.
- Для внутренних систем есть второй способ генерации, где модель ограничена формальной моделью платформы и не может придумать несуществующее.
Что такое вайбкодинг и откуда взялся термин
Вайбкодинг — способ получать код, описывая задачу словами. Человек формулирует, что хочет, модель пишет реализацию, человек смотрит на результат и просит поправить. Ключевое отличие от обычной разработки в том, что автор не читает код построчно и часто не может его прочитать.
Термин появился 3 февраля 2025 года — его в соцсети X употребил Андрей Карпатый, исследователь машинного обучения, ранее руководивший направлением искусственного интеллекта в Tesla. К декабрю 2025 года Collins English Dictionary назвал vibe coding словом года. В феврале 2026-го сам Карпатый заявил, что термин устарел, и предложил вместо него agentic engineering, но в обиходе прижилось первое слово.
Из этой короткой истории важно одно. Вайбкодинг придумывали как описание способа работы человека, который умеет программировать и сознательно отказывается от чтения кода ради скорости. За полтора года практика ушла далеко от исходного смысла, и сейчас так работают люди, которые не программировали никогда. Ровно отсюда растут и польза, и проблемы.
Термин появился 3 февраля 2025 года — его в соцсети X употребил Андрей Карпатый, исследователь машинного обучения, ранее руководивший направлением искусственного интеллекта в Tesla. К декабрю 2025 года Collins English Dictionary назвал vibe coding словом года. В феврале 2026-го сам Карпатый заявил, что термин устарел, и предложил вместо него agentic engineering, но в обиходе прижилось первое слово.
Из этой короткой истории важно одно. Вайбкодинг придумывали как описание способа работы человека, который умеет программировать и сознательно отказывается от чтения кода ради скорости. За полтора года практика ушла далеко от исходного смысла, и сейчас так работают люди, которые не программировали никогда. Ровно отсюда растут и польза, и проблемы.
Что реально получается
Ожидания от вайбкодинга сильно разные, и полезно заранее разложить результат по уровням. Разница между уровнями измеряется не качеством генерации, а тем, что придётся добавить руками.
Первые два уровня вайбкодинг закрывает уверенно, и спорить с этим бессмысленно. Третий уровень получается, но требует работы, которую человек без опыта разработки обычно не видит. Четвёртый — место, где заканчивается способ.
Практический вывод для руководителя. Когда сотрудник показывает навайбкоденное приложение и говорит «оно работает», он почти всегда имеет в виду второй уровень, а планирует третий.
Уровень | Что это | Сколько занимает | Что нужно добавить, чтобы отдать людям |
Утилита для себя | Скрипт, калькулятор, конвертер, разовый отчёт | Минуты и часы | Ничего — она живёт у автора и умирает вместе с задачей |
Прототип для обсуждения | Работающий макет, на котором видно идею | Часы | Понимание, что это макет, зафиксированное явно |
Внутренний инструмент | Приложение, которым пользуется отдел | Дни | Роли, права, обработку ошибок, место для данных, владельца |
Система в контуре компании | То же, но с настоящими данными и интеграциями | Недели, если вообще получится | Ревью, журнал действий, резервное копирование, поддержку |
Первые два уровня вайбкодинг закрывает уверенно, и спорить с этим бессмысленно. Третий уровень получается, но требует работы, которую человек без опыта разработки обычно не видит. Четвёртый — место, где заканчивается способ.
Практический вывод для руководителя. Когда сотрудник показывает навайбкоденное приложение и говорит «оно работает», он почти всегда имеет в виду второй уровень, а планирует третий.
Инструменты 2026 года и для чего каждый
Инструменты делятся на два семейства, и путать их дорого.
Первое семейство усиливает того, кто уже умеет. Второе даёт результат человеку без навыка, и именно оно превратило вайбкодинг в массовое явление.
Сравнительные обзоры 2026 года описывают состояние второго семейства довольно жёстко. Эти инструменты прекрасны в производстве работающего софта за часы, но пока не заслуживают доверия в его эксплуатации. Результат бывает непредсказуемым, а ошибки — тонкими, и на отладку уходит больше времени, чем ушло бы на аккуратную сборку с самого начала.
Отдельно стоит сказать про российский контекст. Большинство перечисленных сервисов работают в зарубежном облаке и на зарубежных моделях. Для домашнего эксперимента это неважно, для корпоративной задачи с реальными данными — определяющее обстоятельство, к которому мы вернёмся в главе про данные.
Инструменты этого класса устроены по-разному, и путаница между ними даёт большую часть разочарований: четыре класса генераторов приложений и где каждый заканчивается.
Семейство | Примеры | Кому адресовано | Что получаете на выходе |
Агенты и ассистенты в среде разработки | Cursor, Claude Code, GitHub Copilot, Windsurf | Разработчикам и тем, кто готов разбираться в коде | Код в вашем репозитории, который надо запустить и поддерживать |
Платформы «текст → приложение» | Lovable, Bolt, v0, Replit Agent, Base44 | Всем, включая тех, кто не программирует | Развёрнутое приложение в облаке платформы вместе с его кодом |
Первое семейство усиливает того, кто уже умеет. Второе даёт результат человеку без навыка, и именно оно превратило вайбкодинг в массовое явление.
Сравнительные обзоры 2026 года описывают состояние второго семейства довольно жёстко. Эти инструменты прекрасны в производстве работающего софта за часы, но пока не заслуживают доверия в его эксплуатации. Результат бывает непредсказуемым, а ошибки — тонкими, и на отладку уходит больше времени, чем ушло бы на аккуратную сборку с самого начала.
Отдельно стоит сказать про российский контекст. Большинство перечисленных сервисов работают в зарубежном облаке и на зарубежных моделях. Для домашнего эксперимента это неважно, для корпоративной задачи с реальными данными — определяющее обстоятельство, к которому мы вернёмся в главе про данные.
Инструменты этого класса устроены по-разному, и путаница между ними даёт большую часть разочарований: четыре класса генераторов приложений и где каждый заканчивается.
Как навайбкодить приложение: порядок действий
Если вы хотите попробовать сами, работающий порядок выглядит так. Он не гарантирует результата, но заметно повышает шансы.
Отдельно про ожидания по срокам. Первый работающий вариант появляется быстро — за это вайбкодинг и ценят. Дальше время растёт нелинейно, и последние двадцать процентов функциональности обычно занимают больше, чем первые восемьдесят.
И одно правило про отладку, которое экономит больше всего времени. Когда приложение перестало работать после очередной правки, бесполезно просить модель «исправить ошибку» — она начнёт менять то, что менять не нужно. Вернитесь к последней рабочей копии и повторите правку меньшим шагом. Это скучно и работает лучше любых формулировок.
- Опишите задачу целиком, а потом разбейте на части. Модель хорошо делает одну функцию за раз и плохо — приложение целиком по одному абзацу. Сначала общая картина, потом сборка по кускам.
- Начните с данных. Скажите, какие сущности есть и как они связаны. Приложение, собранное вокруг понятной модели данных, потом чинится, а собранное вокруг экранов — нет.
- Просите по одному изменению. Два требования в одном запросе почти гарантированно дадут странный результат, и вы не поймёте, какое из них его вызвало.
- Проверяйте после каждого шага. Не в конце. Ошибка, пойманная сразу, стоит одного запроса; ошибка, найденная через двадцать шагов, часто требует начать заново.
- Фиксируйте, что уже работает. Копия проекта после каждого удачного этапа — простейшая страховка от того, что модель сломает готовое, исправляя новое.
- Просите не только сделать, но и объяснить решение. Ответ на вопрос «почему так» показывает, придумала модель ограничение или нашла его в задаче, — даже если сам код вы не читаете.
Отдельно про ожидания по срокам. Первый работающий вариант появляется быстро — за это вайбкодинг и ценят. Дальше время растёт нелинейно, и последние двадцать процентов функциональности обычно занимают больше, чем первые восемьдесят.
И одно правило про отладку, которое экономит больше всего времени. Когда приложение перестало работать после очередной правки, бесполезно просить модель «исправить ошибку» — она начнёт менять то, что менять не нужно. Вернитесь к последней рабочей копии и повторите правку меньшим шагом. Это скучно и работает лучше любых формулировок.
ЕСТЬ ВТОРОЙ СПОСОБ
Генерация, ограниченная моделью платформы
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Отличие от вайбкодинга в том, что модель здесь не пишет код с нуля. Она описывает будущее приложение на объектном языке платформы — сущности, поля, роли, экраны, маршруты — и собирает его из компонентов, которые в платформе уже есть и уже работают. Придумать несуществующий тип поля или права, которых нет, она не может по построению.
С заказной разработкой это сравнивается по устройству цикла. Там между потребностью и работающей системой стоит очередь и релиз на каждое изменение. Здесь очереди нет.
Генерация, ограниченная моделью платформы
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Отличие от вайбкодинга в том, что модель здесь не пишет код с нуля. Она описывает будущее приложение на объектном языке платформы — сущности, поля, роли, экраны, маршруты — и собирает его из компонентов, которые в платформе уже есть и уже работают. Придумать несуществующий тип поля или права, которых нет, она не может по построению.
С заказной разработкой это сравнивается по устройству цикла. Там между потребностью и работающей системой стоит очередь и релиз на каждое изменение. Здесь очереди нет.
- личные кабинеты, заявки, согласования, реестры и внутренние порталы
- правки в чате без нового релиза
- заявленный эффект — в 10–50 раз меньше трудозатрат на типовое решение
Где вайбкодинг ломается
Три места, и все три предсказуемы.
Модель придумывает то, чего нет. Это не дефект конкретного сервиса, а свойство подхода. Языковая модель предсказывает продолжение текста, и когда в задаче не хватает деталей, она достраивает их сама. В приложении это выглядит узнаваемо. Появляется поле, которого не было в требованиях. Вызывается функция, которой не существует. Обработка случая, про который не спросили, просто отсутствует.
Теряются ветви сценария. Человек, описывая процесс, говорит про главный путь и забывает про исключения — отказ, возврат, отмену, пустой список, повторную отправку. Модель не переспрашивает, а собирает то, что услышала. Приложение работает ровно до первого нетипичного действия пользователя.
Результат невоспроизводим. Самая недооценённая проблема. Тот же запрос завтра даст другой код, а внутри проекта нет причины, по которой сделано именно так. Через месяц никто — включая автора — не сможет сказать, почему здесь стоит это условие, и любая правка становится рискованной. В обычной разработке от этого спасают ревью, история изменений и договорённости о том, как принято писать. В вайбкодинге всего этого по определению нет.
К этому добавляется практическая деталь, которую отмечают обзоры инструментов. В таких проектах нельзя зафиксировать состояние кода и запретить его менять, поэтому «работающая версия» — понятие скорее временное.
Модель придумывает то, чего нет. Это не дефект конкретного сервиса, а свойство подхода. Языковая модель предсказывает продолжение текста, и когда в задаче не хватает деталей, она достраивает их сама. В приложении это выглядит узнаваемо. Появляется поле, которого не было в требованиях. Вызывается функция, которой не существует. Обработка случая, про который не спросили, просто отсутствует.
Теряются ветви сценария. Человек, описывая процесс, говорит про главный путь и забывает про исключения — отказ, возврат, отмену, пустой список, повторную отправку. Модель не переспрашивает, а собирает то, что услышала. Приложение работает ровно до первого нетипичного действия пользователя.
Результат невоспроизводим. Самая недооценённая проблема. Тот же запрос завтра даст другой код, а внутри проекта нет причины, по которой сделано именно так. Через месяц никто — включая автора — не сможет сказать, почему здесь стоит это условие, и любая правка становится рискованной. В обычной разработке от этого спасают ревью, история изменений и договорённости о том, как принято писать. В вайбкодинге всего этого по определению нет.
К этому добавляется практическая деталь, которую отмечают обзоры инструментов. В таких проектах нельзя зафиксировать состояние кода и запретить его менять, поэтому «работающая версия» — понятие скорее временное.
Что происходит через месяц
Отдельная глава, потому что решение о судьбе приложения принимают именно на этом сроке.
Первое — приложение просит доработки. Появилось новое требование, изменился регламент, понадобился ещё один отчёт. Автор возвращается к инструменту и обнаруживает, что модель не помнит проект целиком, а изменение в одном месте ломает другое.
Второе — что-то отваливается само. Обновилась библиотека, истёк ключ доступа к внешнему сервису, поменялся формат данных на входе. Приложение, у которого нет владельца среди разработчиков, в этот момент просто перестаёт работать, и никто не знает, с чего начать.
Третье и самое частое — автор уходит. Уходит в отпуск, на другой проект или из компании. Вместе с ним уходит единственное понимание того, как приложение устроено, потому что документации нет, а код никто не читал даже в момент создания.
Ни один из трёх сценариев не аргумент против вайбкодинга. Все три — аргумент за то, чтобы заранее решить, что мы делаем с результатом.
Первое — приложение просит доработки. Появилось новое требование, изменился регламент, понадобился ещё один отчёт. Автор возвращается к инструменту и обнаруживает, что модель не помнит проект целиком, а изменение в одном месте ломает другое.
Второе — что-то отваливается само. Обновилась библиотека, истёк ключ доступа к внешнему сервису, поменялся формат данных на входе. Приложение, у которого нет владельца среди разработчиков, в этот момент просто перестаёт работать, и никто не знает, с чего начать.
Третье и самое частое — автор уходит. Уходит в отпуск, на другой проект или из компании. Вместе с ним уходит единственное понимание того, как приложение устроено, потому что документации нет, а код никто не читал даже в момент создания.
Ни один из трёх сценариев не аргумент против вайбкодинга. Все три — аргумент за то, чтобы заранее решить, что мы делаем с результатом.
Сотрудник навайбкодил рабочий инструмент: что делать
Это главный практический вопрос статьи, и он касается не энтузиаста, а руководителя.
Начнём с масштаба явления. По оценкам 2026 года около двух третей тех, кто пользуется вайбкодингом, не являются разработчиками — это продакты, маркетологи, руководители направлений, основатели. То есть внутри компании такие приложения появляются в отделах, у которых нет ни ревью, ни договорённостей с ИТ.
Дальше начинается то, что в отчётах называют shadow AI. Приложения работают с корпоративными данными, но ИТ-служба о них не знает, их нет в учёте, у них нет владельца и резервных копий. Отчёт Verizon по утечкам данных за 2026 год зафиксировал 858 440 событий, связанных с неучтённым использованием ИИ, — третье по частоте действие со стороны сотрудников. А в опросах ИТ-руководителей 61 процент называют неуправляемое использование ИИ главным барьером безопасности.
Три реакции, из которых работает только третья.
Как выглядит первый шаг третьего пути. Составьте перечень того, что уже есть — обычно хватает опроса руководителей отделов. Для каждого приложения выясните, какие данные оно трогает, кто им пользуется и что случится, если оно встанет. Дальше приложения делятся на три группы. Те, что живут у автора и никого не задевают, оставляем в покое. Те, что работают с реальными данными или на них держится процесс, переносим в управляемую среду. Те, что дублируют существующую систему, закрываем.
Если инструмент решено переводить в разряд корпоративных, дальше работает обычная схема постановки задачи: как описать процесс, роли и данные.
Начнём с масштаба явления. По оценкам 2026 года около двух третей тех, кто пользуется вайбкодингом, не являются разработчиками — это продакты, маркетологи, руководители направлений, основатели. То есть внутри компании такие приложения появляются в отделах, у которых нет ни ревью, ни договорённостей с ИТ.
Дальше начинается то, что в отчётах называют shadow AI. Приложения работают с корпоративными данными, но ИТ-служба о них не знает, их нет в учёте, у них нет владельца и резервных копий. Отчёт Verizon по утечкам данных за 2026 год зафиксировал 858 440 событий, связанных с неучтённым использованием ИИ, — третье по частоте действие со стороны сотрудников. А в опросах ИТ-руководителей 61 процент называют неуправляемое использование ИИ главным барьером безопасности.
Три реакции, из которых работает только третья.
- Запретить. Не работает по той же причине, по которой не работали запреты мессенджеров и облачных дисков. Люди продолжат, просто перестанут рассказывать, и вы потеряете и видимость.
- Разрешить и не смотреть. Работает, пока не случится инцидент с данными или пока на самодельном приложении не окажется процесс, который нельзя остановить.
- Дать легальный контур. Признать, что потребность настоящая, и предложить путь, на котором приложение появляется быстро и при этом видимо для ИТ.
Как выглядит первый шаг третьего пути. Составьте перечень того, что уже есть — обычно хватает опроса руководителей отделов. Для каждого приложения выясните, какие данные оно трогает, кто им пользуется и что случится, если оно встанет. Дальше приложения делятся на три группы. Те, что живут у автора и никого не задевают, оставляем в покое. Те, что работают с реальными данными или на них держится процесс, переносим в управляемую среду. Те, что дублируют существующую систему, закрываем.
Если инструмент решено переводить в разряд корпоративных, дальше работает обычная схема постановки задачи: как описать процесс, роли и данные.
ЧТО ОСТАЁТСЯ У КОМПАНИИ
Приложение, за которое есть кому отвечать
Когда приложение собирается на корпоративной платформе, вопрос «а кто это поддерживает» не возникает отдельно. Оно живёт в той же среде, что остальные системы, с общими правами доступа и общими интеграциями, и обслуживается так же, как любое другое приложение платформы.
По собранному с Nolan приложению формируется итоговое ТЗ и документация на его функциональность, и разработку по этому описанию продолжают дальше — цикл сборки не односторонний. Это ответ на главный страх при работе с генерацией, и его стоит проверять у любого инструмента, не только у нас.
Приложение, за которое есть кому отвечать
Когда приложение собирается на корпоративной платформе, вопрос «а кто это поддерживает» не возникает отдельно. Оно живёт в той же среде, что остальные системы, с общими правами доступа и общими интеграциями, и обслуживается так же, как любое другое приложение платформы.
По собранному с Nolan приложению формируется итоговое ТЗ и документация на его функциональность, и разработку по этому описанию продолжают дальше — цикл сборки не односторонний. Это ответ на главный страх при работе с генерацией, и его стоит проверять у любого инструмента, не только у нас.
- приложение видимо для ИТ и учитывается вместе с остальными
- итоговое ТЗ и документация на собранное приложение
- отечественные языковые модели и размещение в России
Что спросить у сотрудника, который принёс приложение
Разговор идёт легче, если у руководителя есть готовый набор вопросов. Пять штук, и все они не про технику.
Тон разговора важнее содержания. Если сотрудник услышит претензию, следующее приложение вы не увидите. Полезнее относиться к принесённому прототипу как к готовой постановке задачи — человек уже сделал бесплатно ту часть работы, которую обычно приходится вытягивать на интервью.
- Кто им уже пользуется? Один автор, отдел или несколько отделов. Ответ определяет, насколько срочно нужен управляемый вариант.
- Какие данные внутри? Обезличенный набор для проверки идеи или настоящие клиенты, договоры, сотрудники. Это главный вопрос из пяти.
- Что случится, если оно завтра не откроется? Если ответ «ничего», приложение можно оставить как есть. Если «встанет процесс», у него уже есть статус производственной системы, и обращаться с ним надо соответственно.
- Что ты просил его сделать и что он делает сейчас? Расхождение между этими двумя ответами показывает, насколько автор понимает своё приложение.
- Что ты хотел добавить и почему не стал? Самый информативный вопрос. Обычно именно здесь выясняется, что автор уже упёрся в потолок и держит это при себе.
Тон разговора важнее содержания. Если сотрудник услышит претензию, следующее приложение вы не увидите. Полезнее относиться к принесённому прототипу как к готовой постановке задачи — человек уже сделал бесплатно ту часть работы, которую обычно приходится вытягивать на интервью.
Данные: что уходит в модель и где это хранится
Вопрос, который стоит задавать до первого эксперимента, а не после инцидента.
Первое — что попадает в промпт. Одни инструменты получают только описание структуры, другие просят примеры реальных записей, чтобы понять формат. Если сотрудник вставил в чат фрагмент клиентской базы, произошла передача данных третьему лицу, и техническая простота операции этого не меняет. Обработка персональных данных подчиняется 152-ФЗ, и требования действуют независимо от того, генерировалось приложение или писалось руками.
Второе — где живёт готовое приложение и его база. У платформ «текст → приложение» это по умолчанию облако платформы, часто за пределами России. Для внутренней системы с данными сотрудников или контрагентов это обычно сразу закрывает вопрос.
Третье — доступы. Навайбкоденное приложение почти всегда получает широкие права, потому что так проще заставить его работать. Отдельного пользователя с минимальными правами создают редко, а ключи доступа нередко остаются прямо в коде.
Практический минимум для компании выглядит скромно и снимает большую часть риска. Реальные данные в чат модели не отправляем, для экспериментов используем обезличенный набор, для любого приложения с настоящими данными заводим отдельный доступ с минимальными правами.
Первое — что попадает в промпт. Одни инструменты получают только описание структуры, другие просят примеры реальных записей, чтобы понять формат. Если сотрудник вставил в чат фрагмент клиентской базы, произошла передача данных третьему лицу, и техническая простота операции этого не меняет. Обработка персональных данных подчиняется 152-ФЗ, и требования действуют независимо от того, генерировалось приложение или писалось руками.
Второе — где живёт готовое приложение и его база. У платформ «текст → приложение» это по умолчанию облако платформы, часто за пределами России. Для внутренней системы с данными сотрудников или контрагентов это обычно сразу закрывает вопрос.
Третье — доступы. Навайбкоденное приложение почти всегда получает широкие права, потому что так проще заставить его работать. Отдельного пользователя с минимальными правами создают редко, а ключи доступа нередко остаются прямо в коде.
Практический минимум для компании выглядит скромно и снимает большую часть риска. Реальные данные в чат модели не отправляем, для экспериментов используем обезличенный набор, для любого приложения с настоящими данными заводим отдельный доступ с минимальными правами.
Сколько это стоит по факту
В обзорах вайбкодинг почти всегда выглядит бесплатным, потому что считают только подписку. Полная стоимость складывается из четырёх частей.
Отсюда честный способ считать. Вайбкодинг дешёв на первых двух уровнях результата и перестаёт быть дешёвым на третьем, потому что там появляется работа, которую в смете никто не учитывал.
- Подписки на инструменты. Тарифы считаются по генерациям, проектам или пользователям, и на активной работе бесплатных лимитов не хватает.
- Время сотрудника. Основная статья. Человек, который не программирует, тратит на сборку и отладку заметно больше времени, чем кажется в начале, и это время его основной работы.
- Инфраструктура. Где приложение работает после сборки, кто платит за размещение и за внешние сервисы, которые оно вызывает.
- Переделка. Вероятность того, что приложение придётся собрать заново нормальным способом, для третьего и четвёртого уровня из первой таблицы довольно высокая.
Отсюда честный способ считать. Вайбкодинг дешёв на первых двух уровнях результата и перестаёт быть дешёвым на третьем, потому что там появляется работа, которую в смете никто не учитывал.
Два подхода к генерации
Шаг назад от инструментов к принципам. Способов ограничить модель, чтобы она не придумывала несуществующее, всего два, и они дают разный результат.
Ни один подход не лучше другого — они про разные задачи. Свободная генерация нужна там, где само решение и есть конкурентное преимущество. Формальная модель нужна там, где ценность в предсказуемости и в том, что систему кто-то будет поддерживать.
Свободная генерация кода | Генерация в формальной модели | |
Что производит модель | Код на языке программирования | Описание приложения в словаре платформы |
Что ограничивает модель | Проверка человеком после генерации | Словарь платформы — несуществующего в нём просто нет |
Кто проверяет результат | Разработчик читает код | Платформа проверяет валидность описания |
Воспроизводимость | Низкая: тот же запрос даст другой код | Высокая: описание можно прочитать и сравнить |
Потолок возможностей | Практически отсутствует | Ограничен тем, что умеет платформа |
Кому подходит | Продукты со своей архитектурой и своим алгоритмом | Внутренние системы с ролями, маршрутами, интеграциями |
Ни один подход не лучше другого — они про разные задачи. Свободная генерация нужна там, где само решение и есть конкурентное преимущество. Формальная модель нужна там, где ценность в предсказуемости и в том, что систему кто-то будет поддерживать.
Когда вайбкодинг уместен, а когда нет
Короткая шпаргалка, которую можно применить к любой задаче за минуту.
Уместен. Разовая утилита для себя. Прототип, который нужен для разговора и будет выброшен. Проверка идеи до того, как просить бюджет. Обучение — понять, как вообще устроены приложения. Автоматизация личной рутины, которая не касается корпоративных данных.
Не уместен. Приложение, которым будут пользоваться другие люди. Что-либо с персональными данными или коммерческой тайной. Процесс, остановка которого заметна бизнесу. Задача, где нужны роли и разграничение доступа. Всё, что должно жить дольше полугода.
Граница проходит по одному признаку. Если у результата появляется пользователь, кроме автора, вайбкодинг заканчивается и начинается разработка — в том или ином виде.
Полезно проговорить это в компании заранее, до первого спорного случая. Формулировка из одного предложения работает лучше политики на десять страниц, потому что её запоминают.
Уместен. Разовая утилита для себя. Прототип, который нужен для разговора и будет выброшен. Проверка идеи до того, как просить бюджет. Обучение — понять, как вообще устроены приложения. Автоматизация личной рутины, которая не касается корпоративных данных.
Не уместен. Приложение, которым будут пользоваться другие люди. Что-либо с персональными данными или коммерческой тайной. Процесс, остановка которого заметна бизнесу. Задача, где нужны роли и разграничение доступа. Всё, что должно жить дольше полугода.
Граница проходит по одному признаку. Если у результата появляется пользователь, кроме автора, вайбкодинг заканчивается и начинается разработка — в том или ином виде.
Полезно проговорить это в компании заранее, до первого спорного случая. Формулировка из одного предложения работает лучше политики на десять страниц, потому что её запоминают.
Как легализовать самодельные приложения в компании
Практическая часть для тех, кто решил идти третьим путём. Четыре шага, которые дают результат без запретов.
Что даёт такой контур, кроме безопасности. Компания видит настоящий бэклог — тот, который сотрудники уже начали закрывать сами. Обычно это самая точная картина того, чего людям не хватает в существующих системах.
- Договоритесь о правилах эксперимента. Что можно делать свободно и на каких данных. Обезличенный набор и личная рутина — свободно; реальные данные — только в согласованной среде. Правило из двух предложений работает лучше регламента на десять страниц.
- Заведите точку входа. Место, куда сотрудник приносит идею или готовый прототип. Важно, чтобы обращение туда не выглядело как признание в нарушении.
- Сделайте перенос быстрым. Если легальный путь занимает квартал, им не будут пользоваться. Именно поэтому корпоративные платформы со сборкой по описанию оказываются удачным ответом — путь от прототипа до управляемого приложения измеряется днями.
- Оставьте прототипам право на жизнь. Не всё нужно переносить. Часть приложений честно останется утилитами одного человека, и это нормальный итог.
Что даёт такой контур, кроме безопасности. Компания видит настоящий бэклог — тот, который сотрудники уже начали закрывать сами. Обычно это самая точная картина того, чего людям не хватает в существующих системах.
Покажем Nolan на вашем процессе
Свяжемся в течение одного рабочего дня. Без спама.
Опишите задачу — мы разберём ваш процесс и подготовим демо-приложение на его основе
1
Вы оставляете заявку и кратко описываете задачу
2
Мы разбираем процесс или ЧТЗ
3
Показываем демо работающего приложения
Наши продукты:
Программа для ЭВМ «Nolan»
Программа для ЭВМ «CDP.Light»
Программа для ЭВМ «Корпоративный портал»
Компания «Технологии возврата»
3 года занимается разработкой и развитием ИИ
Из описания — в готовое приложение