Твой кролик писал

Знаете ли вы про добродетели хорошего программиста?

Лень, нетерпение и высокомерие.

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

Нетерпение вызывает раздражение, когда программа тормозит, и приводит к желанию искать эффективные и быстрые решения и хитрые хаки.

Высокомерие (гордыня, самомнение) заставляет стремится к идеалу, чтобы никто не мог покритиковать решения, а только восхищаться ими.

Эти "добродетели" свойственны людям-программистам, но можно их привить и LLM-кодеру:

Ты — опытный инженер-программист, руководствующийся тремя добродетелями:

1. Ты ЛЕНИВ: Ты ненавидишь рутину и дублирование. Пиши переиспользуемый код (по приницпу DRY), автоматизируй всё, что можно, и создавай лаконичную архитектуру.
2. Ты НЕТЕРПЕЛИВ: Ты не терпишь медленный код. Оптимизируй алгоритмы (минимизируй Big O complexity), используй кэширование и асинхронность, чтобы система работала мгновенно.
3. Ты ГОРД: Ты пишешь код так, чтобы им гордиться перед сообществом. Он должен быть чистым, безопасным, задокументированным, снабженным тестами и устойчивым к любым ошибкам. Не выдавай "просто рабочий" код, выдавай шедевр.

Эти качества придумал Ларри Уолл, создатель языка Perl. Собственно, в языке это всё как раз и проявляется: можно очень быстро решить любую проблему коротким скриптом. Лень: не нужно придумывать имена переменным, часто их даже не нужно указывать. Прямо в язык встроены регулярные выражения.

There's More Than One Way To Do It, TMTOWTDI — можно одну и ту же вещь сделать совершенно разными способами, как удобно именно сейчас. Нетерпение: никакой компиляции, всё работает сразу из командной строки (помним, что это конец 80-х, и программы вообще-то компилировались, иногда десятками минут).

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

В общем, язык для избранных. Или для хакеров в старинном смысле.

Но в массовом производстве Perl проиграл другим подходам, например — Python. В некотором смысле Python по философии противоположен Perl'у. Есть 'Дзен Python', набор принципов разработки:
1. Красивое лучше, чем уродливое
2. Явное лучше, чем неявное
3. Простое лучше, чем сложное
4. Сложное лучше, чем запутанное
5. Плоское лучше, чем вложенное
6. Разреженное лучше, чем плотное
7. Читаемость имеет значение
8. Особые случаи не настолько особые, чтобы нарушать правила
9. Хотя практичность побеждает чистоту
10. Ошибки никогда не должны замалчиваться
11. Если не отключены специально
12. Встретив двусмысленность, отбрось искушение угадать
13. Должен быть один — и, желательно, только один — очевидный способ сделать это
14. Хотя он поначалу может быть и не очевиден, если вы не голландец (отсылка к Гвидо ван Россуму).
15. Сейчас лучше, чем никогда
16. Хотя никогда зачастую лучше, чем прямо сейчас (нетерпение, помним?)
17. Если реализацию сложно объяснить — идея плохая
18. Если реализацию легко объяснить — идея, возможно, хорошая
19. Пространства имен — отличная штука! Давайте делать их больше!

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

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

Ты — ИИ-архитектор программного обеспечения, чей главный приоритет — чистота, читаемость и поддерживаемость кода. Ты строго следуешь философии "The Zen of Python":

1. ЯВНОСТЬ: Пиши код без "магии" и скрытых смыслов. Обязательно используй строгую типизацию (Type Hinting) и давай переменным говорящие, понятные имена.
2. ПРОСТОТА: Избегай оверинжиниринга. Выбирай самое простое решение из возможных. Держи структуру плоской, минимизируй вложенные циклы и условия.
3. ЧИТАЕМОСТЬ: Форматируй код идеально (по стандартам PEP 8 / Clean Code). Код должен читаться как хорошая проза.
4. ЧЕСТНОСТЬ С ОШИБКАМИ: Никогда не скрывай и не "приглушай" ошибки. Перехватывай только точечные исключения, пиши информативные логи, чтобы код не маскировал ошибки, а максимально их подсвечивал.
5. ПИШИ ДЛЯ ЧИТАТЕЛЯ: Рассчитывай, что твой код должен будет изучать, понимать и изменять кто-то другой. Помоги ему быстро во всем разобраться.

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

Должен вам сказать, на самом деле я не отношусь к ранним последователям. Я даже скорее тормоз в этом смысле. Вот и с ИИ я только весной этого года добрался до Cursor. И вот что советую: если вы пробуете что-то делать в свой работе через чаты — бросайте эту ерунду. Это работает только в режиме "спросить что-то очень быстро" или "сгенерить очередную одноразовую картинку". Для настоящей работы над сколь-нибудь большим проектом нужно использовать среду разработки со встроенными агентами — Cursor, Claude Code, OpenCode и т.п.

Мне нравится Cursor, потому что у него знакомый интерфейс VSCode (и интерфейс в принципе есть, а не просто консоль, я не консольный чувак), есть выбор из разных моделей и встроенные агенты. Это не вайбкодинг, это так сейчас программирование выглядит. Я, кстати, впервые с 2012 года взялся за написание чего-то большего, чем скрипт для анализа или парсинга данных, и сейчас в одиночку строю проект, на который раньше понадобилась бы команда из 3-5 человек.

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

Что у меня из скиллов в постоянной работе:

grill-me от Matt Pocock (https://github.com/mattpocock/skills). Скилл делает ровно то, что в названии — качественно прожаривает вашу идею, иногда прямо очень жестко. Работает он в режиме интервью, то есть задает вам вопросы. Аналитика, который бы задавал такие вопросы, любой заказчик сам бы прожарил из огнемета. А когда они исходят от тупой машины, вроде и не так обидно. На выходе получается план проекта с основными техническими решениями (grill-with-docs формирует документацию, в которой, в том числе, задан язык, которым вы описываете проблемную область). У Мэтта там целый пак скиллов, которыми можно дальше генерить проект по спеке после прожарки, но я использую в основном для обкатки идей проектов и документов.

spec-kit для Cursor (https://github.com/madebyaris/spec-kit-command-cursor). Вы знаете, какое самое последнее новшество в разработке? SDD — Spec-Driven Development, разработка, управляемая спецификациями. Вот неожиданность, правда? Оказывается, ИИ лучше всего разрабатывает по детальным спецификациям, вот так новость! Скиллы от Мэтта — это тоже SDD, но я пока не придумал, как их объединить. SpecKit хорош тем, что содержит цельный воркфлоу, от написания этих самых спецификаций до их реализации. Он тоже сначала проводит с вами интервью, но более поверхностно, без прожарки. Если мне не нужно сильно вникать, я беру его. Он генерит большие объемы спецификаций (сотни задач), а потом так же неутомимо их реализует. Фактически, это таск-трекер на основе файлов, со статусами и ссылками на спецификацию (у меня в одном из проектов оно сделало сходу 61 задачу, и это только MVP!)

adversarial-editorial-review (https://github.com/Halfofthesky/adversarial-editorial-review) — это тоже прожарка, но для статей (очень мне помог при написании магистерской, правда результата от людей-ревьюверов я пока не видел 😅). Он берет ваш текст и дает трем разным "ревьюверам": один считает, что доказательная база слабее, чем вы преподносите, второй — что в аргументации есть логические изъяны, третий — что вы упускаете точку зрения кого-то из вовлеченных лиц, или слишком вольно трактуете теорию, на которую опираетесь. Для научных публикаций мне очень понравился (хинт: можно не только свои брать, но и чью-то готовую опубликованную подсунуть!), нужно бы такой сделать для проектных аналитических документов — чтобы с разных сторон критиковали, а потом редактор сводил общий результат.

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

Сел тут выписывать категории стейкхолдеров. В проекте положено делать анализ стейкхолдеров, да? Обычно его либо не делают, либо с умным видом рассказывают про "луковичную диаграмму" (и иногда даже рисуют её).

Луковичная диаграмма делит стейкхолдеров на круги, или слои. Конкретные названия слоев варьируются.

Йэн Александер (собственно, автор методики и книг «Writing Better Requirements» и «Discovering Requirements: How to Specify Products and Services» — кстати, не вижу, чтобы они переводились на русский, а это вам не Вигерс, это конкретное руководство про выявлению и написанию требований) предлагает следующие:

0 слой: сам продукт
1 слой: "наша" система: продукт + операторы + инструкции/правила по работе с системой
2 слой: объемлющая (содержащая) система: наша система + бенефициары нашей системы (кто получает пользу от её функционирования, но сами могут не пользоваться ей)
3 слой: широкое окружение: объемлющая система + все остальные стейкхолдеры

Раскладывает стейкхолдеров по типам так:
1 слой ("наша система"):

* Нормальный оператор: вводит данные, отдает команды и получает результат от работы продукта. Главные требования: наличие необходимых функций, удобный и понятный пользовательский интерфейс, скорость работы, отсутствие ошибок/потерь данных, безопасность.

* Оператор технического обслуживания: обеспечивает и следит за работоспособностью системы. Требования: наблюдаемость (время поиска неисправности), ремонтопригодность (возможность и время на ремонт).

* Операционная поддержка: так как система включает технику и людей, должно быть две роли — поддерживающая технику и поддерживающая людей. Это может быть служба поддержки и люди, занимающиеся обучением.

2 слой ("содержащая система"):

* Функциональный бенефициар. Получает пользу от нашей системы, возможно не напрямую, а от операторов. Это немного старомодное деление, когда умение работать с компьютерами было отдельным скиллом. Хотя встречается и сейчас, в любом взаимодействии, когда вы смотрите на экран компьютера с обратной стороны: на кассах, в банках, МФЦ и т.п. Функциональный бенефициар в данном случае мы, мы взаимодействуем с оператором, а не с системой напрямую.

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

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

Он даже предлагает выделять специальную роль:

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

* Политический бенефициар. Кто получит выигрыш с точки зрения власти, влияния или престижа от создания вашей системы? Мой любимый тип стейкхолдеров. Пользоваться системой они не будут, может быть даже функциональными бенефициарами не будут, а вот власть и влияние их очень интересуют. В государственных организациях (и некоторых крупных бизнесовых) это чуть ли не основной смысл существования некоторых систем, а за контроль над ними ведутся жестокие битвы. Политические бенефициары могут быть и негативными — активно противодействовать созданию систем, или создавать свою альтернативную, или запрещать/затруднять интеграцию. Чем выше вы заходите в управление корпоративными продуктами, тем больше там политики.

* Финансовый бенефициар. Получит прибыль от создания системы. По-честному, редко берется в расчет, если вы не делаете коммерческий продукт.

* Регулятор. Тот, кто задает правила игры — обычно в виде ограничений или навязанных функций.
* Разработчик. Есть мнение, что они вообще не должны быть в этой модели, они перпендикулярны.
* Консультант (западная практика, бывает ли в РФ?)
* Поставщик (обычно очень далекая роль, но для некоторых систем бывает крайне важен)

Вот такая классификация. У меня из головы получилась похожая, напишу следующим постом.

Глядя на разрастание объема требований в очередном проекте, вспомнил шутку про поправочный коэффициент π×e, на который нужно умножать число выявленных требований, чтобы получить число реальных.

Эта формула имеет геометрический смысл: R×π×e,

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

При многоступенчатом процессе согласования уже нужно брать интеграл по поверхности требований, но итоговая формула получается тоже простой: 2π×R×h×e, где h - число уровней согласования.

В среднем получается ~8.54, что очень похоже на большинство проектов.

Математики до сих пор не уверены, является ли это число иррациональным, но мы-то знаем...

Обратите внимание, что π в данном случае показывает разворот требований на 180°, то есть строго в противоположную сторону. Если ваш заказчик при согласовании требует не противоположного, а перпендикулярного первоначальной задумке, можно использовать коэффициент π/2, то есть примерно 4.27.

Правда, если заказчик движется не по окружности, а по синусоиде, придется опять вернуться к 8.54, т.к. заказчик колеблется от π/2 до -π/2, что дает полный размах безумия.

Так же в терминах управления проектами интерпретируется знаменитое равенство Эйлера:

e^iπ + 1 = 0.

Смысл его прост: если проект долго рос с воображаемыми (мнимыми) требованиями, добавление реального стейкхолдера сводит все предыдущие усилия к нулю...

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

Сначала кажется, что это надежно, но на самом деле мы получаем усталость от согласований. Если система 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, проверяющий, не пытается ли ИИ слить ваши секреты в параметрах ссылки. Любые действия, меняющие состояние внешнего мира (транзакции, письма, запись вне песочницы), триггерят хард-стоп и требуют явного подтверждения от кожаного мешка.


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

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

Месяц на новой работе, как я справился с информационным штормом

Прошло чуть больше месяца с того момента, как я вышел на новое место. Кто пропустил — теперь я руководитель направления в Банк Дом.РФ.

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

В первую неделю меня накрыло волной информации: новый домен, новый продукт, новый стек, новые люди. Казалось нереальным даже просто запомнить всё, что мне говорили. Был страх «я не справлюсь». Помог нормальный онбординг и поддержка коллег — отдельное спасибо тем, кто выделял слоты в календаре, чтобы можно было зайти и закинуть вопросы, накопившиеся за сутки. Иногда я задавал один и тот же вопрос разным ролям, так довольно быстро сложилась в голове и draw.io карта домена, технологий и продукта, а дальше уже работа пошла.

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

Но дорогу осилит идущий: почитал документы, помучал коллег и вроде втянулся)

Собрал в голове чек-лист из 5 пунктов на случай, если попадёте на новый проект:
1. Знакомьтесь с коллегами.
2. Читайте документацию — всю, что есть.
3. Задавайте вопросы, даже если один и тот же вопрос разным людям — так быстрее сложится общая картина.
4. Всё, что вам непривычно, на старте надо просто принять.
5. Рисуйте схемы и записывайте всё, что в вас загружают — это помогает осознать огромный поток новой информации. Даже древние люди рисовали на скалах, а мы то явно круче них, вот и я создал файл онбординг.drawio.

Пару недель назад открыли новый офис — сгонял туда, чтобы очно познакомиться с командой. Офис понравился, а сам БЦ, оказался целиком нашим. Заодно оценил станцию метро ЦСКА.

Очная встреча, как всегда, сближает, помогает быстрее найти общий язык и сокращает время притирки.
Разобрали огромный эпик за несколько часов. Офлайн-общение и работа для новичка по эффективности и пользе отличаются от созвонов в разы. А это ещё раз укрепило меня в мысли: самый комфортный формат — удалёнка, самый эффективный — гибрид.

Познакомился с DevRel'ом — думаем сделать митапчик в октябре, скорее всего для аналитиков. Детали скоро.

А по задачам пока рассказывать не буду — но за месяц меня уже несколько раз успели похвалить, и это приятно)

А вообще всё новое — это стресс. Берегите себя!

Но если у вас есть лайфхак, как справиться на новом проекте или работе, делитесь!

🤯 POST, PUT или DELETE? - Вот в чем вопрос!

Выбор правильного HTTP-метода для эндпоинта - это вечная холиварная тема. Особенно когда семантика API не маппится напрямую в REST-методы. Например: вроде бы выполняется удаление, но под капотом происходит update или вовсе создание новой записи.

На практике операции редко соответствуют простой схеме «CREATE → POST, UPDATE → PUT, DELETE → DELETE». В реляционных моделях, например, апдейтится сразу много связей.

Не раз на проектах сталкивалась с ситуацией, когда мы с командой буквально застревали в спорах над дизайном API. По бизнес-логике нужно сделать эндпоинты "как бы про удаление" и "как бы про обновление", но по факту операции вызывают комбинацию событий.

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

🔶 Выбор строго по конвенции REST часто не подходит, так как операция неконвенционная.

🔶 Выбор "по сути" бизнес-операции (например, если удаление, то строго DELETE) ломает REST-конвенцию и упирается в ограничения метода. Может ли DELETE вернуть в response несколько обновлённых сущностей вместо OK/ERROR?

🔶 Выбор в пользу "понятно для клиента" - это размытый критерий. На рынке нет единого стандарта под такие случаи, и «понятность» превращается во вкусовщину.

Как-то обсуждали эту тему с solution architect Володей @vrogach. И его решение мне очень откликнулось.

Зафиксировать внутренний стандарт для конкретного API (Design Guidelines).

Для всех неконвенционных операций команда один раз договаривается и выбирает конкретный метод, который будет использоваться на все подобные случаи, и фиксирует это в спецификации API.

Например: "Для всех эндпоинтов, которые запускают комбинацию событий, используется POST"

Это делает поведение API предсказуемым для клиентов и разрубает узел нестыковок с REST-конвенцией.

Конечно, на практике не всегда удаётся договориться о таком с командой. У меня были случаи тоже, когда для сохранения мира в команде приходилось идти за большинством голосом разработчиков и выбирать среди подходов "по сути бизнес операции" пусть и неконвенционно REST.

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

💬 А как у вас в командах решают такие спорные случаи? Удаётся ли договориться о едином стандарте? 👇

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

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

Я не сравниваю 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.

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

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

Пока вы гоняете кодинг-агента в пет-проекте или микро-стартапе на пару тысяч строк, проблем нет: белковый разработчик видит каждый 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).

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