Насколько AI увеличивает продуктивность программистов

Недавно METR опубликовали исследование с интригующими выводами: авторы задаются вопросом, насколько AI‑асисты действительно ускоряют или замедляют работу опытных разработчиков.

Почему привычные метрики не годятся
– Большинство бенчмарков фокусируется на узко поставленных задачах с автоматической проверкой результатов, не требующих контекста больших кодовых баз
– Они не учитывают время на настройку подсказок, исправление неточностей и интеграцию AI‑сгенерированного кода в проект
– В них отсутствует фактор человеческой правки: в реальности мы тратим дополнительное время на доводку и ревью предложений ИИ

Как проходил эксперимент
16 опытных разработчиков из крупных open‑source‑репозиториев (более 22 000 звёзд и 1 млн строк кода) выбрали по 15–20 реальных задач — фиксы багов, новые фичи и рефакторинг. Всего получилось 246 заданий. Каждую задачу случайным образом разрешали выполнять либо с любыми AI‑инструментами, либо без них. Разработчики фиксировали время выполнения каждой задачи.

Ключевой вывод
И вот барабанная дробь: использование AI‑асистов замедляет разработчика на 19%. При этом участники до эксперимента прогнозировали ускорение на 24%, а после всё ещё считали, что AI их реально ускорили.

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

– Ограниченный объём сэмплирования: в бенчмарках модели могут генерировать тысячи вариантов, здесь — лишь несколько
– Крутая кривая обучения: эффект от AI‑инструментов может проявляться после сотен часов практики, а в эксперименте у большинства участников было лишь несколько десятков часов опыта
– Высокие стандарты качества: Open‑source репозитории часто имеют строгие требования к тестам, документации и стилю, что требует дополнительной правки AI‑кода

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

#ai

Опыт применения LLM в разработке

Недавно Сальваторе Санфилиппо, создатель Redis, поделился своим опытом использования LLMок в реальной разработке. Он выделил несколько областей, где AI уже сегодня становится незаменимым помощником:
🔹 Поиск багов и ревью кода. На примере реализации Vector Sets для Redis LLM обнаружили множество ошибок ещё до того, как код попал в продакшен. Хотя мой опыт, и опыт разработчиков вокруг меня говорит об обратном, что LLMки так себе справляются с задачами поиска багов
🔹 Тестирование гипотез. Наколеночные прототипы позволяют быстро проверять гипотезы
🔹 Парное проектирование. Комбинация вашего опыта с энциклопедическими знаниями LLM даёт хороший результат: вы вносите контекст и интуицию, AI – широкий набор паттернов и решений
🔹 Изучение новых технологий. В незнакомой области LLM способны быстро ввести в курс дела и предложить первые рабочие заготовки
🔹 Ускорение написания кода. AI пишет код под вашим чутким руководством:)

Для того, чтобы эти сценарии были действительно рабочими необходимо следовать некоторым правилам:
🔹 В большинстве случаев отказываться от вайб-кодинга. LLMки могут самостоятельно сделать что-то небольшое, но в других случаях получаются портянки неподдерживаемого кода
🔹 Давать максимальный контекст – предоставляйте исходники, документацию, требования и примеры плохих и хороших решений
🔹 Использовать передовые модели для кодинга, автор предлагает Gemini 2.5 PRO и Claude Opus 4
🔹 Послдений совет, который дает автор – не использовать агентов. Он обосновывает это необходимостью контролировать весь процесс. Но по своему опыту могу сказать, что агенты уже достигли того уровня, когда их разные фишечки действительно делают жизнь легче и избавляют от многих лишних действий

#ai

The Impact of Generative AI in Software Development (DORA).

Недавно изучил отчёт (файл) DORA о влиянии AI на разработку. Он большой, поэтому разбиваю выводы на серию постов. Сегодня – первые две главы.

В первой главе авторы приводят цифры и несколько небанальных наблюдений.

Почти все уже в игре: 89% организаций ставят внедрение AI в приоритет, 76% инженеров используют его ежедневно.

Как DORA считает эффект. Они моделируют: если отдельный разработчик увеличивает своё использование AI на 25% (от текущего уровня), как меняются его метрики.

Что выросло: документация +7.5%, качество кода +3.4%, скорость code review +3.1%, скорость аппрува +1.3%, а сложность кода снижается на 1.8%.

А теперь к наблюдениям, которые меня зацепили.

Во‑первых, падает delivery. Throughput уменьшается на 1.5%, Stability – на 7.2%. Логика ожиданий была обратной: раз промежуточные шаги ускорились, значит и поставка должна ускориться. Авторы предполагают, что AI позволяет быстро генерировать большие порции кода, ченджлисты толстеют, и команда нарушает базовый принцип маленьких поставок.

Во‑вторых, просела valuable work. Доля времени, которую разработчики сами относят к valuable work, снижается примерно на 2.6%. При этом на рутинные задачи время почти не меняется, а ощущения flow и продуктивности растут. DORA называет это «вакуумной гипотезой»: AI ускоряет то, что мы считаем ценным, и освободившееся окно забивается тем, что AI пока автоматизирует хуже – митингами, согласованиями, организационным шумом.

Во второй главе авторы пытаются разобраться, что именно разработчики считают valuable work. В итоге получилось пять аспектов. Для каждого описано, как влияет AI и что стоит делать, чтобы влияние было положительным.

Утилитарная ценность – ощущение, что твой труд приносит реальную пользу.
AI обычно помогает: путь от идеи до импакта сокращается. Риск в том, что если ускоряется только написание кода, а не весь поток, импакт всё равно буксует. Делать: разрешать AI на всех этапах SDLC и удерживать маленькие, быстро проверяемые изменения.

Репутационная ценность – признание вклада.
AI увеличивает объём результата, но размывает авторство: «это я сделал или модель?». Чтобы перевести баланс в плюс, нужно явно признавать труд по работе с AI – формулировку промптов, проверку вывода, интеграцию – в грейдах и перфоманс‑ревью.

Экономическая ценность – «мне платят за результат».
Эффективность растёт, но вместе с ней поднимается и «новая норма», что рождает страх заменимости. Ответ – смещать оценку на outcomes (что доставлено пользователю), а не на количество строк или часов, и прозрачно объяснять, как AI учитывается в компенсации.

Внутренняя (intrinsic) ценность – важность самого ремесла.
AI обесценивает часть привычных навыков, но открывает новые. Это не минус, а новые вызовы. Нужны время и ресурсы на обучение, чтобы люди ощущали рост, а не эрозию профпригодности.

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

#ai

The Impact of Generative AI in Software Development (DORA)

Продолжаем обзор отчета DORA.

В третьей и четвёртой главах DORA обсуждают доверие к AI и то, как перевести точечные успехи в массовое внедрение.

Сформулируйте понятные правила использования AI
Чётко опишите, что можно и что нельзя: типы задач, работа с данными, допустимые инструменты, требования к проверке и лицензиям. Такая политика снимает страхи, выводит эксперименты из «подполья» и делает применение AI управляемым, а не стихийным.

Ускорьте обратную связь: быстрые ревью и тесты как база доверия
AI – джун на коленках: помогает, но может и прод грохнуть. Таким образом, если проблемы от использования AI будут всплывать только на проде, доверия к инструменту не будет. Но если они ловятся сразу – тестами, линтерами, код-ревью – команда чувствует себя в безопасности. Чем быстрее обратная связь, тем смелее можно использовать AI.

Сделайте обучение с AI частью работы (песочницы, типовые кейсы, наставники)
Опыт рождает доверие. Дайте разработчикам время и формат для практики: внутренние песочницы/репозитории без риска для продакшена, типовые задачи «как мы решаем X с AI», парная работа с наставником, короткие демо‑сессии. Закрепляйте удачные кейсы в мини‑гайдах и общих коллекциях промптов. Чем привычнее инструмент, тем меньше сопротивления и тем выше отдача.

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

Сформируйте видение новой роли разработчика
Далёкий по горизонту, но важный пункт: по мере внедрения AI часть задач заберут инструменты, и роль разработчика будет смещаться. Задайте траекторию трансформации профессии: что автоматизируем, какие навыки наращиваем (проектирование решений, оркестрация и верификация моделей, данные/безопасность), как это отразится в грейдах, обучении и оценке по end-to-end результатам.


В пятой заключительной главе авторы переходят к самому важному – внедрить внедрили, а зачем мы это делали? Мало просто внедрять AI – нужно ещё понимать, насколько хорошо мы это делаем и какие результаты получаем. Для этого нужны метрики.

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

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

А для интересующихся, есть отличное видео от Александра Поломодова, где он с собеседником разбирает отчет за 24 год, в котором DORA делится методами, как все эти циферки вообще получаются.

#ai

Как работать с ai-агентами

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

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

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

Методика автора: решение задачи в три захода

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

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

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

Контекст – ключ к успеху

Каждый ваш разговор с агентом начинается с чистого листа. Чтобы этого избежать, есть свои приемы:

🔹Rules – текстовые файлы с информацией о вашем проекте: архитектурные решения, основные паттерны, любые другие договоренности о правилах разработки

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

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

Кстати, автор пользуется Claude Code – отличное решение от Anthropic, рекомендую попробовать.

Попробуйте Context7

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

Для решения этой проблемы есть интересный MCP-сервер – Context7. Этот MCP позволит вашему агенту иметь доступ к актуальной документации огромного количества библиотек. У ребят в ридми подробно описано, как подключить Context7 к вашему любимому агенту.

Расскажите, какие MCPшки у вас в топе?

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

Я люблю посмотреть что-нибудь на английском. Для этого, разумеется, существует множество ресурсов, но мне особенно нравится Ororo. У ребят действительно неплохая база, а главное – можно не отходя от кассы выделить слово в субтитрах и тут же получить перевод. Еще есть удобная перемотка – не по времени, а по выражениям. То есть если не понял, что только что сказали, можно перемотать только фразу, а не условные 15 секунд, как на YouTube. Для меня это прям две киллер-фичи.

Помимо просмотра, я периодически учу новые слова и выражения. С моей точки зрения, лучший способ для этого – флеш-карточки. И для этого навайбкодил себе бота – @MemAnkiBot. Ну как навайбкодил – начал делать это еще в начале 2024 года, когда даже термина такого не было. В те далекие времена нужно было самому писать код, сейчас какие-то правки уже, конечно, сам не вношу.

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

Еще из удобного: встроенный переводчик. Можно перевести слово и тут же добавить его на изучение.

В общем, для кого актуально – заходите, пользуйтесь. А если что-то не работает – знаете, кого пинать:)

#fun

Прокачать навыки System Design

Периодически коллеги или друзья спрашивают о хороших материалах для подготовки к интервью по System Design или в целом о том, как подтянуть свои навыки по System Design.

И уже достаточно давно я рекомендую небольшой курс (просьба не пугаться слова «курс») по System Design.

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

Начать рекомендую с видео от автора курса на YouTube.

Если никогда не проходили интервью по System Design, обязательно посмотрите мок-интервью от коллег из Тинька. Отличный разбор того, как проходит интервью, как правильно строить ответ, какие вопросы задавать и как углубляться в темы.

#systemdesign

Выбирайте скучные технологии

Принес достаточно старую, но очень жизненную статью.

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

Автор приводит классную метафору: у любой компании есть ограниченное число «жетонов на инновации». Хочешь на затащить Airflow? Потратил жетон. Захотел CockroachDB? Ещё жетон. Решил притянуть кастомную систему очередей, которую сам же и написал? Ну, удачи.

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

И проблема не в новых технологиях как таковых. Проблема – в их цене: экспертиза команды, отладка, операционка, поддержка, миграции. Эта цена часто оказывается намного выше, чем кажется в момент выбора.

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

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

На эту тему у нас уже были посты:
– Как принимать архитектурные решения
– Для чего мы рисуем архитектурные схемы

Еще один способ организовать рабочие чатики

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

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

И некоторое время назад я придумал (вряд ли я, но в моем мире – именно я), как иначе организовать рабочие чатики – по срочности.

Сделал 4 папки:
🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю
🔹Hourly – то, на что нужно посмотреть в течение часа
🔹Daily – пробежаться раз в день, узнать, что происходило
🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)

В результате стало гораздо легче ориентироваться и не отвлекаться на лишний шум.

#devfm

Новый взгляд на MCP

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

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

Проблемы с MCP:
– Как правило, все MCP-тулы и их описания загружаются в контекст. Если у вас подключено несколько MCP-серверов, у каждого может быть с десяток-другой тулов. В итоге, ещё до того как агент начал работу, у вас съедена большая часть контекста модели. В результате модель работает сильно хуже.

– Когда агент вызывает какой-то MCP-тул (например, запрашивает транскрипт из Google Docs), результат (полный текст) возвращается в контекст. А если нужно передать его дальше – допустим, вставить в запись Confluence – этот же текст снова дублируется в запросе. В итоге в контекст дважды попадает большой артефакт, который на самом деле не нужен агенту повторно, и он переполняется.

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

Что предлагают делать:

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

Если подробнее:

1. Информацию о всех тулах MCP-серверов мы храним локально в проекте – каждый тул оформлен как отдельный модуль (например, TypeScript-функция).

2. Агент изучает доступные инструменты через обход файловой системы: сначала смотрит, какие MCP-серверы есть в ./servers/, потом открывает нужные файлы и считывает интерфейсы только тех тулов, которые релевантны текущей задаче. Это позволяет не грузить всё подряд в контекст, а подгружать выборочно – по необходимости.

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

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

Дополнительно, используя такой подход, можно:
– фильтровать большие данные (например, из таблицы в 10 000 строк вернуть модели только 5 нужных)
– токенизировать чувствительные данные перед их передачей в модель (модель будет видеть [EMAIL_1], а не сам email)
– строить полноценную логику: циклы, условия, обработку ошибок – без постоянных вызовов модели после каждого шага

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

#ai

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