You Should Write An Agent

Недавно проводил опрос: по поводу использования агентов и оказалось, что многие используют.

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

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

Дальше – интереснее: как подключать tools к агенту. Автор даёт агенту возможность выполнять команду ping. LLM сама инициирует вызов нужного инструмента. Получается очень прикольно: ты не описывал логики, не писал условий – модель сама решила, какие адреса пинговать, как интерпретировать результаты и как сформировать ответ.

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

В общем, рекомендую посмотреть и поэкспериментировать самостоятельно.

#ai

Шаблонный сервис

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

Так зачем же нужен шаблонный сервис?

Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.

Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.

Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.

Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.

Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)

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

Просто экспериментировать. Создал веточку от шаблона – и прикручиваешь свою новую махарайку, не тратя время на базовую структуру.

Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.

Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.

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

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

В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂

#devfm #systemdesign

Пятничное развлекательное

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

Create HTML/CSS of an analog clock showing ${time}. Include numbers (or numerals) if you wish, and have a CSS animated second hand. Make it responsive and use a white background. Return ONLY the HTML/CSS code with no markdown formatting.

А дальше ai начинает творить чудеса.
В общем заходите посмотреть :)

#fun

Ух, вчера вспомнил давно забытую боль.

Некоторое время назад мы пилили b2b-продукт и интегрировались по HTTP с большим сервисом большой компании.

И вот представьте моё удивление, когда приходит разработчик и говорит, что мы получаем код 200, а в body – что-то типа «произошла ошибка». Мы тогда повозмущались и смирились, потому что альтернатив всё равно не было.

И всё бы ничего, если бы вчера я не рассказал эту историю своему хорошему товарищу. А он, представьте себе, вообще не удивился. Сказал: «Да, всё так и есть. Видел это не раз. И во вполне приличных конторах – тоже».

И вот у меня вопрос – ну как так то, доколе?! Может, у этого есть какая-то логика?
Вы такое встречали?

#devfm

Присмотритесь к Zed

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

В их статье Zed is our office ребята подробно рассказывают, как используют редактор у себя внутри, превращая его в настоящий виртуальный офис. И вот там становится ясно, что их коллаборативность – это не про «парное программирование на коленочках». Масштаб совсем другой.

Если идея парного программирования меня не очень вдохновляет, то такой подход к внутренним рабочим процессам – прям зашёл. Я даже попробовал провести созвон в Zed, когда обсуждали ТЗ: оказалось удобно, ничего шарить не нужно – все работают в одном документе.

Но смотреть на Zed стоит не только ради совместной работы. Он сам по себе очень приятный в использовании – свежий взгляд на IDE. Плюс ребята активно развивают AI-фичи и уже встроили Claude Code и других агентов.

Claude учится экономить контекст

Не пришлось долго ждать. Сначала Anthropic рассказали о проблемах – огромный контекст на старте из-за пачки MCP-тулов, частая путаница в выборе инструмента, ошибки в параметрах – а теперь решения уже доступны в бета-версии Claude Development Platform. Подробности – в статье.

Tool Search Tool
Звучит очень многообещающе.
Теперь нет нужды загружать десятки тысяч токенов инструментов в начале сессии. Модель получает только маленький поисковый тул и подгружает нужные MCP-инструменты по запросу – GitHub, Slack, Jira, Drive, что угодно.

Экономия контекста: Anthropic приводят пример, где удалось сократить объём примерно с 70K токенов до 8–9K. И главное – рост точности: модель перестаёт путаться между похожими командами и работает только с тем, что действительно нужно задаче.

Programmatic Tool Calling
Раньше каждое обращение к тулу означало: свалка промежуточных данных в контексте.

Теперь Claude может небольшие скрипты, которые берут на себя вызовы mcp-тулов. Скрипты вызываются, модель получает только конечный результат.

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

Tool Use Examples
Используя JSON-схема декларирует, что можно передавать в параметрах, но не объясняет, как API ожидает это на практике.
Теперь можно приложить примеры корректного вызова инструмента – и Claude начинает следовать этим паттернам. По внутренней статистике Anthropic точность выросла с 72% до 90% для сложных API.

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

Пятничное развлекательное

Как-то я уже рассказывал о проблеме вагонетки.

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

How AI is transforming work at Anthropic

Ребята из Anthropic опубликовали исследование – как меняется работа инженеров внутри компании, которая сама делает Claude. И кажется, они прошлись по всем вопросам, которые сегодня беспокоят индустрию.

Вот, что меня заинтересовало.

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

– Инженеры используют Claude примерно в половине своей работы и оценивают прирост продуктивности до 50%
– Полностью отдать ему получается только до 20% задач – всё остальное выполняется с плотным контролем
– Треть работ, сделанных с Claude, просто не существовало бы без ИИ: nice-to-have тулзы, дополнительные дашборды

И вот здесь у меня возникает вопросик: если часть задач создаётся только потому, что теперь их дешево делать, не ломает ли это приоритизацию? Мы ускоряемся – но ускоряемся ли в нужную сторону?

Про важность делегирования
Когда начинаете работать с агентами, важно уметь давать ему шанс:
– начинать с маленьких и чётко проверяемых задач
– смотреть, с чем он справляется хорошо
– постепенно развивать навык понимать, какие задачи он делает хорошо, а какие лучше оставить себе

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

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

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

Что с навыками
– Инженеры отмечают страх потерять экспертизу: когда агент быстро прыгает к решению, ты меньше копаешься в доках и чужом коде – экспертиза формируется медленнее
– Парадокс: чтобы проверять агента, нужны именно те навыки, которые могут атрофироваться
– И вот здесь, как мне кажется, кроется большая проблема: непонятно, как теперь вырасти из джуна. У новичков исчезла часть естественных первых шагов, а спрос на настоящих сеньоров будет только расти. (Но не тех, кто в 25 считают себя сеньорами – извинити, вот такой я дед)

Коммуникации в командах
– 80–90% вопросов, которые раньше шли коллегам, теперь уходят сначала к Claude
– Это влияет на менторство: джуны меньше спрашивают, сеньоры реже передают экспертизу

В общем, очень рекомендую статью к прочтению.

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

#ai

Хотел написать небольшой пост – а в итоге получилась целая статья.

Недавно у меня был классный опыт парного программирования с товарищем: он пишет код, а я смотрю за его флоу и предлагаю оптимизации.

Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна

Заходите почитать, если понравилась ставьте лайкосики.

#devfm

Зачем вы проводите код-ревью?

Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.

И каждый PR дисциплинированно пропускают через код-ревью: назначаются ревьюеры, они что-то пишут, код как-то правится...

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

Ответы бывают разные.

Мы хотим поддерживать качество кода, соблюдать единый стиль.
Что ж, похвально. Только у меня сразу возникает вопрос: а что вы считаете качественным кодом, что считаете единым стилем? А у вас настроены какие-то автоматизации? Ответы бывают разными, но по моему опыту редко есть уверенные ответы на все из них. А без этого код-ревью очень быстро превращается в вкусовщину и в обсуждение того, что вообще-то должна делать машина – линтеры, форматеры, базовые проверки.

Ревьюеры могут найти баг или проблему.
Вот с этого я искренне всегда недоумеваю. У меня сразу возникает вопрос: а кто у вас пишет код, если ревьюеры, не находясь в глубоком контексте задачи, могут заметить баг? Если баги регулярно ловятся на код-ревью, значит вы используете самый дорогой, самый медленный и самый ненадёжный механизм контроля качества. Ревью не воспроизводимо, не масштабируется и слишком сильно зависит от человеческого фактора.

Код-ревью нам нужно для шаринга знаний – такой ответ дают самые прогрессивные. Честно говоря, какое-то время это был мой любимый аргумент, и я очень им гордился. Но если задуматься: для шаринга знаний предполагается, что разработчик, у которого куча своих задач и контекстов, переключится на чужую задачу, впитает всё, что там написано, разберётся и получит ценные знания. Вопрос – сколько же времени нужно для этого? Как говорят классики: «сомнительно, но окэээээй». Если услышите такой аргумент, спросите у разработчиков, сколько времени они тратят на ревью, и подумайте, можно ли за это время действительно перенять знания. Ответы, которые получал я, говорят: скорее нет, нельзя.
Моё мнение – код-ревью создаёт иллюзию шаринга знаний, но по факту распространяет только очень поверхностный контекст. Если вы реально хотите шарить знания, есть куда более прямые и честные инструменты – дизайн-доки, обсуждения решений до реализации, грумминги задач.

И это я ещё не затронул другие проблемы и крайности: когда в PR появляется миллион комментариев, когда какой-то очень умный разработчик упирается рогом и говорит, что такой PR "только через мой труп", когда PR-ы висят днями, копят строчки, а потом полдня тратится на разруливание конфликтов. В общем – красота.
Так зачем это всё?

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

Первое – составить гайд, хотя бы выровняться по одной линейке: как в команде проводится ревью, что мы ревьюим, на что обращаем внимание, а что считаем минором, тайминги проведения, выбор ревьюера, правила оформления PR-ов.

Второе – автоматизировать всё, что можно автоматизировать: линтеры, форматеры и вот это всё. Чтобы на ревью об этом даже не думали.

И даже когда есть гайд, тимлид должен чутко следить за его соблюдением и периодически подвергать сомнению его содержимое. У нас на практике в стайлгайдах в шапке была такая графа: актуализировать – "дата". Чтобы целенаправленно и критически посмотреть на эти правила.

Ревью действительно должно быть:
– когда вы залезли в чужой сервис или область знаний и сами просите эксперта посмотреть код
– когда вы мейнтейнер опенсорсного проекта
– когда вы менторите новичков или джунов и осознанно инвестируете время

Если вы прочитали и подумали: "Что это за бред?" – ну что же. Либо вы никогда критически не смотрели на этот процесс, либо вам действительно повезло с командой. Во втором случае искренне за вас рад – держитесь за неё. Так бывает далеко не у всех.

#devfm