Как избежать "спагетти-кода" при вайб-кодинге

Есть много вариантов, как не терять контроль над кодом в эпоху вайб-кодинга, когда кодобаза разрастается с бешеной скоростью ввиду высокой производительности LLM (а не разработчиков). См. картинку из предыдущего поста. Итак, что работает для меня:

🔷 На старте проекта начинать с заготовок и шаблонов (для типовых проектов я сделал то, что называется "boilerplate", и подсовываю его агенту. И он из этого уже продолжает делать лучше, чем если придумывает проект "с нуля"). Здесь определяется и структура проекта, и используемые фреймворки/библиотечки, и какие-то соглашения об именовании, расположение разных блоков. Учитывая, что модель — completion, она склонна "продолжать" в том же духе.

🔷 Завожу .cursorrules, AGENTS.md, CLAUDE.md, и там описываю, что хочу использовать, а чего не хочу. Прописываю, что, например, pathlib предпочтительнее классических os.path, а asyncio нужно использовать при параллельных вызовах всего и вся. Там же указываются нужные паттерны, типа DRY, требования объявлять переменные и константы вверху файла, избегать inline-импортов, требования к UI/UX. Если в .cursorrules указать mandatory, оно грузит рулзы из файлов лучше, чем из глобальных проектных и пользовательских. Плюс их можно использовать и для Claude Code, и для Cursor.

🔷 Изменения стараюсь делать инкрементально, небольшими порциями. Смотрю, что меняется после каждого раунда (у меня теперь обязательное ревью изменений, на больших проектах перестал делать auto-accept). У меня, кстати, ещё ни разу нормально не сработал большой рефакторинг ни на одной LLM. Особенно неудачно рефакторит Codex. Я вообще перестал им пользоваться.

🔷 Для сложных задач стараюсь задавать траекторию изменений: "хочу решить такую-то задачу. Ожидаемый результат такой-то. Менять вот это вот здесь, сделать раз, два, три. Проверяй линтером изменившийся файл, запусти, посмотри в логах ошибки...". То есть крупными мазками определяю, что нужно сделать. Что делать тактически — решает агент. Что должно получиться и в каком порядке — я.

🔷 После большого блока изменений делаю цикл рефакторинга. С этим лучше не затягивать. Код всё равно теряет консистентность и эффективность. Его надо причёсывать время от времени. И чем раньше, тем лучше.

🔷 Документирую структуру проекта после изменений. У меня два типа .md-файлов: PROJECT_DETAILS.md и DEV_DETAILS.md. В первом высокоуровнево определено, как работает проект, какие API эндпоинты доступны, из каких модуле состоит, структура проекта, особенности деплоймента и подобное. Во втором — детали по отдельным сложным алгоритмам и "внутренностям". Когда начинаю какую-то большую фичу или переделку, закидываю их в контекст, заряжаю планировщик на задачу, и по полученному плану уже генерю код.

🔷 Пишу тесты. Тесты — моё спасение при рефакторинге (которого много). Это чуть ли не единственный вариант не нафакапить в большом проекте и сразу обнаружить регрессии при переделках и "улучшениях". Чем старше проект, тем больше возможностей что-то отломать в процессе вайб-кодинга. Поэтому тесты должны появляться вместе с фичами (я обычно чуть опаздываю, но всё же делаю их теперь на фичи). Буквально на днях распиливал огромный проект на плагины и платформу. Если бы не тесты, вообще не представляю, как бы проверял, что ничего не сломал.

—

Да, есть еще отдельная категория проектов. Я их называю "disposable" (типа, "одноразовые"). Навайбкодил → "Accept All" → Запустил → Получил результат → Удалил. На них я так не заморачиваюсь.

Поделитесь, что работает у вас.

Почти вся моя текущая активность крутится вокруг GenAI для решения технических задач. Моя лента - сплошной технический поток: RAG-пайплайны, Claude Skills, MCP-интеграции, бенчмарки моделей, оптимизация промптов. Понимание и использование этих инструментов реально прокачивают продуктивность в разработке. Но в какой-то момент поймал себя на мысли, что, кажется, я слишком зашорено и узко смотрю на GenAI.

Кодописание или генерация красивых картинок — это лишь одно из применений GenAI. А ведь есть ещё бизнес аспекты, саморефлексия, анализ собственной активности, автоматизация персональных задач — и именно здесь, кажется, лежит настоящая точка роста для человека.

Мне всё больше кажется, что с таким взрывным ростом AI-инструментов боттлнеком становятся не навыки их использования, а фантазия человека: как сочетать их между собой, под какие неочевидные задачи адаптировать. Здесь надо думать уже своей головой, придумывать нестандартное применение привычным инструментам и сервисам, используя их для неочевидных сценариев и нетехнических задач. Самый простой пример — когда нетехнические люди натравливают Cursor на свою Obsidian-базу с заметками, транскриптами звонков и личными отчётами, и получают локальный RAG, который достаточно неплохо функционирует и ищет по личной базе знаний. Мне, если честно, такое даже в голову не пришло, потому что я бы сделал привычный RAG с понятным postgres.

В общем, признавая свою слабую насмотренность и фантазию, начал "насматриваться" по сторонам. И случайно познакомился с ребятами из AI Mindset (они, кстати, тоже в Португалии сейчас). Эти доблестные доны формируют экосистему AI-практиков и работают на стыке технологий, бизнеса и креатива. У них принципиально другой подход: не «как модель работает технически», а «как прокачать своё мышление и креативность с использованием современного AI». По сути, это про построение глубоко персональных систем: от ассистентов до того, что сейчас называют «личной операционной системой». Формат у них - лаборатории, где участники учатся через интеграцию AI тулов для решения конкретных практических задач, а не через пассивное слушание (с выключенной камерой, как это обычно бывает).

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

А пока, просто захотелось рассказать про их инициативу, что-то, что выходит за пределы стандартной "технички". Если заинтересовало, смотрите, как у них всё работает
- на сайте https://aimindset.org/ (здесь их последняя лаба)
- в канале https://xn--r1a.website/ai_mind_set

Каждый раз залипаю на их иллюстрации и видосики.

Рождественская идея для IDE:
«Адвент-календарь багов». Каждый день открываешь новую критическую багу в проекте.

Сюда же идёт адвент-календарь CISO или разработчика ядра Linux.

Будет не скучно.

Cursor commands

Все слышали про cursorrules, и, наверняка, уже используете их у себя в проектах. Но рулзы — это штука непредсказуемая. Иногда IDE не цепляет их, даже если в Rules Type явно указано "Always" или "Always Apply". Да и удобнее, порой, самому закидывать в контекст какие-то знания о внутренностях проекта, когда нужно выполнить запрос ad-hoc.

Сегодня, например, мне надоело писать SQL запросы в Redash для аналитики продукта, и я смастерил себе в курсоре команду sql. Пишешь в чате:

/sql какие у нас бэкпорты пофейлились со статусом prerequisite

и оно за тебя пишет правильную sql кверю к postgres, идёт в БД, вытаскивает записи, анализирует и возвращает сразу то, что нужно.

Что такое /sql? В каталоге .cursor/commands/sql.md, в котором у меня что-то типа

---
description: Query the ELS Backporter PostgreSQL database (read-only access)
---

## How to Query

Use the db_query.py script:

source venv/bin/activate
python .cursor/commands/scripts/db_query.py "YOUR SQL QUERY HERE"

Or for interactive mode:
python .cursor/commands/scripts/db_query.py

## Business Context
...

## Table Relationships Overview
...

## Core Entity Tables
...

## Database Views
...

## Common Query Patterns
...

---

## User Request

$input

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

Минут 40 я потратил, чтобы сделать такую команду + вспомогательный скрипт, который физически ходит в БД, и выполняет кверю (здесь сразу можно позаботиться о readonly и других штуках, типа как вернуть 1 миллион записей). Но зато теперь через чат спрашиваю свою postgres базу о любых хитросплетениях судьбы.

Как вы, наверное, уже поняли, просто ссылки на схему данных или код не достаточно для text-to-sql, потому что код не отражает бизнес-сущностей и не говорит на языке землян.

---

На что похожи команды в Cursor? Правильно, на Skills /commands в Claude. Потому что это одно и тоже. Поэтому и делать их можно универсальными сразу, чтобы использовать в обоих агентах.

А MCP в Cursor я перестал использовать, потому что — зачем? Написать MCP, имея доступ к API — дело нескольких минут. Именно в Cursor'е MCP выглядит как пятая нога (лишний уровень абстракций). Вместо условного Jira MCP можно просто кинуть в каталог commands/ ключик в .env, сделать jira.py и описание команды (скилл) jira.md, который будет ходить в Jira API с помощью этого скрипта, и вытворять немыслимое, не ограничиваясь возможностями Jira MCP. А MCP можно оставить на те случаи, когда агент ничего кроме них не умеет цеплять в качестве тулов.

В общем, commands (скиллы) — это классная штука для ad-hoc использований в чате агента. Удобно создавать, удобно расширять, и удобно хранить рядом с проектом (или глобально под все проекты).

Cursor подвел ваши "итоги года".
https://cursor.com/2025

Пару миллиардов токенов пожёг.
А как прошёл ваш год с Cursor?

Новый Cursor, теперь "банановый": как я рисовал комиксы (часть 1/3)

Расскажу, как я задумал генерить обучающие комиксы для ребенка. И как у меня сначала не получилось, а потом — получилось.

Началось всё позавчера: подумал, что я никогда не работал с графикой в GenAI на уровне API, а Nano Banana Pro вполне годится для такого рода экспериментов, почему бы не попробовать.

Вообще, идея появилась после того, как я подсмотрел у одного интересного человека в сториз, что теперь школьникам можно генерить персональные учебники. Любую дисциплину можно было бы объяснить в примерах, основанных на интересах ребенка (не вычисление углов и площади абстрактного треугольника, а, скажем, задачки, где используется терминология из Geometry Dash, что-нибудь типа посчитать площадь группы спайков, орбов и портала на уровне). Да ещё и интерактивно.

Думаю, сделаю серию обучающих комиксов, где буду объяснять материалы следующего года школы. После серии попыток сделать сценарий на 6-7 страниц, понял, что идея плохая, потому что формат не подходящий. Но вот сделать комиксы просто с интересными фактами или забавным нарративом, и при этом процентов на 30 обучающим — это уже в формат коротких комиксов вполне укладывается. У меня ребенок любит комиксы Dav Pilkey (но там всё прикольно, а пользы -- 0), поэтому захотел сделать что-то такое же по стилю, но со смыслом. Правда, по стилю нано банана меня обломила, сказала, что так не можно, авторские права и всё такое. Поэтому я придумал свой стиль ;)

OK. Открыл Cursor. Сделал в нём новый проект и начал формировать пайплайн под серийное производство комиксов )) Сгенерил директорию с документами, которые описывают базовый контекст и основные этапы продакшна (kid_profile.md с предпочтениями, style_guide.md с общими стилями, characters.md с описанием персонажей, page_layout_template.md с гайдами по дизайну страниц, comics_planner.md с пайплайном, task_and_goals.md с заданием) + reference_characters.png с так называемой "библией персонажей" — референсный файл с персонажами в разных эмоциях, диалоговыми "облаками", стилями и цветовой палитрой. Завёл директории под результат, логи, скрипты и будущий web app для просмотра/чтения.

Придумал два персонажа-антагониста: Mr. Trash (умный, но саркастичный енот) и Pegion Brain, глуповатый голубь, который считает себя суперумным, и постоянно попадает из-за этого в неприятности. Как полагается, создал детальное описание персонажей через GPT-5.2 в characters.md, дальше детально определил стили: как ситуативно персонажи появляются в комиксе, какие обязательные элементы должны быть у обоих (например, у голубя должен быть шлем с надписью IQ=<бесконечность>). В файле page_layout_template.md разработал варианты лейаута страниц: сколько и каких блоков ("панелей") могут появляться на странице, какие блоки бывают, как показывать фон и т.п.

Следующим шагом — создал скилл, который умеет генерить одну картинку в Nano Banana Pro и OpenAI ImgGen по заданным характеристикам (чисто посравнивать). Просто в чат закидываешь "Эй, сгенери мне много нарисованных долларов, буду на них визуализировать! Сделай картинку 16:9 в 4K. И используй Google модель" и оно конвертит это в CLI параметры скрипту, а тот дергает API нанобананы про или openai. Очень удобно. Но для комиксов вариант оказался вообще не рабочий. Позже расскажу почему.

comics_planner.md задает воркфлоу - цепочку действий: что и в каком порядке делать, где нужен human-in-the-loop. Например, сначала создаётся каналог нового комикса в определенной структуре, генерится сценарий script.md по новому комиксу и просит меня прочитать, я его читаю, если нужно - исправляю, потом говорю - продолжай, пайплайн переходит к следующему этапу и генерит лейауты страниц с диалогами, форматированием и общим стайл-гайдом. Я читаю страницы, исправляю, если нужно, и/или говорю - всё ОК, сгенери картинки. И оно мне генерит финальные картинки с помощью скилла.

Продолжение здесь.

Новый Cursor, теперь "банановый": как я рисовал комиксы (часть 2/3)

Продолжение. Начало здесь.

В этом месте стоит отдельно рассказать про главную беду генерации картинок для комиксов (а точнее — много разных бед). Самое сложное оказалось — сохранить одинаковость и серийность персонажей при генерации изображений для серии запросов. Например, я генерил 6 отдельных страниц комикса, на каждой было от 4 до 7 панелей/блоков. Енот получался то жирный и с маленькими глазами без белков, то худой и с человекоподобными глазами, то вообще не енот, а какое-то космическое существо, то ...кхм...человек?! При этом, должен заметить, использовал я референсное изображение и style_guide.md для всех запросов. Два дня сидел с этим. В итоге, вот что помогло:

1. Уменьшение суммарного системного промпта для генерации страниц до 3-4K токенов максимум, со всеми деталями по персонажам, описанием лейаута, стилями и сценарием для страницы. Это оказалось самым сложным. Данную проблему я объяснил себе бюджетом внимания модели, и его приходится рационально использовать в запросе. Это не языковая модель, где можно отправить инструкцию в 60K токенов и она неплохо всё учтёт.
2. Сами персонажи должны быть описаны максимально детально и красочно, чтобы даже Стиви Уандер мог нарисовать их по описанию. Вплоть до "миндалевидные глазные белки" и "У голубя — 2 крыла. Не три руки. И не одна.". Думаю, кто-то, кто профессионально занимается подобным продакшном, продаёт эти промпты, потому что с ними приходится прилично повозиться.
3. Модель постоянно забывает детали, внутри сценария страницы нужно время от времени напоминать ей, что у голубя непременно должен быть шлем и бабочка, а у енота — сумка. Да, все эти правила описаны в style_guide.md, который является частью системного промпта, и да, на референсной картинке голубь со всеми нужными атрибутами, но модель упорно продолжает это забывать на части панелей.
4. Сильно улучшило, когда я все инструкции, стайлгайд и характеристики перенес в system_instruction API "нанобананы", а в контентной части рядом с референсной картинкой стал отправлять только "Edit this image according to instructions". До этого я отправлял стили в системном промпте, а вместе с референсной картинкой отправлял сценарий страницы, и это плохо работало.
5. Разница между 1K/2K/4K картинкой — в деталях прорисовки (и цене), но не точности результата. То есть текстура прорисована лучше на 2K, но если енот жирный, а голубь — без шлема, то они будут и на 4K жирные и без шлема.
6. gpt-image-1 vs nano banana pro, это как сравнивать океан на картинках Айвазовского с рисунками океана детей-первоклашек. OpenAI ещё очень далеки от того, чтобы модель можно было использовать для генерации сложных изображений по описанию и референсу. Только в сравнении познаётся крутость "бананы про". MidJourney мне было лень тестировать. Может она тоже крутая. Особенно со всякими ControlNet'ами.
7. Поиск баланса между детализацией описания и длиной промпта — это основной челленж. Здесь нужно сидеть и экспериментировать. Ко второму комиксу у меня вроде стало получаться.
8. Опытным путём установлено, что идеально, когда на странице не больше 5 панелей (лучше — 4). Чтобы комикс был похож на настоящий, расположение панелей я задаю в лейауте и предлагаю модели самой выбрать, какой лейаут в каком случае лучше (на этапе дизайна сценария и страницы).
9. Скилл генерации изображения пришлось заменить на скилл генерации серии изображений, который запускает скрипт, и ему в параметрах передается, какие страницы генерировать, соответствующие сценарии страницы, стайлгайд, и прочие параметры. А скрипт в цикле вызывает API с одинаковыми параметрами, только разными описаниями/сценариями страниц.

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

Начало. Продолжение.

Новый Cursor, теперь "банановый": как я рисовал комиксы (часть 3/3)

Окончание. Начало здесь.

Да, и по контенту: я по наивности сначала думал, что можно попросить модель придумать классную идею, как, например, объяснить ребенку простые числа или площадь/периметр, но с креативом в этом случае у неё туговато (GPT-5.2 и Opus 4.5). Поэтому я придумывал ключевую идею, что и как хочу — сам, а дальше уже прошу расписать сценарий/нарратив и диалоги — LLM (с этим одинаково хорошо справляются и GPT-5.2, и Opus 4.5).

В итоге получился следующий пайплайн и серийность: я задаю идею и гайдлайны по теме в файле task_and_goal.md. Например, "хочу сделать комикс, который рассказывает про топонимы, которые часто путают, вот тебе их список. Давай сделаем, что Pegion Brain телепортируется с помощью своего телепортера в виде консольного GameBoy, но всегда не туда, а Mr. Trash его спасает.", закидываю его в чат, и говорю -- поехали. В этом файле есть ссылки на описание всего пайплайна и соответствующие файлы с описанием инструкций и контекста. Остальное - как я описал выше. В результате - получаю примерно вот такие слайды.

Время на комикс - минут 15-20 (с итерациями), стоимость - около 6 евро.
А как вы тратите свои деньги перед Новым Годом?

Прыгнуть выше головы

Время, как и пространство — непрерывно. Но людям проще и удобнее думать дискретно и циклами. И сегодня завершается один из тысяч таких, придуманных людьми циклов — календарный год. А завтра начнётся новый год! Ура!

Я читаю ленты фейсбуков, LinkedIn, каналов и все такие молодцы! У всех есть куча подведенных итогов, инсайтов за год, ошибок и выводов из них, и, главное, планов на будущее. Это прекрасно и вселяет надежду.

У меня есть тоже маленькое открытие этого года: я понял, что в профессиональном плане (бизнес, разработка) могу прыгать выше головы. Это осознание пришло постепенно, ближе к концу года, когда начало получаться то, что раньше я бы не то что сделать, даже захотеть не смог. И все эти современные технологии настолько круты и волшебны, что лучшего подарка на НГ и не придумать. Слава Роботам! 🤖

Хочу пожелать всем в Новом Году прыгать выше головы. Всех с Наступающей Селёдкой под Шубой!

🧬 Отреверсил свою ДНК с помощью Курсора

В прошлом году у меня получилось отправить слюни в "23andMe", и расшифровать геном. Получилось не сразу, с третьей попытки, пришлось постараться. Они там как раз в момент, когда я им всё отправил первый раз, удачно подали на банкротство и я думал, что мой kit бесследно исчезнет вместе с результатам и доступами в аккаунт. Также пару раз отличилась португальская почта, потерявшая kit (они в этом — лучшие!). Но всё закончилось хорошо. В личном кабинете появилась запись о том, что всё расшифровано и теперь я могу узнать, сколько во мне монгола.

Только эти развлекательные отчеты из серии "а какой европеец сегодня ты" мне не очень интересны, я бы хотел что-то более научно-медицинское и практическое. У 23andMe более-менее стоящее и полезное стоит от $500 (это дополнительно к стоимости kit'а). Поэтому я просто выгрузил геном в raw формате (16MB), и подумал, что когда-нибудь поковыряюсь с ним, может поищу сервисы, куда можно было бы загрузить его не за такой конский ценник.

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

Мне было лень (и некогда) разбираться в деталях генной информатики, поэтому я доверился GPT 5.2, сказал, что у меня есть вот такой файл из 23AndMe, и хочу сделать скрипт для вытаскивания ценных данных по генам. Дальше было где-то часа два разных итераций, улучшений, изменений, подгрузок внешних справочников и интеграции с AlphaGenome API от Google, и на выходе я получил 600 000+ генетических вариантов, из которых отфильтровалось ~130 клинически значимых, а дальше их я прогнал через вероятностную модель от AlphaGenome (она SoTA в этих вопросах).

Что делает пайплайн:

1. Парсит сырой файл от 23andMe
2. Фильтрует по клинически значимым вариантам (ClinVar, PharmGKB, GWAS Catalog)
3. Переводит из старого генома (hg19) в новый (hg38)
4. Прогоняет через AlphaGenome — свежий API от DeepMind для предсказания функциональных эффектов
5. Верифицирует через NCBI — аллель-специфичные запросы к ClinVar
6. Генерирует отчёты с PGx-картой и списком вариантов для обсуждения с врачом

Получил:
- Фармакогенетическую карту: какие лекарства мне нужно принимать осторожнее и почему
- ClinVar-таблицу с реальными ссылками на заболевания и статусом review
- 5 млн функциональных скоров от AlphaGenome — где мои варианты влияют на экспрессию генов, сплайсинг, связывание транскрипционных факторов и прочие непонятные слова.

Весь пайплайн — ~1800 строк Python. Cursor:
- Написал парсер 23andMe с нуля
- Интегрировал pyliftover, pysam, AlphaGenome API
- Сделал аллель-специфичную верификацию через NCBI (это важно — один rsID может быть и патогенным, и доброкачественным в зависимости от конкретной мутации)
- Сгенерировал Markdown-отчёты с таблицами: персональные рекомендации по питанию, зоны риска по здоровью и прочую ерунду, типа pgx_card файлика со списком генов, влияющих на эффективность, усваиваимость и побочки определенных лекарственных препаратов (его рекомендуют показывать врачам, если те собираются выписать что-то из списка).

Жалко, что все эти технологии не были доступны 20 лет назад, когда я был молодой и красивый. В очередной раз: кодинг-агенты — это мой рекомендасьон.

Claude Code для десктопа

Пока мы все спали, Anthropic релизнул сабж. Сначала я пытался найти отдельное приложение и где его загрузить, но оказалось, что в существующем Claude Desktop появился таб "Code". Там можно заонбордить проект и начать по нему гонять агента. Все традиционно стильно, аккуратно, и эффективно.

Работает исправно. Вот, только что тесты в проекте с помощью него пофиксил.

claude.ai/download

P.S. Зачем он, если есть Cursor или Codex? Я решил, что буду пользоваться ими всеми. Во-первых, у каждого есть свои сильные и слабые стороны (специализация на каких-то определенных аспектах кодописания или кододизайна). Во-вторых, так получается экономнее: можно равномерно распределять запросы между подписочными Codex и Claude + иметь базовый Cursor за 60. Первые два — это скорее про долгие и объемные фичи, которые нужно сделать по ТЗ, а Cursor у меня как ad-hoc тул для всего на свете, или когда нужно хирургически что-то подправить.

Теперь у меня есть классная фоточка, которой можно комментировать посты из серии «…вчера мой друг за вечер навайбкодил копию Salesforce (Miro, Canva, …). Всем SaaS’ам — хана!»

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

Ag3ntum. Тизер
https://youtu.be/dwbacH0DdOw

Тут пояснения.

Ограничиваем агентов в их правах

У мeня возникла абсолютно безумная идея запрыгнуть в красный океан агентов и релизнуть... тоже... агента. В чем же будет его отличие? В том, чтобы не бояться использовать Claude Code со всем его богатым функционалом в продакшн среде, через веб и нескольким пользователям сразу.

Поскольку эта мысль посетила меня в канун Нового Года, то я 31го загадал желание. А 1 января оно сбылось: я открыл Cursor, набросал своё видение продукта, фич, запустил это всё в работу и уже через час у меня был готовый к релизу продукт. Ну...вы, конечно, поняли, что это всё полная фигня, и так оно не работает. На самом деле последние две недели я вайбкодил, перекодил, фиксил, тестил, редизайнил, удалял, снова вайбкодил. Пожёг ХЗ сколько миллионов токенов (спасибо тарифу Max от Anthropic за 180).

В общем, сделал агента, работающего под контролем и обмазанного пятью слоями защиты. Внутри сильно кастомизированный Claude Code, работающий в докере, внутри которого bubble wrap для sandboxing'а файловых операций, виртуальная файловая система, многопользовательская изолированная среда, внутри которого вайтлистинг и блеклистинг по паттернам для файловых операций и кастомные тулзы, ну и все это слегка приправлено LLM промптом (на который меньше всего надежны, но всё же).

Полностью заменил системные тулзы (свой Bash, свой Read/Write/LS/Glob, свой WebFetch) — проверяют куда можно, куда нельзя ходить и что читать. Каталоги монтируются с указанным доступом (r/w, r/o). Есть возможность монтировать каталоги для конкретной сессии (запроса). Агент работает через API, можно Curl'ом отправить запрос, попросив проанализировать логи на серваке, смонтировав в readonly только нужные каталоги и только на время работы запроса.

Multi-tenant: несколько юзеров работают с агентом изолированно, у юзеров своя виртуальная среда (включая переменные окружения, воркспейс, свои каталоги). Сессии юзеров живут в отдельных аккаунтах с изоляцией на уровне ОС, у каждого под сессию создается своя файловая система, которая начинается с /workspace и в неё монтируется всё нужное. У каждого юзера есть persistent каталог, куда можно сваливать файлы на постоянное хранение и они будут доступны между сессиями агента, или куда можно подмонтировать кастомные каталоги как в read-only, так и read-write.

Решил в агенте оптимизировать расход токенов. Посмотрел разные сценарии, типа "вот агент запустил баш команду, сделал вывод в файл, потом запустил cat, потом решил, что надо не cat, а tail, потом ещё какие-то странные действия сделал, и, наконец, выяснил, что файл слишком большой, и надо было всё же head'ом посмотреть, с чего всё началось". Я сделал свой тул Ag3ntumBash, и он сразу перенаправляет всё в файлы, возвращает его размер и, в зависимости от параметров, или первые N или последние N строк. Аналогично решил, что WebFetch слишком неэффективный. Нам часто нужен только контент страницы или статус страницы. Поэтому сделал так, чтобы мой Ag3ntumWebFetch возвращал или markdown версию страницы, или только HTTP заголовок (или всё). Ну и там много чего ещё по мелочам оптимизировалось.

Если говорить про UI, то в том же Claude Desktop мне не хватало файлового браузера. Поэтому я сразу прикрутил File Explorer, где можно работа с файлами в привычном виде: загружать туда пачку файлов для сессии, просматривать примонтированные, и в целом выполнять привычные файловые операции как в "Проводнике".

Я почти доделал интерфейс к локальным моделям, так что скорее всего будет поддержка Qwen и прочих со стримингом. Из того, что сейчас еще не хватает — это безопасная работа через SSH/FTP, чтобы можно было держать под контролем администрирование серверов. И надо подумать, как прицепить стандартную MCP поддержку, потому что то, что у Claude Code "из коробки" — это одна большая "дыра в безопасности". Но пока что это не блокер, можно пользоваться скиллами с запуском пайтоновских скриптов.

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

Проект Ag3ntum.

Шифрование агентских скиллов

На днях меня посетила мысль. И я её начал думать. Мысль о том, что скилл в агенте — это то, что несет бизнес-ценность. Не сам агент, а именно скилл в нём. Сам агент — это просто оболочка, платформа (или что-то вроде ОС), которая уже давно стала обычным делом. Сам по себе агент умеет делать какие-то базовые операции, поддерживать MCP тулы, команды и те самые скиллы. А вот когда нужно автоматизировать конкретный пайплайн обработки документов, или совершать повторяемые действия с внешними ресурсами, это определяется в скиллах. Там же часто лежит ценная информация о том, что, как и почему делать, и что не делать. В каталоге скилла могут размещаться скрипты, база знаний, уникальные алгоритмы и прочие предметы интеллектуальной деятельности.

Сейчас есть миллион ресурсов, которые размещают у себя опенсорсные скиллы. Потому что там это просто файлики с описанием алгоритма работы с API или форматом (по сути, пересказ API или формата файла и небольшая пошаговая инструкция). Поскольку вендоры API заинтересованы в том, чтобы сервисом пользовались, они сами их и выкладывают. Но ценности в них не много. Написать, скажем, свой скилл для работы с Jira или Slack или Telegram у меня занимает минут 15.

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

К чему я это всё. Кажется, что в какой-то момент должен появиться механизм защиты интеллектуальной собственности (лицензирования) скиллов, который технически может быть похож на механизм защиты PHP скриптов от копирования и модификации, которую делают Zend Guard или ionCube. То есть автор делает скилл, заворачивает его в некий зашифрованный формат, подписывает, и назначает формат распространения (можно даже сделать ограничение на число использований, типа небольше 10 раз). А дальше, все уважаемые агенты, будут его расшифровывать и использовать (вероятно, с помощью модуля от той же компании, аналогично как работает Zend Guard / ionCube на хостинге).

Я уже сейчас думаю, не запилить ли такой модуль. Но останавливает то, что тот же Anthropic завтра может объявить, что вот они уже всё сделали, показать новый стандарт, сделать к нему поддержку в Claude Code, и мой вариант станет никому не нужным.

Рандомные мысли про вайб-кодинг как тренд

- Расфокусировка и прототипирование всего и вся: хочется сделать всё самому ("зачем использовать редкие функции SaaS, если можно запилить свой карманный SaaS с UI который удобен тебе, интерфейсом и функциями"). Есть соблазн делать их под каждую задачу. Надо ли?

Каждый второй хвастается своей выросшей продуктивностью и числом реализованных задач, проектов, автоматизации своей жизни, персональной ОС и т.п. Отчасти потеряв связь с реальностью и делая это просто потому, что может (не разделяя "я могу" и "мне нужно"), отчасти из-за FOMO, потому что другие так и живут.

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

- Человек - продакт-инженер. Кажется, что начинаются большие изменения в парадигме работы команд. Раньше три разработчика могли планомерно разрабатывать три фичи продукта, договариваясь, как запилить какие-то совместные интерфейсы, как реализовать API, бэкенд и фронт. Писали ровно столько кода, сколько было нужно для фич. Затем мёржили, резолвили конфликты и получали достаточно управляемый результат. С вайб-кодингом все меняется. Три разработчика фигачат фичи как не в себя, выкатывая миллиарды строк кода с рефакторингами и изменениями общих частей до неузнаваемости. Мёржить такое даже с агентами очень сложно. А уж ревьюить — тем более. Люди в команде теряют понимание кода, и начинают тратить основное время не на разработку, а на "и как нам это всё теперь замёржить в мастер и зарелизить, чтобы оно заработало?!".

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

Это, кстати, конкретно фундаментальное изменение, к которому не каждая компания готова. И вот тут я вижу постепенное начало активного процесса увольнений тех, кто привык работать в "потоке". И, с другой стороны, возможности роста тех, кто заявляет о себе, как о продакт-инженере и берет на себя всю эту оркестрацию и end-2-end разработку большого куска в одно лицо.

Презентации 2.0

Сегодня делал воркшоп по Agent Skills. Решил, что будет неудобно переключаться между презентацией и Cursor'ом, когда нужно будет показывать исходники и процесс работы в чат-окне. Поэтому сделал презентацию по-новому, прямо внутри Cursor'а, в своём любимом олдскульном стиле с мониторчиком из детства и CGI адаптером. Фон сгенерил в Nano Banana, а остальное — Javascript.

Вообще, кажется, что делать презы в PowerPoint в эпоху AI — это уже моветон.