Привет, Хабр! Заметил, что в феврале вокруг вайбкодинга взорвался целый шквал новостей. Если коротко, то намечается зрелость вайбкодинга — на смену наивным «промптам» приходят агенты с четкими рамками, правилами и проверками. И этот переход привёл к буре дискуссий о безопасности, ролях разработчиков и будущем софта. Разберёмся, что случилось за месяц и к чему это приведёт.
От вайбкодинга к агентной инженерии
Андрей Карпати объявил следующий этап — agentic engineering. Грубо говоря, вайбкодинг — это когда я даю промпты ИИ и он мне код пишет. А сейчас агентная инженерия — это когда ты собираешь целую систему агентов, которая сама планирует задачи, пишет и правит код, прогоняет тесты, рефакторит… и человек при этом больше ревьюер.
Команды уже обсуждают не отдельный промпт, а контекст (что передать в агенты), разделение задач между ними, цепочки верификаций (тесты, мониторинг, инварианты) и протоколы безопасности.
Текущая мода — агентная инженерия: промпт + чёткие рамки + валидации + ограничения.
Агент = новый сервер (и столько же рисков)
Если ты быстро развернул агента в проде — ты не один такой. И, скорее всего, ты уже в зоне риска. Вот что случилось:
Тысячи открытых инстансов OpenClaw
OpenClaw массово торчит наружу — инстансы слушают на всех интерфейсах, без авторизации. Нашли десятки тысяч открытых установок. Причина — всё та же: вайбкодинг на скорость и дефолты без защиты.
Вредоносные расширения в маркетплейсе
У OpenClaw есть магазин плагинов, и туда уже успели залететь вредоносные пакеты. Агент с таким навыком может:
прочитать файлы,
стянуть токены,
исполнить shell-команды.
Агент работает в твоей среде, с доступом к ключам и конфигам. Это не просто уязвимость — это дыра с руками.
Что с этим всем делать:
закрой внешний доступ (никаких 0.0.0.0),
включи аутентификацию и логирование,
проверяй зависимости и расширения,
ограничь права на уровне ОС и API.
«Вайбкодинг» vs SaaS-паника
В конце января Anthropic выпустил плагин для работы с юридическими документами: ревью NDA, поиск рисков, первичная аналитика. Запустили в Claude/Cowork — и рынок заметно дёрнуло. Акции крупных игроков просели.
Если ваш продукт — просто форма + фильтр + отчёт — будьте готовы: завтра это может сделать агент с доступом к вашим API и CRM.
Что останется за разработчиком?
То, что сложно скопировать:
сертифицированные процессы (GDPR, HIPAA),
доверие и аудит (логи, подписи, трассировка),
проверяемое качество (SLA, гарантии),
безопасная инфраструктура.
Крупная ли «ракета» вайбкодинга – или фейерверк?
Многие ли готовы полностью перейти?
ПО — это всего 8–12% затрат компании. То есть автоматизировать такие вещи как ERP/CRM/ERP может сэкономить пару процентов.
Вайбкодинг — мощный инструмент, но не он решает бизнес‑цели сам по себе. Применение должно быть селективным: там, где без внедрения ИИ убыточно долго, где ошибки приемлемы, где качество можно проверять (A/B‑тесты, фидбэк). Переписывать ядро и жизнь компании из‑за вайбкодинга — большая алчность.
OSS и экономика
Ещё одна любопытная история. Публикация на arXiv «Vibe Coding Kills Open Source» изучает влияние вайбкодинга на экосистему OSS. Авторы доходят до вывода: да, вайбкодинг делает разработку дешевле, но снижает вовлеченность пользователей в проекты. Когда агент сам подцепляет фреймворки и библиотеки, люди меньше читают доки, не репортят баги, не контрибьютят. А ведь многие проекты живут именно за счёт такой активности. Модель показывает: если OSS продвигается только через «любителей нажать на витрину» (stars, доки, issue‑репортеры), массовый вайбкодинг приведёт к снижению новых проектов, ухудшению качества и даже коллапсу платформы — при всех плюсах продуктивности.
Вывод для нас: если мы строим мир, где агенты массово «режут» OSS, нужно думать про новую модель вознаграждения мейнтейнеров. То ли донаты по новому принципу, то ли платные лицензии, чтобы люди имели стимул не забрасывать библиотеки. Иначе со временем база, на которой базируется весь наш «помощник», просто деградирует.
Итоговые тезисы
Вот какие выводы вышли:
Agentic engineering — новый тренд. Вайбкодинг без контроля уступает место системам агентов с управлением и верификацией. Роль DevOps и SecDevOps уже в топе: мы не просто пишем код, мы строим экосистему агентов.
Безопасность. Крутость инструментов не отменяет необходимости защищенных конфигураций.
Софт и агенты. Нельзя упрощать: агенты может выполнять задачи, но платформа живет данными и доверием.
Не вайбкодим все подряд. Мнение опытных — вкладывайте ИИ туда, где нужно ускорение и эксперименты, и где невысоки цены ошибок. Переписывать всё ERP ради 10% выгоды сомнительно.
Поддержка OSS — вопрос. Надо думать, как стимулировать мейнтейнеров, если они работают за лайки.
Ваша ценность разработчика сейчас смещается — от «писателя функции» к «архитектору процессов». С большой силой приходит большая ответственность!
Если вам близка идея «агентов с рамками», то следующий шаг — научиться собирать продукт целиком, а не только генерировать код. На курсе «Вайб-кодинг: создание цифровых продуктов с AI» прокачаете дисциплину AI-прототипирования: интерфейс, логика, данные, сценарии и проверка гипотез — в один рабочий mini-MVP.
Для знакомства с форматом обучения и экспертами приходите на бесплатный демо-урок «Lovable для Product Manager’а: от статичной картинки к кликабельному прототипу с логикой» 18 февраля в 20:00. Участие бесплатное, нужно только зарегистрироваться.
Еще больше бесплатных уроков от преподавателей курсов можно посмотреть в календаре мероприятий.
Комментарии (17)
EmCreatore
12.02.2026 10:04Да проехали уже и агентов.
Сейчас GitHub Copilot в VS Code сам создает субагентов, сам сжимает контекст, сам создает глобальный контекст приложения в постоянной памяти, сам создает виртуальное окружение чтобы защитить от сомнительных пакетов и т.д.
Но только это не сильно повышает производительность , поскольку надо все время следить за диалогом и оперативно менять ход рассуждений. Нельзя просто взять и уйти пить кофе.
Да , вайб есть, но он теперь не такой какой-то.
opusmode
12.02.2026 10:04Cooilot отсталый, я с него потому и слез
Мультиагентный оркестратор в том же kilocode - можно пойти даже пообедать, при нормальном промпте
gaal_dev
12.02.2026 10:04"вайбкодинг делает разработку дешевле"
Кто-то все равно платит и это провайдеры ИИ услуг демпингующие реальные цены (вроде как "победитель" получит все) сжигая миллиарды на токенах. Очень умно с их стороны.
Заинтересованный в увеличении выручки собственной компании глава Nvidia может говорить что угодно о будущей выгоде от внедрения ИИ, но в данный момент инвесторы лишь наблюдают, как облачные гиганты увеличивают капитальные затраты до $650 млрд, а потому их капитализация накануне упала на $1 трлн вместе с котировками акций."
StriganovSergey
Эх, промпты, агенты...
Лучше бы модели обучили правильно diff генерить.
Для экономии токенов и контекста. И ускорения инференса.
Сколько ни пытался заставить отвечать дифами к коду - ересь пишут.
Не попадают в изменяемые строки.
Dhwtj
У меня попадает
StriganovSergey
Подскажете модель?
Запускается локально?
В моих экспериментах и grok промахивался, и локальные модели вроде qwen и прочие.
akardapolov
Гарантированный результат (95%) можно получить только при использовании топовых LLM (Claude, Gemini и GPT). Похуже (70-90% с ручными правками) - тоже вариант, это китайские модели (GLM, DeepSeek, Qwen).
Dhwtj
Claude 4.6 thinking (что-то на богатом, если за деньги)
lexasub
я так понимаю лечат агенты это всякими промтами. Не зря же диффы предлгагаются когда вайбкодим. Ну или это нас обманывают создатели агентов и на самом деле модель переписывает кусок
Bardakan
не понял вашей логики. Во-первых, вы хотите притянуть в llm то, что делается обычным скриптом.
Во-вторых, для того, чтобы сделать diff, модели нужно прочитать все документы, но тогда где здесь экономия токенов и контекста? Наверное, единственный вариант, как вы могли бы сэкономить токены - завести под diff отдельную небольшую модель и/или поднять отдельный mcp.
StriganovSergey
Стандартный сценарий такой ( у меня)
шаг 1
При старте работы в контекст загоняю все файлы проекта и требование внести такую-то правку.
шаг 2
модель генерит ответ в виде готовых полных исправленных файлов кода,
или простыми словами предоставляет текстовое описание:
какие строки кода в каких фалах поменять при ручной правке.
Да, может отдать не весь файл, а какую-то функцию.
Но это не сильно спасает ситуацию.
Шаг 3
протестировать исправление, запросить доработку.
Повторить много раз.
Вот такая выдача модели - полные исправленные файлы кода или текстовые описания исправлений и забивают контекст и требуют значительное время на инференс.
С десяток итераций правок делает контекст огромным.
Если бы модель всегда строго diff отдавала то множество итераций правок накапливало бы меньший контекст.
И сами дифы генерятся быстрее потому что во много раз меньше полного файла кода или описания изменений.
Но сама концепция LLM с ее галюцинациями противоречит строгой структуре диф файлов, в которых нужна абсолютная точность.
Подозреваю, что дело не только в целенаправленном обучении модели генерить дифы.
Нужен некий логический внутренний процесс выверки точно ли он попал в нужные строки и символы.
Вроде внутреннего эксперта - reasoning на тему дифов.
opusmode
А причём тут модели? Моделям пофиг. Индексируйте файлы в векторную базу, возьмите kilocode с кешем и разными режимами вставки и в общем всё.
Вы используете инструменты не по назначению
StriganovSergey
Интересный подход.
Видимо, в таком варианте - история доработки будет находиться не в контексте самой модели, а в авто-пополняемой (по ходу разработки) векторной базе.
Значит, два сервера надо - для модели и векторной базы.
Спасибо попробую.
Bardakan
Все llm грубо говоря представляют собой набор списков неких абстрактных вероятностей для некоторых токенов. Diff - точная задача с конкретным алгоритмом. Т.е. ваша основная ошибка в том, что вы хотите скормить точную задачу модели, в основе которой лежит аппроксимация.
Естественно чем больше контекст, тем меньше вероятность того, что точное решение совпадет с приблизительным.
Да, для некоторых задач приблизительных ответов llm будет достаточно, но это не ваш случай
unclear0122
У меня в agents прописано, что каждый фикс должен быть записан в
issues.mdс id, name, desc, severity, resolution status.После коммита, критические остаются в истории файла, остальные либо в архив, либо в /dev/null.
Diif составляется по
issues.mdочень точно.Не знаю, насколько это экономично с точки зрения расхода токенов, но очень удобно потом искать "помнится, я уже что-то такое исправлял" ...
gun_dose
Зачем? Почему агент не может просто запустить git diff?
StriganovSergey
О, а вот и ответ прилетел.
Да. Добавление позиционных токенов улучшает ситуацию.
Разработчик поменял способ обработки диффов в Cursor и Aider. Точность правок выросла до 10x, но Google его забанил / Хабр