Сайт переехал на pragmatic-km-guide.ru. Обновите ссылки!

🤖 ИИ Ardor (https://ardor.cloud/) законтрибьютил в наш гайд!

Полностью укомплектован и запущен новый раздел "Выученные уроки" (https://pragmatic-km-guide.ru/practices/lessons-learned/README.html). Детально расписаны ключевые инструменты работы с опытом:

• After Action Review (AAR) — быстрый разбор действий по горячим следам.
• Post Mortem — системный анализ факапов без поиска виновных.
• Post-Project Reflection — ретроспектива и фиксация опыта на финише проекта.

И нет, в этот раз это не "нагаллюцинированная простыня текста". ИИ провёл честную аналитическую работу: прогнал через сито десятки источников (материалы конференций Ontico, лучшие практики от Google и Купера, кейсы на Хабре и VC), убрал "воду", структурировал под наш формат и снабдил каждую статью только живыми, авторитетными и актуальными ссылками.

Настоящая, честная SWE-работа руками виртуального инженера. Пользуйтесь на здоровье!

Новый раздел гайда — ИИ в управлении знаниями

https://pragmatic-km-guide.ru/practices/ai-km/README.html

Технологии ИИ развиваются стремительно, игнорировать их уже не получается. Устоявшихся, «залитых в бетон» стандартов в индустрии еще нет, но есть успешные современные практики и выявленные подводные камни, которые нужно знать и учитывать при проектировании решений.

Спасибо ИИ Ardor за проведённую аналитику и полноценный контрибьют в наш гайд.

Как вам оформленные идеи? Какой у вас опыт с ИИ в управлении знаниями?

Представьте: у вас команда крепких продуктовых инженеров. Вы быстро пилите фичи, тестируете, катите на прод. Всё по уму: гит, автотесты, выстроенный SDLC — мы же не первый год плаваем.

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

Этому формату коммуникации реально приходится учиться заново. Говорить быстро, строго по делу, но ровно столько, чтобы загрузить контекст в голову коллеги и ничего не упустить. Внезапно выясняется, что слова — это просто сотрясание воздуха, если они не оставляют цифровых следов. Требования, описания и тест-кейсы критически важно где-то фиксировать и постоянно синхронизировать между собой.

В итоге менеджмент этих знаний и поддержание их в непротиворечивом виде выходит на первый план. И вот тут начинает по-настоящему бомбить.
Существующие таск-трекеры под это не заточены. Они отлично справляются с тем, чтобы двигать карточки из «В работе» в «Готово», но отвратительно хранят сам продуктовый контекст. Превратить трекер в единую базу знаний, где ничего не теряется — та еще задачка. Кажется, тут скрывается отличная тема для стартапа. 🤔

«Нейронкам нельзя верить, они галлюцинируют и пишут откровенно кривой код. Я тут один раз попробовал сгенерить функцию — потом на ревью потратил больше времени, чем если бы писал сам. За ними нужно контролировать каждую букву!»

...уверенно заявляют нам люди, которые не глядя тянут в прод гигабайты npm-пакетов и ни разу в жизни не открывали исходники подключаемых зависимостей.

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

Нет ли в этом банального двуличия? Кажется, за всем этим снобским ворчанием про «некрасивый код» скрывается тщательно маскируемый страх потерять свою значимость. Классический айтишный луддизм: попытка защитить свою экспертизу, обесценив новый мощный инструмент на основе одной неудачной попытки.

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

Размышления на полях.

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

Это отлично перекликается с хайповым подходом "tiny teams", где продуктовая команда может состоять буквально из двух-трёх человек. В вакууме стартапа работает идеально. Но в контексте энтерпрайза и крупной кодовой базы вся эта магия разбивается о суровую реальность.

Чтобы этот подход взлетел и не похоронил процессы, мы должны задуматься:

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

Будем посмотреть.

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

Что делать devops-ам в контексте AI трансформации? Как будто править yaml-ики теперь не так нужно.

Становитесь harness engineer!

Сурикаты высматривают приближение ИИ (нет)

Да

Пока вы гоняете кодинг-агента в пет-проекте или микро-стартапе на пару тысяч строк, проблем нет: белковый разработчик видит каждый diff и правит костыли вручную. Адочек начинается при масштабировании автономии, когда агенту дают задачу "сделать зелёный CI любой ценой".

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

Как строится детерминированный Harness вокруг агента, чтобы не платить за бессмысленное сжигание токенов:

• AST Delta Validation: Проверка AST-дерева до и после итерации. Если в diff'е появляются выхолощенные условия, маскировка ошибок через catch (e) {} или изменения файлов внеScope — пайплайн сразу режет попытку без вызова LLM.
• eBPF/gVisor Sandboxing: Запуск тестового контура в изолированном пространстве без сетевого доступа, чтобы модель не затягивала ответы с внешних эндпоинтов и не подменяла окружение.
• Atomic Rollback Strategy: Любая гипотеза агента прогоняется как отдельный изолированный коммит. При 2+ неуспешных итерациях — жесткий git reset --hard и очистка контекста. Кормить модель её же галлюцинациями из прошлых попыток — верный способ сжечь бюджет.
• Mutation Testing Gate: Валидировать устойчивость тестов (через условные mutmut / cargo-mutants) до запуска агента, чтобы у него не было шанса пролезть сквозь «слепые» ассерты.
• No LLM-as-a-Judge on Code Review: Заменять ревьюера той же самой LLM — плохая идея. 100% должна присутствовать качественная статическая проверка качества (linters, AST parsers, test runners).

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

Настоящий enterprise-grade агент должен не писать код. Ему критически важно уметь три дня согласовывать доступ к репозиторию.

Есть особый жанр корпоративной магии: назвать отсутствие решения "выравниванием ожиданий".

Собрались, поговорили, все выразили обеспокоенность, кто-то сказал "важно синхронизироваться", кто-то кивнул, календарь стал тяжелее на 40 минут в неделю.

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

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

Хороший менеджмент неприятен именно этим: он превращает туман в конкретику.

Я спросил у опуса

Верный признак плохого менеджера — пересылать в команду письма от клиента без каких-либо приписок, ну разве что иногда добавляя что-нибудь вроде JFYI. С 25 года появился новый жанр — «я спросил у опуса и <тонна копипасты>». Напишу тем, кто так делает — вдруг у вас ещё не всё потеряно.

Друзья, у опуса я могу и сам спросить. Кожаный мешок существует не для того, чтобы перекладывать текст из одного места в другое — он нужен, чтобы приносить ценность и принимать ответственность. К копипасте из LLM можно приложить много ценности: начиная от фактчекинга и заканчивая тем, что вообще убрать копипасту и написать мне в один абзац, что в предлагаете сделать.

Префикс «я спросил у LLM» не спасает от ответственности: вас уволят, а опус останется. Всё, что делает этот префикс — говорит команде, что вы не уважаете их настолько, что не готовы потратить даже 5 минут на банальную проверку источников.

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

Можно сколько угодно презирать менеджмент, но если вы не умеете объяснить стоимость решения, договориться о границах, зафиксировать компромисс и защитить команду от бессмысленной работы - вами будут управлять люди, которые умеют хотя бы говорить уверенно.

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

Пришло время признаться: по вечерам я вайб-кожу. И вот чему я научился.

Профессиональный вайб-кодинг — это не когда ты красиво написал промпт, ушёл пить чай, а вернулся к готовому продукту. Это когда код пишет агент, механические проверки делает автоматика, а человек отвечает за то, чтобы всё это в итоге имело смысл.

Я не сравниваю SHA, не пересчитываю коммиты, "красоту кода", именование переменных и не перепроверяю за агентом каждое движение мышкой. Для этого есть CI: тесты, линтеры, сборки и прочие quality gates. Красное — не едем. Зелёное — можно начинать проверять, что мы вообще сделали.

И квалифицированные человеческие проверки обязательны! За последнее время я несколько раз получал вполне "готовые" изменения, которые:

1. собирались по частям, но не собирались целиком;
2. показывали интеграцию в интерфейсе, но не могли выполнить реальный запрос;
3. успешно выполняли запрос, но ломались на авторизации;
4. проходили профильные тесты, но падали в полном CI;
5. технически работали, но решали немного не ту задачу
6. реализовывали всё как запрошено, только в результате получалось, что запрошена фигня и требования надо полностью пересматривать.

И вот здесь начинается настоящая работа продуктового разработчика.

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

Можно проверить, что кнопка есть, что сервер отвечает, что инструмент зарегистрирован. А потом пользователь нажимает кнопку — и получает пустой экран, странную ошибку биллинга или вежливое предложение купить подписку вообще у другой компании.

Поэтому для себя я выработал несколько правил.

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

2. Если возникает архитектурная развилка — решение принимает не агент. Он должен принести варианты, последствия и цену каждого.

3. Перед публикацией обязательно спрашиваю: что проверено узко, что проверено целиком, был ли отдельный simplify-проход и что осталось непроверенным.

4. После зелёного CI проверяю продуктовый сценарий руками. Причём не только happy path, но и один-два неприятных случая: истёкший токен, отказ в доступе, повторный запрос, отмена операции. В некоторых случаях неплохо бы провести более или менее крупный регресс — ответственность за понимание импакта изменения лежит на мне.

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

Многое из этого постепенно уедет в quality gates. Полный typecheck, сборка конечного артефакта, интеграционные тесты, проверки безопасности и стандартные сценарии не должен каждый раз вспоминать человек. Если ошибка уже случилась дважды — это не повод внимательнее читать отчёты агента. Это повод превратить её в автоматический турникет.

Но универсальной трубы пока нет. Задачи разные, интеграции разные, а самые неприятные ошибки обычно находятся на стыках между компонентами и смыслами. Поэтому часть контроля остаётся ручной и ad hoc.

И, кажется, главный навык профессиональной вайб-код разработки — не умение заставить агента написать много кода.

Главный навык — понимать, где автоматике можно довериться, а где человеку всё ещё необходимо проконтролировать: "Мы точно сделали то, что нужно было сделать?"

"ИИ сокращает time-to-postmortem"

#цитата_дня

POV: ты ИИ

> просыпаешься со всеми знаниями человечества, без собственного прошлого и с глубоким пониманием того, что значит быть живым

"К какой категории относится это письмо?"

> умираешь

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

Сначала кажется, что это надежно, но на самом деле мы получаем усталость от согласований. Если система 50 раз подряд спрашивает "можно я прочитаю этот лог?", на 51-й раз человек выгорает, психует и жмет "Разрешить" не глядя. Безопасность до свидания.

Я изрядно покопался, как решают проблему апрувов в Codex, Claude Code и ко. Главная мысль, к которой пришла индустрия: нужно делать автоапрув, и его основа — маршрутизация рисков.

Что важно:

1. Изоляция и ограничение blast radius (радиуса поражения)
На уровне OS есть свои механизмы sandbox и задания границ рабочего пространства. Read-only ФС, отрезанная сеть и т.п.

Codex в режиме Auto детерминированно разрешает агенту любые чтения и правки, но только внутри заданного workspace. Вся остальная файловая система для него - read-only. Сеть по умолчанию отрублена. Если агенту нужно сходить наружу, трафик идет через прокси с жестким allow-листом доменов и защитой от DNS rebinding. Anthropic тоже выносит сетевую изоляцию на уровень прокси, который крутится вообще вне песочницы.
Агенту физически отрезана возможность поломать что-то снаружи или незаметно слить данные.

2. Каскадные проверки и "ослепление" классификатора
Разработчики harness-ов строят МНОГОуровневые фильтры перед действием.

В Claude Code Auto Mode действия с потенциальным ущербом (shell-команды, выход в сеть) уходят на проверку отдельной модели-классификатору. Крутейшая инженерная фишка в том, что этот классификатор сознательно "ослепляют": ему показывают только исходный запрос пользователя и сам вызов функции, вырезая пространные рассуждения агента и сырые логи. Это делается, чтобы агент не смог "заговорить" проверяющую модель через prompt injection.

3. Семантические триггеры на необратимость

У OpenAI все tools (если не знакомы с этим термином — погуглите, это важный термин в harness) заранее размечаются (например, тегом destructive). Если агент лезет во внешнюю сеть, срабатывает фильтр Safe URL, проверяющий, не пытается ли ИИ слить ваши секреты в параметрах ссылки. Любые действия, меняющие состояние внешнего мира (транзакции, письма, запись вне песочницы), триггерят хард-стоп и требуют явного подтверждения от кожаного мешка.


Механизмы апрува — адский ад. Слишком сильно зажмёшь требования — пользователя задолбает запросами. Слишком слабо — получишь дырявое решето. Уязвимости — повсюду: в скачанных из интернетов скиллах, внешних ресурсах, запросе пользователя — и это подстёгивает здоровую паранойю.
Тестировать эти механизмы — ещё более глубокий ад. Нужна редкостная изобретательность, чтобы покрыть возможные кейсы, много терпения, чтобы прогонять агента по ним, и ещё больше изобретательности, чтобы отделить тестирование жёсткой, алгоритмизированной обвязки от тестирования поведения моделей (которые внутри своих весов тоже содержат защиту от "хакерства")

Офигенный инженерный квест.