Профессиональное кодирование и моделирование против вайб-кодирования и вайб-моделирования

ailev · 15.Февраль.2026 21:01:30

Как появляется технический долг при вайб-работе
Некоторое время назад обсуждалась разница между профессиональным кодированием с помощью AI-агента на работе и вайб-кодированием в pet-projects дома. И то же самое – с моделированием. Мой тезис в том, что вайб-моделирование – это по факту моделирование-в-малом, а в контексте моделирования-в-большом – это мультипликатор вреда целому проекту. AI-агент радикально удешевляет не моделирование, а моделирование-в-малом, которое при переносе в контексты моделирования-в-большом радикально удешевляет мультипликатор вреда целому проекту. Вреда больше, и он наносится дешевле!

Пример: как навайбленная “универсальная колонка” превращается в источник чужих проблем. В организации заводят “универсальную” табличку “Контакты контрагентов”. Кто заводит? Это и есть проблема: новичок? “ничейный” (корпоративный, “колхозный”) AI-агент по поручению другого AI-агента? целая команда разработчиков под давлением недостатка времени? Если у модели нет владельца смысла и режима изменений – она обречена стать помойкой, хоть с AI-агентом, хоть без.

В этом месте и работают “по наитию”, вайбят (vibe – “по наитию, по настроению”): делают колонку Address и пишут туда то юридический адрес, то email, то ФИО “контактного лица”, то ссылку на сайт, то @username в “мессенджере” (у каждого этот мессенджер или даже социальная сеть будут своими любимыми, о существовании других мысли не будет). Всё, появился технический долг: поле ввели сейчас, а катастрофа будет потом, когда-нибудь – и не у тех, кто ввёл это поле. Проблема “вайба” в том, что этот технический долг невидим и никаких планов по его искоренению нет.

Санитария: правильные типы правильного уровня общности
Дальше я буду различать уровень общих правил и принципов моделирования для всех предметных областей (мета-мета-модель, FPF как First principles framework), уровень типовых моделей предметных областей (метаУ-модель “как в учебнике”, SPF как Second principles framework) и уровень конкретной ситуации в конкретной организации (метаС-модель “как в ситуации”, TPF как Third principles framework). Это нужно, чтобы понимать, на каком уровне общности мы говорим о контексте и где должны жить проверки, ибо и вы и AI-агент много знаете о мире вообще (мета-мета-модель), но дальше надо знать особенности предметной области (и вы их можете не знать, а LLM в AI-агенте ещё будет как-то знать, хотя может перепутать с каким-нибудь модным подходом из прошлого, а не SoTA из текущего нервного настоящего), а уж особенности организации можете не знать ни вы, ни ваш AI-агент, и это главная засада.

Этот частный провал удобно обобщить в принцип/правило, который работает для любой предметной области, на мета-мета-уровне: “Single-meaning slot”: каждое поле/слот в модели должно иметь ровно один тип значения и один смысл в договорённом контексте; смешивание разных видов значений в одном слоте запрещено. Суть этого неочевидна, ибо звучит как “присваивай полям значения хорошо, а нехорошо не присваивай”, но это утверждение “принципиально”: оно не про конкретную предметную область, а про корректность моделирования с прицелом на моделирование-в-большом (взаимосвязь разных моделей, evolvability целого набора связанных моделей).

Онтологическая инженерия: какие значения вообще существуют в этой предметной области “адрес”? Вместо вайб-моделирования с результатом “поле адреса - Address” вводим:

postalAddress : PostalAddress
email : EmailAddress
contactPersonName : PersonName
websiteUrl : URL
telegramUsername : Username

Далее делаем (машинно)проверяемое ограничение (constraint):

postalAddress – не строка, а структурированный объект (минимум: country, city, street, postalCode).
email должен быть не произвольной строкой, а только принадлежащей множеству адресов электронной почты
websiteUrl должен быть не произвольной строкой, а только URL
… и так далее, указывая способы проверки ограничения (например, country ∈ ISO-3166)

Формат проверяется автоматически, иначе вы сознательно разрешаете случайному мусору маскироваться под “ценные данные, не потеряйте”.

Даже если авторы значений в этих табличках буду разные (низовые сотрудники, а не авторы самих табличек), они больше не могут “не заметить”, что засунули email в почтовый адрес: они немедленно получат ошибку несоблюдения типов (“круглое в квадратную дырку не засовывают!”). Им это ткнут (с разной степенью точности, ибо строгость проверки в следовании стандартам будет неизбежно разная, как и понимание, что там “главный стандарт”), дальше пусть думают – ибо голь на выдумки хитра, локальные интересы “вайба” всё равно будут работать, если их не осознавать:

системы соседей неожиданно требуют “одну строку”, для них команда “временно! Только для отладки!” добавляет addressText. Через месяц это становится source of truth, ибо оттуда было удобно брать значения для трёх разных AI-агентов в ходе вайб-программирования: им не сообщили, что это “временно”! Некому сообщить, и они ж не люди, чтобы сообщать!
пользователям “неудобно”, так что они вместо заполнения ставят N/A, -, unknown, “test@test.com”. Формально тип проходит, фактически смысл умер.
владелец процесса хочет KPI, ему вайбкодят характеристику “заполнено”, чтобы получать значения “заполнено 95%”, далее закон Гудхарта заставляет генерировать мусор, чтобы “удовлетворить KPI”, смысл опять умер.

И вот это – самый нижний уровень работы, типы тут – просто “входной билет”, чтобы можно было хоть о чём-то разговаривать. Формальная проверка типов – гигиена, санитарная проверка, “вымыли ли вы руки перед работой” (а если это не вы, а AI-агент – то проверка того, достаточно ли умна в агенте LLM или правильно ли вы дали промпт, чтобы эта проверка случилась). Правильные типы не спасают от лжи, они спасают от случайности. Всё остальное – вопрос стимулов, workflow, наблюдаемости, проверок и всего того, что трудно подвластно пущенному в одиночное плавание AI-агенту в ходе вайб-моделирования.

“Правильные типы” можно навайб-онтологизировать, но можно знать предметную область – и использовать знание современных методов решения проблем с типизацией (и это надо предусмотреть, LLM в AI-агенте может “знать, но не использовать” без отдельного напоминания в промпте “посмотри SoTA как это сейчас делается”). Так, с ContactPoint есть распространённый паттерн: выделять «точку контакта» как сущность с типом канала (kind) и валидируемым значением (value). На уровне предметной модели это может называться ContactPoint/ReachabilityEndpoint/CommunicationChannel – имя тут вторично. На уровне общих правил моделирования важно другое: одна сущность моделируется по-разному в разных ситуациях: есть несколько строго типизированных вариантов + явные проверки для каждого + версионирование вариантов и организованный “переезд” (миграции) между версиями этих вариантов + разные views (отображения, нотации) под протоколы для разных интересов разных проектных ролей. Тогда исчезает соблазн делать “универсальные поля” и называть все сущности сверхобобщениями с одинаковыми именами для самых разных типов этих сущностей.

Инварианты: чеклисты того, что вы будете проверять при любых изменениях
Типы – это входной контроль. Но чтобы модель жила в непрерывных изменениях (а она будет изменяться!), нужны правила, которые переживают эти изменения. Инварианты – это наши чеклисты, conformance checklists. Их можно включать в проверки при изменениях – и если какое-то изменение нарушило инвариант, оно не проходит.

Дальше делаем инварианты уровня уже не мета-мета-модели (что должно быть истинно всегда, то есть ограничение, которое сохраняется при любых изменениях как модели, так и данных во всех предметных областях), а мета-модели (предметной области):

инвариант целостности контактного адреса контрагента: Для каждого объекта CounterpartyContact все поля имеют значения своего типа; перегрузка/overloading (несколько типов значений для одного поля) невозможна.
инвариант экспорта контактного адреса: в экспортируемом (которое для обмена данными) представлении контактного адреса запрещены “универсальные строки” как конкатенация строк-значений из полей, возможны только строки значений, разнесённые по полям и прошедшие проверку целостности. “Универсальные строки” допустимы только как views/проекции для объекта CounterpartyContact, а не как “источник истины”.

А дальше надо говорить о спецификациях обмена и совместимости, без этого никак! Именно этот шаг часто пропускается при вайб-моделировании. Протокол обмена и совместимости – это какие сообщения считаются корректными для импорта/экспорта, какие изменения формата считаются совместимыми, и как переводим старые данные в новый вид. Это про использование онтологии, принципов, инвариантов. Скажем, “Сформированное сообщение контрагенту считается корректным, если: есть counterpartyId и есть хотя бы одно из полей адреса для каналов связи: email или postalAddress или websiteUrl”, иначе это “пустой контакт” – сообщение для такого контакта или отклоняется, или попадает в очередь на “ручной разбор” (в зависимости от процесса). И это тоже можно замерять для оптимизаций: например, “доля сообщений, улетевших на ручной разбор”.

Даже после всех введённых ограничений и инвариантов будет то, что нельзя свести к полностью формальной и “умозрительной” (без выхода в реальный мир) “проверке типов”, ибо в жизни много сбоев случается не только из-за типов, но ещё из-за неправильных допущений о текущем сценарии/workflow, интересов ролей, культуры с её иногда абсолютно иррациональными предпочтениями, реализующихся экзистенциальных рисках (вроде “вы тут моете полы на тонущем Титанике”), регуляторике. Например:

Что считать “достаточно хорошим адресом” для конкретной страны в конкретный период времени (возьмите 20 лет назад, прикиньте, что там будет через 20 лет, если темп изменений сохранится).
Нужна ли детализация до здания, или надо точнее (квартиры? офиса? рабочего места?), то самое “на деревню дедушке Константину Макарычу” – а как надо-то?
Какие сценарии (как happy path, так и epic fail) реально важны, чтобы не пропустить их подробно обложить чеклистами.
Email может быть синтаксически корректным, но не доставляемым (bounce, блокировки, домен умер, mailbox full).
Почтовый адрес может соответствовать стандарту, но быть непригоден для доставки (контрагент его выдумал специально так, чтобы вы ему ничего не присылали!).
Имя человека – правильное, но не идентифицирующее (однофамильцы, разные языки/транслитерации, смена фамилии).
… и много подобного.

Так что “проверяемость” там формальная (синтаксис/тип), семантическая (это действительно то, что вы думаете – и все это именно так и будут трактовать), операционная (оно работает в процессах: доставляется, используется кем-то, поддерживается и выживает при изменениях). Контроль типов – это нижний порог, настоящая катастрофа – семантическая, операционная и организационная проверяемость. У AI-агента проблемы будут именно с этим, именно в этом сейчас нужна помощь людей, занимающих самые разные проектные роли, имеющие самые разные проектные интересы и отсюда самые разные потребности в моделировании (viewpoints). Собственно, “смысл” живёт у ролей, не бывает “осмысленности вообще”, это всегда чья-то (агента в роли, то есть у него это “для чего-то”) осмысленность. Если у вас “вайб”, то вы не можете передать ролевой “вайб” как набор преследуемых интересов LLM, это совсем не “по наитию”, это надо уметь делать.

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

Вайб-кодирование, вайб-моделирование, вайб-письмо – это ОК, когда вы работаете с самыми начальными идеями. Затем надо повышать точность языка и гарантировать соответствие целям не локального вашего проекта, а общего командного: работать не на “нашу систему, систему моей маленькой команды” (часто – “команды из себя, любимого, и всё”), но большой команды. Если AI-агент повышает вашу производительность x10, то позаботьтесь, чтобы это была вписанная в коллективную работу производительность, а не x10 производительность по привнесению ошибок в общую работу.

Мало сделать, надо чтобы потом оно ещё и жило и наносило непоправимую пользу с минимальным количеством вреда и постоянной адаптацией к дрейфующим обстоятельствам. Вайб – это приватизация выгод и сдвиг издержек на окружение. Быстро сделал без заботы о системном целом, без учёта ситуации “разработка-в-большом” – выгоду получили вы и сегодня, а возникшие проблемы (технический долг, называйте как хотите) оплачивают завтра соседи и “будущий вы”. Долги накапливаются, вайб возможен – но если от “по наитию” (собственно вайба) перейдёте к нормальной разработке.

Моделирование-в-большом против вайб-моделирования
Дома “на одного” всё ОК, “олимпиадное программирование, моделирование”, programming/modeling-in-the-small. Проблемы начинаются с программирования и моделирования (онтологизирования тоже!) “в большом”, в случае коллективной разработки, а сейчас ещё и коллективной постановки проблем. Я когда-то много об этом писал, вот ещё девять лет назад, в 2017 году “Ключевое тут различие, конечно, “моделирование-в-малом” и “моделирование-в-большом”, та же “нептолемеевскость”, водораздел между персональным и общественным”, LW-моделирование/онтологизирование/программирование "в большом": ailev — ЖЖ (и там ссылки на много других моих постов об этом). Да-да, “нептолемеевскость”, где я писал в “” (Птолемеевская модель человека: ailev — ЖЖ, 2017):““Человековость”, культура, мышление живут “промеж людей”, они не центрируются на человеке. “Человековость” оказывается нептолемеевской. С мышлением нужно разбираться не в ситуациях “я сижу и размышляю”, а в ситуациях совместного действия. Переходить от сольных танцев ума к более сложным групповым культурным формам. Сначала синергия (увеличение требуемой характеристики за счёт удачного сочетания свойств взаимодействующих объектов, не путать с системным эффектом/эмерджентностью), а потом вверх, вверх по системной холархии – и вот она, эмерджентность, мы имеем шанс получить новое качество, которого на предыдущем системном уровне не было. Но это трудней, много трудней. Ибо вся сложность сольной работы сохраняется, групповая работа или даже работа всего человечества не слишком облегчает индивидуальный труд”.

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

В случае вайб-кодирования вам просто надо дать достаточный контекст – и вы получите приличный код. Если этот контекст уже есть в виде кода, то вам счастье. Если контекста недодали, то программа будет работать, но не будет решать поставленную задачу (ибо “телепать контекст на расстоянии” не может ни человек-кодер, ни машина-кодер, никакая телепатия тут не сработает). То же происходит с моделью. И вы должны дальше понимать, как поставить задачу! FPF вроде как должен помогать делать ровно это. Но беда, если вы не понимаете предметную область: для новичка в предметной области невидимы её проблемы, неизвестно, какие будут важные элементы контекста. Конечно, AI-агент с FPF всё это учтёт, если сообщить. Но это ж надо догадаться сообщить! И тесты: как вы или AI-агент (даже с FPF) догадаетесь, что там должно быть в тестах не только в конкретной вашей предметной области (метаУ-модель), но и в конкретной вашей ситуации (метаС-модель)? А вдруг там “политические расклады”, “отсутствие политической воли” и прочее такое? Что делать будете вы, и что делать будет AI-агент (даже если он с FPF)?

Когда табличка при помощи AI-агента делается инженерами или менеджерами, не проходившими резидентуру программы рабочего развития (то есть людьми, не разбирающимися в уровнях мета-моделирования), с типами в заголовках обычно беда, а точность языка нулевая (омонимия, метонимия и всякое такое). Дальше всё, каюк. Табличка есть, а пользоваться нельзя. Тот, кто её делал, хоть как-то пользуется сам (грубо говоря, в поле “адрес” пишет, например, фамилию, почему бы и нет! “На деревню дедушке Константину Макарычу” как раз вот это самое!). Проблема начинается, когда каждый такой сотрудник себе навайбкодил мета-модель (шаблон таблички – это ведь мета-модель), а потом они обмениваются моделями (заполненными табличками), и имена колонок в них всех – сверхобобщения, например, и это только одна из типовых ошибок моделирования, “не та лексика” (метонимия: вместо таксона низкого уровня называется имя таксона высокого уровня, вместо “мыши” пишут “зверь”). И всё, тут каюк. Появляются отдельные файлики, описывающие структуру хранения и схему данных (ибо из коллективно используемых табличек это вычитать невозможно), но они тоже у каждого в своём формате и интерпретируют смысл по-своему, исходя из интересов проектной роли. Потом делается заявление, что давайте навайбкодим каждый свой переходничок, а формат неважен – и у каждого переходничка будет своя хитрая ошибка, вайбкодят и вайбмоделируют ведь непрограммисты.

И это мы ещё не обсуждаем семантику! Только онтологию формата текстового документа.

Раньше люди ошибались медленно, теперь AI-агент без знания нюансов ситуации и надлежащих проверок позволяет ошибаться быстро (поручение выполняет не дни, а минуты или часы в крайнем случае), убедительно (её на это специально тренировали!) и массово (потому что дёшево!). В инженерии “быстрые черновики” – норма. Вопрос в том, как в инженерии черновики превращаются в надёжные хорошо работающие изделия (даже не информационные модели!).

Парето-фронтир вайб-режима в пространстве проектных ситуаций
Когда речь заходит о том, где AI-агент и вайб-стиль с ним работы помогают улучшить, а где помогают развалить работу, полезнее думать не просто дихотомиями “индивидуальный - коллективный проект”, “знакомая - незнакомая предметная область”, а в терминах пространства характеристик проектной ситуации. Ситуация тогда моделируется как точка в пространстве этих характеристик. Типовые характеристики как оси для этого пространства (минимально достаточные, чтобы не врать самому себе, что “контекст уже задан и доступен AI-агенту, я ему дам вайб, а он пусть моделирует”):

Цена ошибки: во сколько может обойтись неверная модель/код (деньги, сроки, безопасность, регуляторика, репутация).
Наблюдаемость и проверяемость: есть ли быстрые и однозначные проверки результата как “гипотезы”, приёмки результата работы, или обратная связь размыта, отложена, получается только “в модели” (а не “в мире”).
Доступность контекста: контекст формализован (артефакты, логи, стандарты) или живёт в головах и “неписаных правилах” (и вы можете даже не знать, что именно надо спросить или померить).
Сцепленность по интерфейсам: сколько ролей в каких командах, сколько систем должны понимать “одно и то же” одинаково (и сколько невидимых потребителей у ваших результатов “вайба”).
Скорость дрейфа мира: как часто меняются термины, рабочие процессы, модели и базы данных, ожидания, как дорого сохранять совместимость моделей при неминуемых “переездах” с версии на версию (“миграциях”).
Требование к агентности: достаточно “посчитать по данным”, или нужно добывать недостающее знание действиями (расспрашивание, зондирование, эксперименты, другие интервенции).
Неопределённость интересов: насколько конфликтны интересы ролей и насколько трудно выразить это в постановке задачи (договорились ли о характеристиках, по которым определяется итоговое качество решения и о процедурах замера этого качества).

В этом пространстве почти всегда есть несовместимые характеристики, которые нельзя максимизировать одновременно:

скорость получения результата против гарантий корректности;
автономность работы против контролируемости последствий;
универсальность формулировок против однозначности смысла.

Лучшие достижимые компромиссы в этом пространстве обычно формулируются как Парето-фронтир. Парето-фронтир зависит от агента, вокруг которого разворачивается ситуация в проекте. “AI-агент в один запрос” и “команда с дисциплиной (явные слоты, ограничения, инварианты, тесты, версии, миграции + review)” – это разные агенты, у них разные области оптимальности. Точно так же отличаются человек-новичок и человек-профи в предметной области, независимый AI-агент с вызовом по одному промпту и AI-агент с заранее понятными проверками и workflow, AI-агент с инструментами доступа к данным контекста (репозитории, банки данных, логи, трекеры, протоколы тестов/испытаний) и AI-агент с доступом к реальным людям и реальным датчикам (например, видеокамерам, чтобы понимать происходящее).

Отсюда практический вывод про вайб-режим, работу в режиме “по наитию”. Вайб – это почти всегда выбор точки, где минимизируются человеком элементы “не по наитию”, а “через волевое усилие, потому что надо”:

расход на добычу контекста,
расход на проверку (типовую, семантическую, операционную),
расход на вписывание результата в коллективные интерфейсы.

В одиночной работе это иногда рационально. В работе-в-большом это превращается в мультипликатор ошибок: каждый оптимизирует под локальный контекст, а платит команда, клиент, инвестор (в разных долях, но платят!). При этом сдвиг на AI-агента не исключает этот “вайб” и у самого агента: неестественный интеллект без специально принятых мер (которые тоже принимаются не “по наитию”, не “по интуиции”, а по знанию!) вполне может действовать “без протокола”, “по наитию” – своему нечеловеческому “наитию”, по своему неестественному “вайбу”, по своей нейросетевой “интуиции”.

Чеклист быстрой самопроверки (примените его к последнему вашему “вайб-моделированию/кодированию”, насколько оно было разумным):

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

Если высокая цена ошибки + плохо с доступностью контекста + плохо с проверками + высокая сцепленность – вайб опасен, сразу работайте “по-взрослому” и имейте для этого квалификацию. Да, это трудно. Но новичок без медицинского образования, который проводит операцию на открытом сердце, нажав кнопку очень умного робота “сделай там всё по уму” может провалить дело даже не из-за незамеченной ошибки робота, а из-за того, что не будет знать, как помыть перед операцией правильно руки, чтобы настроить этого робота, как подготовить пациента к операции, куда потом девать свежеоперированного пациента по окончанию операции, как проверить, что всё-таки прошло правильно – пациента ведь самого не спросишь об успехе в момент окончания работы робота!

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

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

Сближаем модели с реальностью: интервенции и агентность
На моих семинарах по FPF я тоже подчёркивал, что с ростом знаний FPF удаётся задействовать много более полно. Но это только zero and first principles, а там ведь ещё second principles, “разъезд моделей в коллективе” (моделирование-в-большом) случается ещё и на уровне third principles (в текущих руководствах это мета-мета-модель, метаУ-модель и метаС-модель. Подробно я давал этот материал с уровнями моделей даже не в руководствах, а на семинаре по мантрам, ибо мантры/канвы/уравнения-в-типах как раз с этими уровнями моделирования работают). Сдвинуть всё на роботов, чтобы они думали вместо вас, не получается. Нужна у роботов агентность не такая, как сейчас (“долбиться в одну точку” известной части контекста), а другая – пойти и сделать какую-то интервенцию, чтобы прозондировать неизвестную часть мира, “снять туман войны” (как в играх, где территория непонятна какая, пока её не исследуешь). Причинное мышление только так устроено, без интервенций/зондирования (активных измерений) – не работает! Просто визуализацией немного данных добудешь, нужны эксперименты, условия для них надо создавать!

Конечно, в этом направлении международная инженерная и научная мысль работает давно, и работает очень активно, это мейнстрим. А мы выводим на такую работу резидентов (сначала надо, чтобы они перестали глядеть себе в пупок, перестали заниматься исключительно “личным развитием”, новый сорт эгоизма, перешли таки к рабочему развитию, затем этот взгляд должен находить какие-то важные объекты внимания – из первых принципов, то есть на основе мета-мета-модели, но затем надо зондировать, активно добывать информацию, “системное мышление начинается с того момента, когда ты встал со стула и пошёл спрашивать, пошёл делать какие-то действия и смотреть на результаты”, я всегда этому учил, многие помнят эти мои слова. Steve Blank в своих книгах писал “идеи для вашего стартапа находятся не в этом здании!”, смысл там ровно такой же: вставай и иди, добывай информацию активными действиями. И поставка решения в бесконечном цикле развития для развитых такая же: после получения решения надо собрать информацию, что там произошло в мире с этим решением и вокруг него!

В текущей ситуации AI-агенты пока этого всего не могут делать, агентность там игрушечная, интеллект в существенной мере disembodied, так что сдвинуть на них полностью разработку и кодирование нельзя, для себя, любимого, это ещё как-то будет работать, а в коллективной работе без присмотра со стороны вполне знающих и умеющих людей – рассыпется. Так что AI-агент (особенно с FPF) помогает, конечно, но не всем – и очень трудно объяснить, почему не всем. “Из той же мучки, да не те ручки” тут многое объясняет. Senior programmer не вайбкодит, он программирует при помощи AI-агента. С Junior может быть не так, потому как senior заботится не только о коде (это AI-агент позаботится, о коде), но и обо всём остальном – постановка задачи прежде всего, архитектура. А Junior будет видеть только код, режим олимпиадного программирования “задача на один час, на выходе несколько строк кода, проверка решения автоматическая”, programming-in-the-small.

Я сам ведь тоже считаю, что “умозрительно” (языковые модели, “из текстов и картинок, рассуждающие на текстах и картинках”) с миром не поработаешь, ибо надо разбираться с эффектами – делать эксперименты. AI-агент, конечно, шикарная штука, но ему бы руки, чтобы что-то делать, и ноги – чтобы это делание происходило в нужном месте, а “умозрительно”.

Что я имею против вайб-моделирования?
В интернете когда-то бродил мем, что он хорош тем, что никто не узнает, что за компьютером где-то там далеко сидит щенок и участвует в интернет-дискуссиях. Ах, наивные времена. Если в вашем коллективном проекте участвует не щенок, а AI-агент под управлением щенка, ситуация может быть печальнее: у вас будет провал моделирования-в-большом (не путать с кодированием-в-большом, когда AI-агент сможет изучить кодовую базу. В моделировании у вас не кодовая база, а кусок реальной жизни, ваш бизнес. И не факт, что он хорошо отражён в текущих моделях, а добавочка от AI-агента вам правильно отразит ещё неотражённое). Это означает, что основное узкое место: связь с жизнью и интеграция. Даже если AI-агент чрезвычайно умён, он не получит живой контекст бесплатно. Контекст защищён ролями каких-то других живых и не очень живых агентов с их интересами, временем (время – деньги!) и недоверием, ибо мало ли какие паразиты рвутся к людям и другим AI-агентам забрать информацию, а взамен ничего не дать ни её владельцу, ни проекту в целом. Поэтому ускорение генерации модели без ресурсов на добычу контекста – это ускорение самообмана.

У вайб-моделирования от AI-агента, вызываемого щенком по принципу “промпти и молись” (prompt and pray) огромные проблемы с заданием нужного контекста, ибо AI-агент получить себе этот контекст сам не может, он ведь в реальной жизни, а щенку неведомо, что туда включать. Сказать, что “вот тебе всё, что я нашёл в мире” – это дать много мусора, который даст AI-агенту много шума, будет отвлекать, значительная часть времени уйдёт, чтобы разобраться с этим ненужным шумом, в котором вполне может не оказаться сигнала. Щенок выучил промпт (запомнил, что надо делать: нажимать большую красную кнопку с надписью “сделай мне красиво”), а дать важные объекты в жизни не может, ибо не подозревает об их содержании. Не может проверить результат работы AI-агента. Не может оценить, как это влияет на проект, ибо все эти байки Голдратта про “глобальный максимум”, руководства МИМ про коллективную разработку и всё подобное ему незнакомы. Не может проверить, появились ли от результатов его работы какие-то проблемы, ибо ненамётанный глаз проблем, которые замечают профи, не видит. Вайб – это режим, где вот это всё провалено. А если не провалено – то это не вайб-моделирование, а обычное моделирование с благословенной помощью от AI-агента (и ещё большей помощью от AI-агента с FPF).

Не надо надеяться на чудо, чудеса будут после решения следующих проблем (но не надейтесь на то, что можно дальше ничего не делать, “подождём”, ибо вайб-моделируете вы сейчас, а не когда-то потом):
– коллеги начнут разговаривать с AI-агентами как с людьми. Пока же там расизм: если “чужой AI-агент” припрётся к вам с расспросами по поводу того, как устроены ваши рабочие процессы, то вряд ли вы будете тратить время на подробный разговор. Так что рабочий контекст (ситуация) для даже добропорядочного AI-агента в существеннейшей степени останется недоступен, AI-агент будет работать в платоновской пещере, пытаясь определить происходящее в мире по теням на стене.
– много агентов будут согласовывать свои решения между собой, чтобы не обращаться к людям. Это коллективная агентская разработка, без неё никуда (хотя уже выяснили, что “гениальность” лучше даёт один сверхсложный агент, но вот масштабирование – много маленьких агентов попроще, без разделения труда на много специализированных агентов с масштабированием будет сложно).
– агентам дадут выход в реальный мир, причём не только датчики (видеокамеры), но и возможность что-то прикупить из инструментов, получить доступ (хотя бы на время) к телу робота, чтобы сделать какое-то действие в физическом мире. Без этого не будет ни экспериментов и новых данных для принятия решений, новой проблематизации, ни оперативного исправления самой ситуации – модели будут оторваны от жизни.

Но если всё это будет, то люди как прокладки между AI-агентами и жизнью нужны не будут. Так что занимайтесь пока честным моделированием, работайте с помощью AI-агента с усилением со стороны FPF, и будет вам (временное, оно всегда временное) счастье.