Уютный IT адочек

Пришло время признаться: по вечерам я вайб-кожу. И вот чему я научился. Профессиональный вайб-кодинг — это не когда ты красиво написал промпт, ушёл пить чай, а вернулся к готовому продукту. Это когда код пишет агент, механические проверки делает автоматика, а человек отвечает за то, чтобы всё это в итоге имело смысл. Я не сравниваю 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. И, кажется, главный навык профессиональной вайб-код разработки — не умение заставить агента написать много кода. Главный навык — понимать, где автоматике можно довериться, а где человеку всё ещё необходимо проконтролировать: "Мы точно сделали то, что нужно было сделать?"

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

Я спросил у опуса Верный признак плохого менеджера — пересылать в команду письма от клиента без каких-либо приписок, ну разве что иногда добавляя что-нибудь вроде JFYI. С 25 года появился новый жанр — «я спросил у опуса и <тонна копипасты>». Напишу тем, кто так делает — вдруг у вас ещё не всё потеряно. Друзья, у опуса я могу и сам спросить. Кожаный мешок существует не для того, чтобы перекладывать текст из одного места в другое — он нужен, чтобы приносить ценность и принимать ответственность. К копипасте из LLM можно приложить много ценности: начиная от фактчекинга и заканчивая тем, что вообще убрать копипасту и написать мне в один абзац, что в предлагаете сделать. Префикс «я спросил у LLM» не спасает от ответственности: вас уволят, а опус останется. Всё, что делает этот префикс — говорит команде, что вы не уважаете их настолько, что не готовы потратить даже 5 минут на банальную проверку источников.

Есть особый жанр корпоративной магии: назвать отсутствие решения "выравниванием ожиданий". Собрались, поговорили, все выразили обеспокоенность, кто-то сказал "важно синхронизироваться", кто-то кивнул, календарь стал тяжелее на 40 минут в неделю. Через месяц проблема на том же месте, только теперь у нее есть регулярный слот и владелец без полномочий. Если после встречи не поменялось ни одно ограничение, ни один приоритет, ни один бюджет, ни одна ответственность - это была не управленческая встреча. Хороший менеджмент неприятен именно этим: он превращает туман в конкретику.

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

Пока вы гоняете кодинг-агента в пет-проекте или микро-стартапе на пару тысяч строк, проблем нет: белковый разработчик видит каждый 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). Я уверен, что на первый план будут выходить вопросы обеспечения качества созданных решений с наименьшими затратами. Генерация текста давно стала дешёвой коммодити. Победят не те, чьи агенты быстрее штампуют строки, а те, чья инфра умеет детерминированно и дёшево резать мусор ещё до того, как код дойдёт до ревью.

Да

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

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

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

Размышления на полях. Если ваш vibe product engineer выкатывает по три фичи в день — это круто. Но если посадить в одну кодовую базу больше трех таких пулеметчиков, начинается уютный ад. Вал конфликтов в гите, вечный мердж, бесконечный цикл регресса и перетестирования. Как итог — разработка напрочь встает колом из-за собственной же скорости. Это отлично перекликается с хайповым подходом "tiny teams", где продуктовая команда может состоять буквально из двух-трёх человек. В вакууме стартапа работает идеально. Но в контексте энтерпрайза и крупной кодовой базы вся эта магия разбивается о суровую реальность. Чтобы этот подход взлетел и не похоронил процессы, мы должны задуматься: • Как грамотно нарезать ландшафт компании на продукты, чтобы разработчики не топтались по чужим ногам? • Как распределить ответственность за общую кодовую базу между этими микро-командами? • Как интегрировать продукты друг с другом в условиях постоянных и быстрых изменений? Контракты-то постоянно меняются, но их нельзя пускать на самотёк. • И главное: как драйвить масштабные проекты, затрагивающие множество продуктов, и не потерять ту самую хваленую скорость? Будем посмотреть.

«Нейронкам нельзя верить, они галлюцинируют и пишут откровенно кривой код. Я тут один раз попробовал сгенерить функцию — потом на ревью потратил больше времени, чем если бы писал сам. За ними нужно контролировать каждую букву!» ...уверенно заявляют нам люди, которые не глядя тянут в прод гигабайты npm-пакетов и ни разу в жизни не открывали исходники подключаемых зависимостей. Получается потрясающая картина. Мы безгранично доверяем абстрактным васям из интернета, устанавливая сотни чужих библиотек, но мгновенно включаем режим параноика, когда пару строк пишет ИИ. Нет ли в этом банального двуличия? Кажется, за всем этим снобским ворчанием про «некрасивый код» скрывается тщательно маскируемый страх потерять свою значимость. Классический айтишный луддизм: попытка защитить свою экспертизу, обесценив новый мощный инструмент на основе одной неудачной попытки. Пожалуй, лучшее, что можно сделать сейчас — перестать отрицать реальность. Нейросеть — это такой же инструмент, как и чужая библиотека. Да, у него есть погрешность, и его нужно уметь готовить. Но чем быстрее мы перестанем защищать свою песочницу и научимся управлять этим экскаватором, тем выше будет наша реальная ценность.

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

Новый раздел гайда — ИИ в управлении знаниями https://pragmatic-km-guide.ru/practices/ai-km/README.html Технологии ИИ развиваются стремительно, игнорировать их уже не получается. Устоявшихся, «залитых в бетон» стандартов в индустрии еще нет, но есть успешные современные практики и выявленные подводные камни, которые нужно знать и учитывать при проектировании решений. Спасибо ИИ Ardor за проведённую аналитику и полноценный контрибьют в наш гайд. Как вам оформленные идеи? Какой у вас опыт с ИИ в управлении знаниями?

🤖 ИИ 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-работа руками виртуального инженера. Пользуйтесь на здоровье!

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

Новости про отзыв западных сертификатов и веерные блокировки хостингов окончательно стали рутиной. Если отбросить абстрактные разговоры о беспокойстве и посмотреть на ситуацию через язык прагматики, мы увидим планомерный демонтаж той сети, которую мы знали. Глобальный интернет изначально строился инженерами на принципах доверия, прозрачности и отсутствия границ. Сейчас этот фундамент методично уничтожается в угоду геополитике. Иллюзий быть не должно: блокировки доступов к репозиториям, закрытие облачной инфраструктуры и отзыв сертификатов — это не случайные сбои, а целенаправленная изоляция. Западу стратегически выгодно технологическое отставание целого региона, и ради этого они готовы рушить базовые протоколы связности. В свою очередь, эти действия создают идеальную почву для внутреннего закручивания гаек. Логика железобетонная: внешнее давление легитимизирует бесконечное усиление ТСПУ, DPI и строительство «суверенного» периметра. От чего по-настоящему бомбит, так это от осознания жестокого парадокса. Крайними в этой игре политиков с их глобальными макроцелями остаемся мы. Глобальная сеть гибнет, и никого наверху совершенно не волнует, что миллионы людей просто хотят общаться, работать и обмениваться знаниями без заборов. С нами никто не собирается считаться. В итоге огромная часть нашей инженерной и менеджерской энергии уходит не на созидание и рефлексию над новыми технологиями, а на изобретение сложных костылей для преодоления искусственно созданного трения. Полного отключения рубильника, скорее всего, не будет, но нас ждет долгий дрейф в «сплитинтернет». Глобальный веб перестает быть базовым правом. Он становится неудобной, требующей постоянных технических навыков привилегией для тех, кто готов ежедневно пробивать стены ради связи с миром. А массовый пользователь осядет в комфортном, но наглухо изолированном национальном супераппе. И самое ироничное (и трагичное), что строить эти стены и этот суперапп, скорее всего, придется кому-то из нас.

Пришло время признаться: я уже некоторое время вайбкожу на проде. И вот какие выводы для себя сделал. Профессия, которая идеально стыкуется с новой эрой в IT — это не разработчик (вам хана), не девопс (вам тоже, как ни удивительно, хана) и не тестировщик (вам хана чуть попозже). Профессия будущего — это технический продакт-менеджер. Сейчас поясню. Агенты уже вполне неплохо справляются с написанием кода, тестов и рутиной вроде «сходи в сервис Х через MCP и запиши туда саммари нашего диалога, переведя на клингонский». На них реально построить SDLC и получать вменяемый результат, закрывающий потребности бизнеса. Да, остается открытым вопрос качества архитектуры, удобства рефакторинга и склонности агентов ломать легаси. Но уже сейчас можно уверенно сказать: агент — это джун с охренительным кругозором и бесконечной работоспособностью. Как менеджер, я не вижу критической разницы: делегировать задачу не самому надежному джуну или агенту. Один фиг — нужно обкладываться тестами, четко понимать, чего хочешь, внятно это артикулировать и погружаться в ключевые точки принятия решений. Как и при любом делегировании, я не снимаю с себя ответственность за результат. Я продумываю фреймворки, процессы ревью и страхую риски. Те же вопросы, которые я задаю разработчику: «хрен ли ты тут накодил?», «а про откат миграций не забыл?», «какие кейсы покрыл тестами?» — я адресую агенту. И он отвечает не хуже мясного сотрудника. И ровно так же, как с кожаными мешками: иногда агент оказывается умнее (кругозор шире), а иногда ты — опытнее (или просто знаешь нюансы контекста, которые забыл скормить в промпт). В итоге на первый план выходят всего три скилла: лидерство, умение читать простыни текста и умение задавать правильные вопросы. И хороший технический продакт — это как раз средоточие того, что остается востребованным. Маркетинг, онбординг, монетизация. Ответственность за результат. Высокоуровневый контроль продукта, интерфейсов, архитектуры и надежности. Лидерство и таскинг всего этого цирка с конями. Учитесь читать и задавать вопросы.

Птичка на хвосте принесла. Российские хостеры начали убивать аккаунты (вместе со всем, что на них было), ссылаясь на 126 ФЗ. Другая птичка говорит, что подобное уже происходит, если детектят трафик для телеграм прокси или vpn в какой-либо форме. Как именно происходит детекция - птичий совет пытается выяснить. Но совершенно точно не стоит держать что-то похожее на телеграм прокси или ВПН на одном аккаунте со всей остальной инфрой.