Согласен с постом, но хочу докинуть своего мнения)

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

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

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

Плановое обслуживание кода

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

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

Эффективность агента

/doctor (Claude Code) — раз в месяц проверяю здоровье агентского окружения: конфигурацию, неиспользуемые скилы и MCP, медленные хуки, проблемы с permissions и другие накопившиеся проблемы. Заодно помогает освобождать память от устаревшего и лишнего.

/fewer-permission-prompts (Claude Code) — анализирует историю работы и предлагает, какие часто используемые безопасные команды стоит добавить в allowlist, чтобы агент меньше отвлекал подтверждениями.

/run-skill-generator (Claude Code) — периодически пересобирает знания агента о том, как поднять и проверить проект, чтобы /run и /verify не опирались на давно устаревшие команды.

/retro (Matt Pocock Skills) — формально не плановая задача. Запускаю после сессии, где агент заметно буксовал, делал лишние шаги или его приходилось несколько раз исправлять. Скил анализирует, что можно поменять в инструкциях, автоматических проверках и окружении, чтобы эта проблема больше не повторялась.

Качество кода

/simplify (Claude Code) — прохожусь по активно меняющимся частям проекта. Ищет дублирование, лишние абстракции, возможность переиспользовать уже существующий код и просто слишком сложные решения. Удобно запускать раз в неделю по нескольким наиболее активно меняющимся каталогам.

/code-review (Claude Code; у Matt Pocock также есть одноимённый skill) — отдельный проход по изменениям за неделю на корректность, качество кода и возможные упрощения. Обычный review конкретного изменения такую накопительную деградацию часто не замечает.

/improve-codebase-architecture (Matt Pocock Skills) — ищет места, где архитектура постепенно поплыла: слишком мелкие модули, неудачные границы, сложные интерфейсы, размазанное по нескольким местам поведение. Можно натравливать прямо на конкретные слои, типа посмотри сервисы

Чтобы не потерять это добро, я включил в его книгу паттернов агентной разработки

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

p.s. Поделитесь своими фишками, что запускаете вы?

Telegram | YouTube | AI Клуб | Внедрение AI

Почему нам нужны визионеры

Недавно DHH выступил на Rails World и по полной прошелся по привычному программированию. Сказал, что писать код руками становится экономически бессмысленно, что сам почти перестал писать на Ruby, а часть нового HEY они делают на Rust, который он сам не знает и воспринимает как черный ящик для агентов (но уверен что он тут специально нагнетает).

Этим он подорвал столько пердаков, что из космоса было видно зарево. Мой твиттер на неделю превратился в бесконечный срач. На Reddit появились треды в духе "уберите DHH из Rails", Aaron Patterson посвятил значительную часть своего закрывающего доклада ответу DHH. Как вообще создатель Rails может выйти на Rails-конференцию и рассказывать людям, что язык, фреймворк и даже понимание собственного кода скоро могут перестать иметь прежнее значение?

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

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

Амазон годами инвестировал в инфраструктуру и рост вместо прибыли. AWS поначалу вообще выглядел почти побочным направлением интернет-магазина. Сегодня идея покупать вычисления как электричество кажется естественной, но кто-то должен был вложить в эту модель миллиарды до того, как она стала естественной.

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

И обратных примеров тоже полно. Компании редко погибают потому, что вообще не знали о новой технологии. Kodak одной из первых разработала цифровую камеру. Nokia прекрасно видела развитие смартфонов. Большие корпорации обычно располагают огромным количеством исследований, аналитики и талантливых людей.

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

Причем важно не превращать это в культ великих людей. Визионер вполне может завести компанию не туда. Чем сильнее убеждение, тем опаснее ошибка. Стив Джобс ошибался. Безос ошибался. DHH ошибался и еще много раз ошибется.

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

Telegram | YouTube | AI Клуб | Внедрение AI

В мире с миллиардом Эйнштейнов кому-то всё равно придётся строить лаборатории, вести бухгалтерию и таскать материалы…

Кажется, это все нам придется делать:(

На сайте OpenAI вышло авторское эссе The Eternal Complement.

И там есть хороший вопрос:

👉🏼 насколько быстрее вообще сможет развиваться цивилизация, если интеллект перестанет быть дефицитом?

Вот Галилею, чтобы посмотреть дальше в космос, понадобились две линзы и трубка.

А чтобы человечество посмотрело ещё дальше с помощью James Webb, понадобились около $10 млрд, сотни организаций, десятки стран, сложнейшее производство, логистика и годы координации.

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

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

Есть исследование Nicholas Bloom и соавторов: чтобы поддерживать темп роста плотности транзисторов, сегодня требуется больше чем в 18 раз больше исследователей, чем в начале 1970-х. Похожие тенденции они нашли в сельском хозяйстве и медицине.

То есть прогресс не становился проще, но мы просто бросали на него всё больше людей, денег и инфраструктуры.

А теперь представим, что интеллект стал почти бесплатным.

AI может:
- придумать лекарство;
- предложить новый материал;
- спроектировать двигатель.

Но лекарство всё равно нужно испытать, материал - произвести, двигатель собрать и проверить.

И природе, короче, вообще всё равно, насколько умный у вас AI 😁

Авторы предлагают два возможных сценария.

Первый : «цивилизация глубины».

AI становится настолько хорош в моделировании мира, что нам нужно всё меньше физических экспериментов. Он просто гораздо точнее понимает, что действительно стоит проверять.

Второй - «цивилизация ширины».

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

Чем дешевле становится интеллект, тем ценнее может становиться исполнение.

Потому что между:

«Я придумал гениальную штуку»

и

«Эта штука реально существует»

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

Возможно, мы представляем сверхинтеллект немного неправильно.

Мы ждём миллиард Эйнштейнов, которые будут бесконечно совершать великие открытия.

А потом окажется, что 999 миллионов из них заняты тем, чтобы открытия первого миллиона вообще доехали до реального мира 😁


Само эссе: https://openai.com/index/the-eternal-complement/