#llm #code

Создатель Claude Code — о том, как он пишет 30 PR в день без единой рукописной строки 🤖

Послушал интервью Бориса Черни (создатель Claude Code) в подкасте Pragmatic Engineer — одно из лучших про то, как реально меняется работа инженера прямо сейчас.

Интересно, что в самом начале своего пути в Anthropic (после перехода из Meta) Борис получил реджект за первый же PR — потому что написал его руками, а не через ИИ :)

Главное 👇

🔧 Как рождался Claude Code
Борис дал модели единственный инструмент — bash — и спросил: «Какую музыку я сейчас слушаю?»
Sonnet 3.5 написал AppleScript, обратился к плееру и выдал ответ с первого захода.
Главный инсайт: не надо загонять модель в рамки. Дай инструменты — она сама разберётся. Это, по сути, и стало основой Claude Code.

⚡️ Рабочий процесс Бориса сегодня

— 5 параллельных агентов в терминале, каждый — в режиме плана
— 20–30 пул-реквестов в день, от однострочников до тысяч строк
— 0 строк написано вручную
— IDE удалил — и не заметил этого ещё месяц
— ~треть кода пишет... с телефона, запуская агентов с утра 📱
С Opus 4.5 поведение модели изменилось настолько, что хороший план практически гарантирует реализацию с первого захода.

🔍 Код-ревью: как это работает

• Claude Code автоматически ревьюит каждый PR → ловит ~80% багов
• Живой инженер делает второй проход
• Человек всегда в контуре финального одобрения
Плюс: Борис пишет «@Claude, напиши lint-правило для этого» прямо в комментарии к чужому PR — и Claude делает это на месте 🎯

🖨 Интересная аналогия с печатным станком

В Европе XV века писцы — < 1% населения — умели писать. Короли нанимали их, сами будучи безграмотными.
Появился печатный станок:
— стоимость материалов упала в 100× за 50 лет
— количество текстов выросло в 10 000× за 100 лет
— появились писатели и авторы как профессия
Писцы не исчезли — рынок просто расширился до масштабов, которые никто не мог предвидеть.
Разработчики сегодня - в позиции писцов. Вопрос не в том, исчезнет ли профессия. Вопрос — что появится, когда создавать код сможет каждый?

📈 Навыки: что растёт, что падает

Теряют значение:
— холивары о языках и фреймворках
— жёсткая привязанность к «правильному» стилю кода

По-прежнему важны:
— методичность и гипотетическое мышление
— умение отлаживать системно

Растут в цене:
— мультидисциплинарность (инженер + продукт + бизнес)
— адаптивность к быстро меняющимся инструментам
— умение быстро переключаться между контекстами 🔄

📚 Книги от Бориса
• Лю Цысинь — короткие рассказы (не только «Задача трёх тел»)
• «Accelerando» Чарльза Стросса — дорожная карта следующих 50 лет
• «Функциональное программирование в Scala» — учит думать типами, делайте все упражнения

P.S.
1) Полный интерактивный транскрипт интервью на русском подготовил для вас здесь.
2) Гамифицированная версия лучших практик по работе с Claude Code от Бориса тут
(сделана с использованием claude code и лучших практик Бориса :)

@llm_notes @MAX

#claudecode #anthropic #aiengineering #futureofwork #llm #cherny #bestpractice

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

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

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

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

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

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

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

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

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

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

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

@ai_for_devs

#llm #metrics

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

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'

#llm #code

#softskills #career

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

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

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

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

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

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

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

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

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

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

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

#rl #courses

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

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

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

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

#agents #metrics

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

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

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

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

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

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

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

#devfm #ai

#agents #petproject

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

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

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

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

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

#ai #agents

#analytics #interview