Михаил: про ИИ и технологии

Про практические истории с Fable

Модель умнее, чем Opus. Но расходует токены очень жирно

Поэтому иногда делаю так: прошу Fable сделать ревью/спроектировать. По найденному написать подробный план, чтобы дальше отдать его Sonnet.

Получается, что драйвит все решение Fable, руками работает Sonnet, качество проверяет Fable

Fable часто находит более крутые штуки, чем Opus. Но делать им черновую работу затратно

Пустить агента разведать

Есть у меня такая практика. Если где-то вижу проблему, пустить агента посмотреть что там. Агент ходит смотрит сам и возвращается с причинами. Иногда нужно пару раз задать уточняющие вопросы, чтобы сложилась объективная гипотеза.

Например вчера. У нас есть тест, который работает то 20 минут, то еле-еле в два часа укладывается. И как раз поймал момент, когда он собирался работать два часа. Попросил агента разобраться, почему так.

Он пару раз приходил с выводом что тестов сейчас много запущено, поэтому тормозит. Попросил посмотреть нагрузку на сервер, что именно тормозит. Вернулся, говорит — диск тормозит. Если диск тормозит, есть готовое решение — рамдиск (диск, который хранит данные в памяти). Переключили, скрость кратно возрасла. Теперь 7-13 минут в зависимости от нагрузки

Два вывода:
1. Агентами можно находить причины, скрытые парой поворотов. Самим ходить долго/неудобно/некогда, а агент сходит. Иногда позволяет найти проблемы и скрытые возможности
2. Но вместе с этим нужно понимать масштаб. Очень легко залезть в 10 разных небольших улучшений, а на важные дела внимания не хватит

Про качество

В продолжении мыслей про пост Ильи. В продуктовой разработке качество состоит из двух частей: продуктовой и технической

Техническое качество это понятная история. Насколько хорошо технически сделано решение. Качество кода, качество тестов. Инженеры сильно топят за это качество

Продуктовое качество — как продукт решает задачу клиента. Насколько хорошо, насколько удобно в нем работать. Насколько круто в нем работать. Насколько решаемая задача важна для клиента

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

Агенты позволяют сдвинуть внимание в продуктовое качество

Вайбкодинг (тут в смысле, что разработка не техническим специалистом) — позволяет фокусироваться на продуктовых аспектах системы. Садится аналитик/продакт, человек кто очень хорошо понимает задачи и боли пользователей, и пытается именно эти проблемы решить.

Быстрые эксперименты — ускорять цикл обратной связи. Сделали — показали, собрали фидбек. Поправили, снова показали, собрали новый фидбек. Возможно код и перепишится потом, но сразу будет понимание в каком виде нужно решение

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

Увидел вчера новый термин про современную разработку — Рэп-кодинг. Как вайбкодинг, только требования к системе наговаривают голосом :)

Пойду наговорю что-нибудь Клоду ))

Кстати, там интересно реализована проверка. Регистрируется прехук, который спрашивает у агента — а обновил ли ты документацию? И тот идет обновлять :)

Апдейт про #openspec и автоматическое обновление документации:
1. если открыть спецификацию изменения (change request), то все что обсуждается в чате складывается в информацию по этому изменению (это отлично!)
2. данные изменения нужно смержить в общую документацию (явно попросить об этом)
3. круто, что фиксируются разные решения, которые не подошли или были отклонены. По идее, снова случайно к ним возвращаться не должны

Лендинг, это, конечно, специфический проект. Но результаты интересные. Продолжаем наблюдение!

В последние недели явно наблюдается факт — хорошая документация помогает агентам. Я сам (очень) не люблю документацию. Но надо разбираться

Дока бывает полезна в двух режимах (это вообще эталонный процесс):
1. описание как должно работать — те самые интенты
2. текущий план реализации — позволяет держать план у агента и человека в голове, с чеклистом и критериями. У агента есть похожий встроенный, но он иногда его теряет

Среди возможных решених многие рекомендуют #openspec. Я немного экспериментировал, было интересно. Но решил подключить в настоящем проекте. Делаем доработку лендинга, вот там и проверим :)

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

Удобно, что сразу все вместе

Еще непроверенная возможность (пойду проверять сейчас) — опенспек регистрирует скилы и хуки в процесс, который позволяет автоматически набирать эти требования по чату. Снимая из запросов "почему и зачем", а не просто "как"

После аджайла и вотерфола

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

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

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

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

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

Решение лучше — формировать контекст проекта. Делать рамки и подсказки, чтобы агент автоматически их учитывал, и не нужно было его постоянно подруливать:
1. линты кода (красить красным как нельзя делать)
2. тесты — правила написания, требования выполнять и сами тесты
3. архитектура в целом — какие компоненты, как собирается, как поставляется клиенту, как устроен деплой
4. архитектура в частности — подробнее про компоненты, их структуру и правила. Например, как пишем helm-чарты. Или как работаем с базой данных
5. спецификации — планы разработки модулей (целевая модель), текущие интенты (почему именно так было сделано, важные требования и ограничения)
6. фидбек-луп — набор скиллов, который проверяет полученный код на разные аспекты: качества кода, дизайн, безопасность

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

#nextgen_dev

В продолжении вчерашней темы.

Во время вчерашних разборок Клод обнаружил, что билд-машина не видит второй диск. Написали в поддержку, диск поменяли

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

Что получилось?

С точки зрения процесса:
1. проверку я запускаю каждое утро
2. теперь проверок пять: логи системы (системные и журнал событий системы), производительность, трейсы, логи Gitlab CI

Какой результат:
0. честно скажу, что каких-то супер открытий еще найдено не было. Но если бы запустили неделю назад, то нашли бы
1. нашли несколько небольших проблем в системе
2. нашли пару проблем в нашей локальной инфре
3. многое из найденного починили. И сегодня первый запуск был без красного статуса

В итоге суть метода в последовательных шагах. Раз за разом находить небольшие проблемы и последовательно их устранять

А вы делаете что-нибудь подобное?

#ai_архитектура

Хочу написать несколько мыслей про #nextgen-dev

Начну с мысли про процесс разработки.

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

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

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

Поэтому задача #nextgen-dev сейчас, это найти новую точку баланса. И итоговый процесс может значительно отличаться от привычного сейчас

Делай пока не закончишь

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

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

Как думаете, чем хорошо три фазы на даче?

Если одна отключится, можно переключиться на остальные две

Это, конечно, костыль. Но спасает если одна фаза отключается. Другие соседи жалуются, что ничего не работает. А мы собрали временное решение и у нас все работает

#дачная_байка

Тест зелёный, а на самом деле он не выполнялся. У нас таких 50+ джобов на каждый коммит, и глазами их не пересмотришь. А агент может

Вопрос с ИИ в разработке давно не в том, использовать или нет. Вопрос как использовать системно. Тема большая, но покажу на одном конкретном примере, что это даёт.

Мы фанаты автоматических контролей: 50+ проверок на каждый коммит в Gitlab CI. Тесты модульные, фронтовые, e2e, проверки безопасности. И там регулярно всплывает коварная проблема: тест зелёный, но фактически он не отработал.

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

А 50+ джобов глазами это нереально. Но если есть Gitlab CLI (или аналог для GitHub), можно попросить агента пройтись по логам самому. Особенно попросить перепроверить именно зелёные тесты, те, на которые обычно никто и не смотрит.

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

А у вас бывало, что зелёный тест оказывался пустышкой? Как ловите такое?

#ai_архитектура

Всем привет!

У меня случилась пауза в ведении канала. Было много разных дел, я несколько странно вылетел из ContentHero (была ошибка на их стороне), мы классно съездили в Карелию (потрясающее место!)

Буду возвращаться! Есть много интересных мыслей, которые должны быть высказаны