Интересное что-то

Agent Harness — звучит круто, да?

И последнее время слышу это определение всё чаще. Но что оно вообще значит?

Коротко: это вся инфраструктура вокруг LLM — оркестрационный цикл, инструменты, память, управление контекстом, обработка ошибок. Всё, что не LLM.

Есть три уровня работы с харнесом (на картинке):
1. Prompt engineering — формирует инструкции, которые модель получает.
2. Context engineering — управляет тем, что модель видит и когда.
3. Harness engineering — включает оба предыдущих плюс всю прикладную инфраструктуру: оркестрацию инструментов, персистентность состояния, восстановление после ошибок, циклы верификации, обеспечение безопасности и управление жизненным циклом.

Не стоит умалять заслуги людей, которые обучают LLM — за последнее время они сделали огромный шаг вперёд. Но харнесс тоже имеет вес. Например, LangChain поменяли только его, не трогая модель и веса — и поднялись с 30-го на 5-е место в TerminalBench 2.0.

Подробнее про то, как устроены Claude Code, OpenAI, LangChain и где во всём этом харнесс — в новой статье на Хабре.

Рекомендую сохранить, если хотите лучше понимать, как работает ваш агент и как его можно улучшить.

@ai_for_devs

#agents

Как прокачивать продуктовое мышление?

Чтобы улучшить продуктовое мышление нужно думать как продукт
Шучу! Или нет.

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

А еще здесь могли быть ваши шутки про продукты в пятерочке 🤓

Зачем мыслить как продукт?

Для продуктового аналитика одним из ключевых скиллов является "продуктовое мышление", наравне с остальными хард скиллами: SQL, A/B тесты, дашборды и так далее, потому что аналитик полноценный партнер бизнесу, а не выгружатель данных по запросу.
Поскольку это требуется в работе, то и на собеседованиях очень часто спрашивают на продуктовой/бизнесовой секции.
Я сама раньше писала, что невозможно прокачать продуктовое мышление кроме как непосредственно на работе продуктовым аналитиком. Сейчас согласна с этим частично, потому что так развивается лучше всего, но все-таки можно подготовиться и не будучи продуктовым аналитиком. Хотя конечно это чуть сложнее, чем учить SQL и питон, и даже статистику, но возможно.

Как мыслить как продукт?

Когда я сама переходила в продуктовую аналитику, мне помогло разгонять знакомые мне продукты с точки зрения воронки AARRR, ключевых метрик и моделей монетизации. Глобально идея понять как продукт привлекает пользователей и зарабатывает, какая у него может быть North Start Metric. Можно валидировать свои ответы с помощью нейросети, конечно нейросеть может обмануть, но тут важно скорее мыслить в правильном направлении, детали важны меньше.
Такое упражнение очень хорошо помогает повышать насмотренность и не впадать в ступор при вопросах на собеседовании/в работе. Из побочных эффектов – утомила всех рассуждениями про модели монетизации и рекламу 😁

На собеседованиях могут спросить следующее:
🟡прикинуть дерево метрик для конкретного продукта (может быть тот продукт куда собеседуетесь или наоборот НЕ тот куда общаетесь и точно не тот, где работаете). Здесь можно заранее подготовить продукт, которым пользуетесь каждый день и примерно разложить дерево метрик.
🟡описать, на каком этапе развития находится продукт, какие ключевые метрики и вызовы перед ним могут стоять.
🟡упала метрика, что делать
🟡запускаем новую фичу, как оценить эффективность внедрения. Это может быть кейс на A/B, но необязательно

Это далеко не все возможные примеры вопросов, но чтобы разобрать детальнее нужен отдельный пост. Ставьте реакции 🔥, в следующий раз могу написать, какие типы вопросов бывают, как к ним готовиться и отвечать 💪


#analytics #собес_PA

#analytics #interview

Я продолжаю экспериментировать с разными штуками, которые позволяют запускать автономную работу агента и выполнять поставленные задачи "под ключ". А то начитаешься всякого на реддите, что "если у вас агент ничем не занят, то вы делаете что-то не так" 🙂

Сейчас пробую Ralphex. Очень любопытная штуковина – под капотом используется Claude Code, но поверх накручена полноценная система управления процессом работы агента.

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

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

На самом деле – там много интересного происходит под капотом – рекомендую поэкспериментировать.

#ai #agents

#agents #petproject

Вот и прошёл AI Dev Day. Классное получилось мероприятие. Делюсь выжимкой моего доклада.

Первая часть была посвящена тому, как мы разрабатываем агента в среде разработки. Когда мы начинали, было много скепсиса к агентам, поэтому главной ставкой были фичи, связанные с бесшовным входом в разработку с агентом. Но настоящим вызовом стал адопшен – нужно было сделать так, чтобы агентом начали реально пользоваться. Писали доку, гайдлайны, проводили воркшопы – в общем было очень потно, но в то же время приятно было видеть, как в результате растёт аудиторная метрика.
Ещё один важный момент, влияющий на адопшен, который подтверждается как нашими внутренними исследованиями, так и исследованиями DORA – важно, чтобы были прозрачные политики безопасности, чтобы люди понимали, что можно отправлять в агентов, а что нет.

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

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

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

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

А кто любит движуху вокруг LLM – 21 марта будет ещё один любопытный митап в офлайн и онлайн форматах.

#devfm #ai

#agents #metrics

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

Сегодня у него вышло обновление. Автор оформил книгу в виде бесплатного мини-курса с видео-лекциями, слайдами и кодом.

Получилось 4 лекции по часу, от введения до математики и реализации.

Лекции на ютубе смотреть тут

#rl #courses

Дорогие и дешевые сигналы лидера

Недавно прочел исследование, в котором говорится, что люди оценивают чужие лидерские компетенции довольно субъективно. Они замечают ряд «сигналов», из которых делают выводы.

А сигналы эти исследователи делят на «дешевые» – не требуют затрат и легко имитируются. И «дорогие» – требующие затрат и несущие риски.

Дешевые
- Харизматичная риторика (метафоры, сторителлинг, обещания);
- Публичные заявления о ценностях и этике;
- Дружелюбные сообщения и благодарности в коммуникациях;
- Статусный или «технобро»-стиль одежды;
- Демонстративная «открытость».

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

В чем тут ирония?
Я читал и грудь колесом делал: «Я же выбил полный страйк из дорогих сигналов, ух я лидер!».

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

НО
На днях один из сообщников по Менеджмент Хабу, с которым мы долго работали вместе, написал: «Я вот Жене что угодно доверю, потому что если мы договорились, он прям точно сделает».

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

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

Кстати, вот здесь перформанс ревью работает, на мой взгляд, хорошо (оставляю за скобками другие его аспекты). Там так просто не отбрехаться, там надо результаты предъявить.

#softskills #career

# ULTRAPACK

Я стал настолько много клод-кодить, что захотелось поработать напильником.

TL;DR: мой минималистичный пак скиллов для Claude Code, построенный вокруг коротких планов и работы над одной фичой в одном диалоге: https://github.com/btseytlin/ultrapack или просто /up:.

Установка:

/plugin marketplace add btseytlin/ultrapack
/plugin install up@ultrapack
/reload-plugins

Запускаем:

/up:make <описание вашей фичи>

Что произойдет:
1. Агент создаст файл docs/tasks/<ваша-фича>.md который будет пополняться по ходу планирования и исполнения. Всегда можно возобновить работу с этого файла или закинуть его в контекст другому агенту.
2. Проведет через стадии: дизайн, планирование, исполнение, верификация, ревью, обновление документации.
3. Если написать /up:make handsoff <описание вашей фичи> будет стараться минимально вас о чем-то спрашивать и при этом делать самые безопасные выборы (например, ничего не удалять без бекапа). Явно документирует какие решения он принял без вас, см. пример.

Дизайн и планы получаются достаточно короткие, потому что делается упор на инварианты (условия которые должны выполняться) и принципы.

В исполнении и проверке делается фокус на мануальное тестирование. Как же меня достало, что агент делает фичу, покрывает всё тысячью юнит-тестов, но потом всё падает при первой попытке это запустить. В up агент всегда сам "протыкивает" свои изменения.

Подобные паки уже есть и ultrapack это компиляция из всего, что мне в них нравится, но короче и проще:
- Официальный feature-dev: в целом хорош, но мне лично много чего в нём не хватает, например мануальных тестов и обновления документации. Основной воркфлоу в up оттуда.
- Superpowers: ещё больше хорош, но перегружен и уничтожает лимиты. Потому что пишет в планы буквально какой код планирует писать и какие команды будет вызывать дублируя всю работу. Пихает TDD туда, где он не нужен. Ещё авторы зачем-то меняют всё каждые 15 минут, я устал.
- Personal AI Infrastructure: перегружен какой-то шизофренией.

Вот здесь пример task файла по созданию этого же пака: https://github.com/btseytlin/ultrapack/blob/main/docs/tasks/ultrapack-v1.md

Пример task.md для поиска нетривиального бага в hr-breaker: https://github.com/btseytlin/hr-breaker/blob/main/docs/tasks/fix-non-ascii-resume-upload.md

Пользуйтесь, делитесь фидбеком 👀

Пет проекты в 2026 би лайк: 5 маркдаун файлов.

@boris_again

#llm #code

5 git-команд, которые стоит запустить перед чтением чужого кода. Это рекомендация консультанта по аудиту кодовых баз

— 20 самых часто изменяемых файлов за последний год. Файл на первом месте -- тот, которого все боятся:

git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

— Все авторы, отсортированные по числу коммитов, чтобы понять, кто «главный». Если один делает ≥60% -- высокий bus factor:

git shortlog -sn --no-merges

— Где скапливаются баги. Пересечение с первым списком -- самый рискованный код:

git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

— Проект растет или умирает. Коммиты по месяцам за всю историю. Резкое падение, например, уход сотрудника:

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

— Как часто команда тушит пожары. Несколько раз в год - норма. Раз в две недели -- проблемы с деплоем:

git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

#code

Opus 4.5 набирает 80.6% на SWE-bench Verified. Opus 4 — 72.5%. Значит ли это, что Opus 4.5 лучше программирует, чем Opus 4?

Ну... возможно.

Но SWE-bench Verified это не показывает. Он показывает способность модели чинить небольшие баги в 12 популярных open source Python-репозиториях, которые почти наверняка входят в её обучающие данные.

SWE-bench Verified не тестирует умение ориентироваться в вашем TypeScript-монорепо, Spring Boot-приложении или самописном ORM, на котором настоял предыдущий CTO.

А вы знаете, как устроены самые популярные бенчмарки? Если хочется чуть больше понимать, что происходит за цифрами в каждом новом релизе флагманской модели — добро пожаловать в лонгрид на Хабре.

Разбираем 14 самых популярных бенчмарков на конкретных примерах: что тестирует каждый и как устроена оценка.

@ai_for_devs

#llm #metrics

🔥 Квантизация с нуля: как 160-гигабайтная LLM помещается на ноутбук

Помните, мы переводили статью про кэширование промптов? Сегодня подготовили перевод от того же автора — на этот раз про квантизацию. Тот же стиль: интерактивная визуализация, объяснение базы, которая лежит в основе и всё это простыми словами.

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

За счёт этого модели на 160 ГБ могут поместиться на обычный ноутбук и даже работать быстрее!

Главный инсайт от автора:

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

Это оказалось не так.

Переход с 16-битной до 8-битной квантизации несёт почти нулевые потери качества. Переход с 16-битной до 4-битной более заметен, но это точно не «в четыре раза хуже оригинала». Ближе к 90%, в зависимости от метрики.

Не бойтесь запускать локальные квантизованные модели.

Понимание того, как модели устроены изнутри, напрямую влияет на то, насколько хорошо вы их используете. Поэтому считаем такие статьи must have для senior vibecoder 😉

📚 Читайте и комментируйте на Хабр.

@ai_for_devs

#llm