Итак про агентов. Можно уже делать классификацию их по типу и способу взаимодействия и другим параметрам. Например, выделить группу агентов, которые живут в рамках сессии с пользователем, есть также те, что выполняют задачи по событиям, которые не связаны с вопросами пользователей напрямую. Запуски по тику времени или крону также относятся к событиям. Срабатывание вебхуков, которые вызывают агента (или сам агент содержит в себе http-сервер и обрабатывает внешние запросы) кроме тех, которые связаны с запросами пользователей. Агенты второй группы могут быть консольной утилитой или иметь графический интерфейс или обрабатывать запросы от пользователей через подписку на телеграмм. Разница в описанных двух крупных группах со стороны LLM. В случае запросов от пользователей идут подзапросы от user, во втором случае их нет, только системный промпт и данные от инструментов/навыков - tools/skills. Думаю на следующей неделе расширю эту классификацию и дополню графическими схемами для понимания.

Вайбкодинг и его влияние
Наверное, многим приходилось читать или слышать истории о том, как люди, не являясь программистами, становились вайбкодерами, а их программы, сайты или игры, написанные почти целиком при помощи LLM/БЯМ (больших языковых моделей), внезапно становились успешными: помогали запустить бизнес, приносили деньги и доказывали, что теперь разработчики больше не нужны. Чем больше фантазии у рассказчика, тем смелее примеры.
Из-за таких историй легко поверить, что вайбкодеры скоро заменят всех разработчиков. Но это не первый и не последний случай, когда новая технология обещает радикально изменить профессию. Ткацкие станки не сразу заменили ручной труд, автомобили не сразу вытеснили лошадей и конный транспорт.
Вайбкодинг в таком смысле - это автоматизация части труда разработчика. Отличие в том, что порог входа стал настолько низким, что этим начинают заниматься даже люди, далекие от ИТ-сферы. Они могут получить результат быстрее, но не всегда понимают цену этого результата: архитектуру, поддержку, безопасность, тестирование и ответственность за итоговый продукт.
1. Противники вайбкодинга
Уже встречаются, в том числе на Хабре, статьи о вреде вайбкодинга. В них приводят разумные доводы: если постоянно отдавать написание кода модели, можно отучиться самостоятельно разбираться в разработке. Человек не всегда способен на следующий день повторить то, что ему сгенерировала БЯМ. Вайбкодеров называют кнопкодавами; можно предложить и вариант "массажисты клавиатур".
Но чем эникейщики отличаются от кнопкодавов? По сути, ничем. Мы уже проходили похожий этап: "Press any key to continue" сменилось на "Да, разрешить" и "Да, разрешить все".
Еще один аргумент звучит так: "Можно сколько угодно смотреть ревью, писать запросы в нейронки и все такое. Но если ты сам не пишешь код, ты его и не знаешь". Слишком прямолинейный вывод. С такой точки зрения архитектор, техлид, тимлид, продуктовый менеджер, проектный менеджер и аналитик тоже "не знают код", потому что не пишут его каждый день. Но это неправда. Архитектору не обязательно закрывать задачи разработки из Jira, чтобы понимать устройство продукта, ограничения системы и последствия технических решений.
Слабое место вайбкодинга не в том, что человек не печатает каждую строку. Проблема появляется тогда, когда он не понимает результат, не умеет проверить его и не несет инженерной ответственности за последствия.
2. Сторонники вайбкодинга
Сторонники говорят, что не нужно писать код прямо в чате с БЯМ: нужно пользоваться агентами. Для новой задачи стоит заводить новый чат или отдельный контекст, использовать git и github, разбивать большие задачи на маленькие, сначала планировать, потом реализовывать. Полезно применять spec-driven development, вести базу знаний проекта, добиваться от агента самопроверки, писать тесты, логировать важные действия, не делиться секретами и оформлять повторяющиеся операции как команды.
Это хорошие практики. По сути, речь идет не о магии, а о дисциплине работы с инструментом. Если кто-то скажет, что Claude Code лучше OpenCode или Codex, это уже тема для отдельного холивара, но принцип останется тем же: результат зависит от доступности инструментов, качества контекста и умения ими пользоваться.
БЯМ - это инструмент. Кто-то использует ее для исследования и ускорения разработки, а кто-то пытается забивать ею гвозди. Разница не в модели как таковой, а в постановке задачи, контроле качества и понимании предметной области.
3. Так зачем нужен вайбкодинг и как с ним работать?
За час или два с агентом можно собрать небольшой MVP, решить локальную задачу или написать простую игру. Это правда. Но есть важное ограничение, сложный проект за час не появляется.

Возьмем для примера игру. За короткое время реально сделать аркаду, бродилку, стрелялку или другой легкий жанр для одного игрока. С многопользовательской игрой сложности начнутся быстро: сетевое взаимодействие, синхронизация состояния, защита от нечестной игры, серверная часть, баланс и экономика. Человек все еще может поставить такие задачи агенту, декомпозировать их и довести результат до рабочего состояния, но это уже не один час и часто даже не один день.
Отдельная проблема - качество ощущений. Агент понимает слово "красиво" не так, как человек, а слово "интересно" почти всегда требует ручной проверки, итераций и вкуса. Для игр уровня AAA нужны геймдизайнеры, художники, 3D-моделлеры, сценаристы, инженеры, специалисты по звуку и другие роли. Можно заменить часть работы небольшой командой и агентами, но у профессиональной гейм-студии с сильным процессом результат, скорее всего, будет лучше.
С программами ситуация похожая. Чем сложнее структура и чем больше интеграций, микросервисов, прав доступа, миграций, данных и эксплуатационных требований, тем выше риск, что кодовый агент напишет много кода, но система не взлетит с первого или второго раза. Тесты помогут, но они не заменят архитектурного понимания и знания домена.
Рабочий вариант - декомпозиция задач. Оператор агентов должен владеть контекстом, опытом и базовыми инженерными навыками: видеть слабые места архитектуры, формулировать критерии приемки, читать диффы, запускать тесты, замечать зацикливание агента и вовремя менять подход.
4. Что важно не забыть
Вайбкодинг снижает стоимость прототипирования, но не отменяет ответственность за продукт. Если код попадает в реальный сервис, его нужно проверять так же, как код, написанный человеком: ревью, тесты, безопасность, обработка ошибок, наблюдаемость, документация и понятная история изменений.
Особенно опасны задачи, где есть секреты, персональные данные, платежи, права доступа, инфраструктура или юридические ограничения. Здесь мало получить работающий фрагмент. Нужно понимать, какие данные уходят в модель, какие лицензии у зависимостей, как устроены границы доступа и что произойдет при сбое.
Поэтому вайбкодинг лучше рассматривать не как замену разработчика, а как новый слой автоматизации. Он делает сильного специалиста быстрее, а новичку дает возможность раньше получить работающий результат. Но чем серьезнее система, тем важнее человек, который понимает, что именно получилось и почему это можно выпускать.
Так что да здравствует автоматизация труда разработчиков. Каждому знатоку БЯМ и агентов - побольше токенов, доступов к удобным инструментам и инженерной дисциплины.

Из намеченного начну скоро заниматься стендом для тестов. Тем более, что появился новый Fable 5, думаю, что и OpenAI ответит симметрично. Каким стендом и для каких тестов? Аналог autoresearch от Карпатого. Хочу локально проверять гипотезы, нашел у себя записи о другом типе нейрона, попытаюсь построить на его основе трансформер и возможность переноса знаний из существующих малых llm. Для этого как раз понадобится небольшой стенд. Видеокарты своей нормальной нет, поэтому буду пробовать подобное на llm до 4 млрд параметров. Агент будет подбирать конфигурацию нейронной сети - количество нейронов в слое, количество слоев, функцию нормализации и другие параметры для внимания, кэша, потом проводить адаптировать весы из экстра маленькой модели и проверять. Каждый эксперимент будет записываться в журнале, потом неудачные браковаться, удачные проверяться более углубленно. Что-то вроде эволюции и дистилляции в одном флаконе, журнал будет в обсидиане. Кстати, если кто не знает, в обсидиане есть возможность строить графические карты между отдельными знаниями, а в данном случае записанными результатами экспериментов. Скорее всего начну на следующей неделе. Буду делиться итогами, самому интересно, что может получиться. Структуру будущего нейрона пока раскрывать не буду, скажу только, что перцептрон (единственный нейрон данного типа) способен решить задачу xor. Также из интересного в моих гипотезах есть частичное обучение конкретному знанию нейронной сети. На данный момент это весьма нетривиальная задача и не имеет явного решения.

Перерыв в выкладке информации завершается. Из смешного и недавнего - все-таки начал делать виртуальный мир с саморазвивающимися персонажами, пока только основы, прикручиваю туда llm, ну и так как доступно не так уж и много (локально старая видеокарта на 8 гиг, скорость которой не особо далеко ушла от ОЗУ).

Живая проверка полного цикла. Наблюдал деревню целый игровой день:
- Локальная 350M оказалась непригодна для русского («Олаф слился к старому
холме, но его листья сломались») — переключил дефолт на 1.2B с few-shot
промптом и температурой 0.6: пишет простовато и порой смешно, но канал
работает и модель меняется одной env-переменной.
- Облачный DeepSeek на итоге дня показал класс: «День в деревне выдался
богатым на добычу и сделки: Торин и Борка наперебой охотились на оленей,
нанимали Олафа и Миру для переноски туш… жители разошлись по домам, усталые,
но довольные прибыльным днём» — все факты точные, вытащены из реальных
событий симуляции.

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

Попробовал модель LFM2.5-1.2B использовать в качестве ллм для летописца - механика: на закате каждый житель, у которого за день накопилось 3 и более свежих воспоминаний, осмысливает день, модель получает его журнал и прежние выводы, потом возвращает до 5 обновленных убеждений. Выводы автоматически попадают в контекст диалогов и персонаж в разговоре может сослаться на то, что он понял о жизни.

Торин: «Доставка через контракты спасает, но съедает шкуры: потратил 3 шкуры на две туши» — арифметика сходится с летописью.
Борка: «Места охоты (33,6) и (30,19) стоит запомнить — там есть олени» — координаты из его собственной памяти.
Олаф: «Шкуры — основная валюта для обмена и оплаты» — эмерджентное обобщение, этого нет ни в одном промпте.

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

стоимость монет, наверное, стоит сделать жесткой - 1 золотая = 100
серебрянных, 1 серебрянная = 100 медных, может быть еще ввести что-то для сотни или тысячи золотых?

получил в итоге то, что на скрине. Хотя я думал про какой-нибудь рубин. Ну и как вы все, наверное, уже догадались, названия трав также будут по его инициативе из Руси. Девясил, тысячелистник, крапива, мята, полынь, кровохлебка, хмель, багульник, белена, плакун-трава, разрыв-трава, сон-трава, одолень-трава и прочие... Ну а я что, разве буду спорить с нашим, славянским? Конечно согласился, в итоге мир обрастает условностями, сырьем, профессиями. Осталось еще день-два работы (обсуждаю, что сделать, вместе составляем план, согласую и клод работает) и можно будет уже переходить к мультидеревням. Про самые мультицепочки производства конечно же напишу в следующий раз. И про смешные случаи тоже.

Мир потихоньку развивается в фоне, на основе бесед с кодовым агентом. Сегодня пришлось увеличить скорость передвижения жителей в 3 раза, потому что, как оказалось, очень много времени уходило на перемещение по локациям, а агент мне предложил разместить удобнее дома в деревне, чтобы жителям не пришлось далеко ходить. Забавно смотреть на результаты симуляции агентом, потом правда приходится исправлять поведение, и не всегда так, как он предлагает. Кроме данного проекта также продолжаю делать исследовательскую команду - рисерч тим, встречаю разные варианты в каналах, изучаю, смотрю, что можно еще взять себе. Сегодня нашел время сформировать скилл для обработки технического текста, сделал его двухуровневым. Базовый - прямая формулировка, очистка от риторических конструкций, канцелярита и рекламы. Расширенный - проверка доказательности, статуса реализации, сравнений, причинности, терминологии и измеримости результатов. Например, модель любит писать в стиле: не икс, а игрек, я хочу показать, использует сравнение...

Думаю, что не все понимают, причем здесь какая-то игра и мультиагентные системы. Ответ прост, персонажи с саморазвитием, они учатся новому, потом применяют, по сути - это агенты в мультиагентной системе. Они общаются друг с другом, но у них нет общего оркестратора, то есть это децентрализованная система, но с самоорганизацией и развитием. Научившись делать такую игру, смогу проверить какие варианты и подходы в управлении поведением агентов работают реально. Поэтому и нужны эксперименты, чем и занимаюсь. На текущий момент одна llm предложила варианты:
1) GOAP (Goal-Oriented Action Planning) с личным набором действий - строки реестра с предусловиями/эффектами. Научился - добавилась строчка, планировщик сам строит новую цепочку.
2) HTN (Hierachical Task Network) - иерархические задачи. У ученика путь длинный, у мастера - короткий, так как подшаги стали примитивами и действуют на автоматизме.
3) Процедурная память - не буду расписывать, вроде итак понятно.
4) Обучение с подкреплением по весам полезности - тот самый RL.
5) Правила-классификаторы. Если X, то делай Y
И сделать комбинацию из первых двух вариантов. Я начал сомневаться, спросил другую llm. Та предложила использовать динамическую утилитарность + GOAP/HTN. То есть, если в базе знаний NPC появляется новый рецепт, который начинает оказывать влияние на уровень мотивации. И как только выбрана цель, включается этап GOAP.

Как это решает задачу LitRPG-прокачки
Появление новых действий: Персонаж изучил магию «Огненный шар». В систему GOAP добавляется новое действие с предусловием Есть мана и эффектом Нанесен урон.
Изменение приоритетов: Персонаж поднял уровень магии. Формула полезности «Огненного шара» теперь выдает больше виртуальных очков, чем удар мечом. Персонаж автоматически начинает вести себя как маг, а не как воин, хотя код ИИ вы не меняли.
Эффект памяти: Вы можете динамически менять веса на основе опыта. Если кузнец пошел в шахту и его там побил монстр, вес полезности действия «Добывать руду самому» падает на ноль. Персонаж «понял», что лучше покупать руду у торговцев.

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

Сделал заготовку под скилл ТРИЗ (теория решения изобретательских задач), залил в репозиторий https://github.com/snow-ghost/triz думаю, что основными скиллами также потом поделюсь. На текущий момент реализация позволяет использовать как компактный внутренний ризонинг слой. Для анкеты сделаю, наверное, отдельное расширение. Буду использовать его для агентов рисерч команды после доработок. Скилл можно использовать практически в любом кодовом агенте, сделал обязательную поддержку cursor/codex/opencode/claudecode. По игре продолжаю составлять архитектурную документацию в базе обсидиан, само описание мира, локаций, характеристики, редкость и ранги снаряжения, виды оружия, далее буду расписывать ресурсы, потом перейду к профессиям и навыкам.

Сделал заготовку под еще один скилл - для архитектурного надзора (https://github.com/snow-ghost/arch) Что именно я хочу добиться этим скиллом. Проверки сгенерированного кода моделью на предмет разных нюансов, а именно: дублирование кода, но не то, что можно отловить обычным линтером, а то, что модель генерирует, повторяя уже имеющееся поведение; ручная реализация возможностей стандартной библиотеки или принятой зависимости, позднее добавлю и для использования спек с автогенерацией кода вместо ручной реализации моделью (в которой часто ошибается, например, с обязательностью полей); использование deprecated функций, очень часто модель генерирует такой код, не обращая на это внимания, например, просишь использовать вторую версию библиотеки, а вместо этого код с функциями из первой версии и они уже устарели; нарушение направления зависимостей, циклы и неясное владение состоянием (также добавлю позднее возможность инверсии зависимостей, чтобы уменьшить количество импортов; костыли и локальные обходы, в том числе через regex - когда они явно не нужны; использование абстракций и паттернов без границ, иными словами переусложнение кода. Думаю, что также потом добавлю примеры на разных языках программирования (и зафиксирую в тестах), чтобы было понимание, что и как лечится данным скиллом. По скиллу ТРИЗ идет дальнейшее развитие - оформлены мейлстоун и несколько ишью