Книжный куб

Материалы Code of Leadership №84: разработчик становится менеджером в эпоху AI? (Рубрика #Management) Готовы запись и конспект Code of Leadership S2E26 от 6 октября 2026 года. Вместе с Андреем Дмитриевым, сооснователем JUG Ru Group, обсуждали, как меняется работа инженера, когда часть исполнения можно поручить агентам: кто выбирает задачу, организует работу и отвечает за результат? Агент может исправно готовить отчёт, который никто не читает. Работа идёт, ресурсы расходуются, а проверить, кому всё это ещё нужно, забыли. В разговоре возвращались к этому вопросу: прежде чем что-то ускорять, хорошо бы разобраться, стоит ли продолжать это делать. Обсудили: 🔸 Продуктового инженера и границы специализации Андрей выделяет знание предметной области и умение выяснять потребности пользователя. Опыт работы с языком программирования помогает, но готовых требований к незнакомому продукту может уже никто не принести. 🔸 Как проверить пользу до автоматизации Андрей рассказал о руководителе, который временно прекращал рассылку части отчётов: некоторые получатели этого даже не замечали. Хороший повод найти реального потребителя результата, прежде чем заводить для него ещё одного агента. 🔸 Жизненный цикл агента Подключить, обучить работе, контролировать и вовремя отключить. Андрей предлагает эту управленческую аналогию; мы обсуждаем доступы, критерии результата и поддержку инженера. Выданная подписка сама по себе процесс не создаёт. 🔸 Знания, которые нельзя потерять при делегировании Я описал подход, в котором код можно пересобрать из намерений, архитектурных правил, проверяемого поведения и причин решений. Андрей напомнил о противоречиях в документации. Проверять приходится и функции, и безопасность, и соблюдение архитектуры. 🔸 Софт под одну задачу и интерфейсы для агентов Рассказал про личный сайт для выбора района в Лондоне; Андрей — про бота, который уточняет требования и создаёт сайт. Обсудили и ограничения: актуальность данных, доступность источников, трудность объяснения собственных предпочтений. Прогнозы о будущем профессий в этом разговоре остаются нашими оценками. А вопрос к руководителю уже вполне практический: какую пользу он добавляет, когда часть координации тоже можно автоматизировать? Материалы выпуска: 📌 Страница выпуска с таймкодами 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект #CodeOfLeadership #Management #Leadership #AI4SDLC #Agents #Engineering

Проектирование обвязки для длительной (автономной) разработки приложений (Рубрика #AI4SDLC) В 33 выпуске Research Insights Made Simple мы разбирали SWE-agent: как интерфейс, инструменты и обратная связь меняют результат той же модели. В 34 выпуске — как передавать работу между сессиями, сохраняя список функций, прогресс и проверенное состояние проекта. В 35 выпуске мы говорили про подход OpenAI к созданию harness, а в этой статье "Harness design for long-running application development" Притви Раджасекарана идет речь про подход к снаряду ребят из Anthropic. По-факту, тут переход от рабочего места и памяти агента к организации автономной one-shot разработки целого приложения. У LLM с самооценкой легко получается «кукушка хвалит петуха»: написала что-то, сама проверила и решила, что всё отлично. Автор разделяет создание и оценку результата. В полной версии harness появляются три роли: 1) Planner разворачивает короткий запрос в продуктовую спецификацию. 2) Generator реализует приложение. 3) Evaluator проверяет работающую систему через браузер, API и состояние базы. По-моему, это уже очень похоже на команду с product manager, разработчиком и QA. Особенно интересен контракт спринта: до написания кода агенты согласуют, что должно получиться и как проверить готовность. Спецификация остаётся достаточно общей, а критерии приёмки связывают её с реализацией. При этом отдельный критик тоже требует настройки. Автор разбирал его логи и учил строже относиться к найденным проблемам. Для дизайна — задавал критерии цельности, оригинальности, качества исполнения и удобства, затем калибровал оценки на примерах. Здесь меня интересует граница: насколько можно формализовать вкус? Оценщик способен всё увереннее попадать в заданные предпочтения, но рост баллов ещё не гарантирует, что следующая версия понравится человеку больше предыдущей. Цена такого процесса тоже заметная. В примере редактора игр одиночный запуск стоил $9 и занял 20 минут, полный harness — $200 и шесть часов. По описанию автора, во втором случае заработал игровой режим. Но одновременно выросли бюджет, время и объём задания, поэтому вклад самого разделения ролей этим сравнением не изолирован. А дальше начинается самая полезная для инженеров часть: harness упрощают по мере усиления модели. На Opus 4.5 автор смог убрать явные сбросы контекста; на 4.6 — спринты, оставив проверку после сборки и циклы исправлений. Уже знакомый поворот из истории SWE-agent: части обвязки могут перестать быть нужными. Каждый такой элемент фиксирует предположение о слабости модели. Поэтому после её обновления стоит снова проверять, зачем нам эта передача работы, эта роль, этот промежуточный этап. Удалять их по одному и смотреть, что происходит с качеством, временем и стоимостью. И тут у меня следующий вопрос: сможет ли агент сам улучшать собственный harness — менять процесс, проверять результат и убирать лишнее? Звучит как естественное продолжение, но тогда особенно важно понять, кто будет оценивать самого оценщика. 9 октября в 9:00 по Москве разберём эту статью в прямом эфире Research Insights Made Simple. Обсудим устройство процесса, пользу отдельной приёмки и то, что останется от обвязки с усилением моделей. Приходите! #AI4SDLC #Agents #Engineering #Research #Evals

Материалы выпуска Research Insights #33: SWE-agent (Рубрика #AI4SDLC) Собрал материалы сольного выпуска Research Insights Made Simple от 5 октября 2026 года — «SWE-agent: интерфейс меняет результат». Разобрал, как одна и та же языковая модель решает задачи по-разному, когда меняются её инструменты и ответы среды. Инженеру помогают редактор, поиск и номера строк. У агента тоже есть рабочее место, только оно складывается из команд и текстовых ответов. Если после правки непонятно, что изменилось, следующий ход уходит на выяснение состояния файла. В [статье SWE-agent](https://arxiv.org/abs/2405.15793) с NeurIPS 2024 авторы исследуют, как такие детали влияют на способность довести исправление до работающего патча. В выпуске разобрал: 🔸 Как агент ориентируется в чужом проекте Поиск файла, поиск совпадений и просмотр кода с номерами строк — и почему удобный человеку перебор результатов может загнать модель в бесполезный обход. 🔸 Что возвращать после правки Команда edit сразу показывает обновлённый фрагмент. Если проверка отклоняет изменение, агент получает ошибку и оба варианта кода. Но у ограничения есть цена: оно может мешать нужному промежуточному состоянию. 🔸 Что оставлять в контексте Размер окна просмотра и старые ответы инструментов: после нескольких правок история уже хранит версии файла, которых больше нет. 🔸 Как читать результаты экспериментов Полный SWE-bench и Lite, запуски с демонстрацией и без неё, вклад отдельных компонентов. Несколько независимых попыток и продолжение застрявшего диалога — разные эксперименты. 🔸 Почему конструкцию агента приходится пересматривать В финале — SWE-smith, mini-SWE-agent с возвращением к bash и изменения SWE-bench Verified. Проценты и настройки из статьи относятся к экспериментам 2024 года. Для современных моделей заново проверять нужно и пользу специальной команды, и цену её ограничений. Материалы выпуска: 📌 Страница выпуска с таймкодами 📊 Слайды 📖 Лонгрид об эволюции агентных оболочек 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект #AI4SDLC #Agents #DevTools #Evals #ResearchInsights #Engineering

Justin Reock: код менять легче, деплоить страшнее (Рубрика #AI4SDLC) Новый доклад Justin Reock из DX продолжает его старую линию из предыдущего доклада, где речь шла о том, как процессы и инструменты вокруг инженера влияют на результат внедрения AI. А в новом докладе "The State of AI in Software Development: Data from 400+ Orgs" заместитель CTO компании DX возвращается к этой теме. Его тезис: ускорение генерации кода ограничено тем, как устроена остальная разработка. В данных, которые приводит Reock, есть интересное расхождение: - Оценка поддерживаемости кода разработчиками выросла почти на 4%; - Уверенность в изменениях снизилась на 6%; - Средний размер PR вырос примерно с 44 до 72 строк. Это наблюдения DX, а первые два показателя — оценки самих инженеров. Они не доказывают, что AI стал причиной всех изменений. Главный тезис доклада "Код стало проще менять, но деплоить его спокойнее не стало" и для меня здесь интересен разрыв между локальным пониманием и уверенностью в поведении всей системы. Агент может объяснить функцию и помочь ее переписать. Дальше остаются вопросы: какие контракты мы затронули, что действительно проверяют тесты, какие зависимости вообще не попали в контекст? Красивое объяснение diff само по себе на них не отвечает. Reock приводит пример: AI мгновенно генерирует функции, а сборка по-прежнему занимает 45–60 минут. Возникает соблазн собрать изменения в один большой PR. Это гипотеза о механизме, а не установленная причина роста PR во всей выборке. Я бы здесь проверял, сколько работы мы перекладываем на следующего человека. Автор быстрее закончил свою часть, а ревьюеру теперь нужно восстановить логику нескольких изменений одновременно. Если проверка обнаружит проблему, сколько времени займет переделка? И останется ли выигрыш после нее? Без этих вопросов легко принять локальную экономию времени за улучшение всего процесса. Кстати, это хороший повод вернуться к фреймворку DX Core 4, который я уже разбирал. Там продуктивность рассматривается через speed, effectiveness, quality и impact. Для такого кейса я бы смотрел рядом на время прохождения PR, его размер, возвраты на доработку и сбои после выпуска. Опрос про уверенность тоже нужен: он помогает найти места, где команда боится менять код, даже если счетчик поставленных изменений растет. А техническая сторона уже была в разборе Max Kanat-Alexander про DevEx для агентов: быстрые предсказуемые тесты, понятные ошибки, документация с контекстом и управляемая нагрузка на ревью. Если агент часто запускает тесты, каждая лишняя минута ожидания повторяется вместе с этим циклом. Получается вполне предметный повод наконец заняться медленным CI:) При этом размер PR я бы не превращал в самостоятельный KPI. Можно нарезать одно связное изменение на десяток неудобных кусков и получить красивый график. Важно, может ли проверяющий понять замысел, проверить последствия и при необходимости откатить изменение. Поэтому после внедрения AI я бы задавал команде такой вопрос: мы стали быстрее доводить изменения до состояния, за которое готовы отвечать, или пока только быстрее наполняем очередь на проверку? P.S. На обложку конечно вынесен более провокационный вопрос:) #AI4SDLC #Engineering #DevEx #Productivity #Metrics #Management

Зачем руководитель возвращается к коду — материалы выпуска (Рубрика #Leadership) Вышел 82-й выпуск Code of Leadership: 1 октября поговорили с Никитой Белокопытовым, который руководил инженерными командами в AutoScout24 и Playrix, а сейчас занимается прикладным ИИ в Bluefish. Зачем снова садиться за разработку, когда уже умеешь управлять людьми? Никита объясняет свой выбор вполне практично: как руководить командой, если её новые инструменты и даже проблемы тебе незнакомы? Обсудили: 🔸 Как техническая правота мешает стать руководителем Никита рассказал, как однажды заявил менеджеру, что хочет занять его место, и получил предложение спросить коллег, хотят ли они такого начальника. После честной обратной связи пришлось менять привычки общения. В календаре появилось ежедневное напоминание BeKind. 🔸 Почему сильнейшие программисты не первыми переходят на Cursor По наблюдению Никиты в Playrix, ускорение написания кода мало меняло работу тех, кто и так пишет быстро, а основное время тратит на обдумывание задачи. Более полезным оказался разбор багов с агентами — когда для них задали граф состояний, инструменты и изолированную среду. 🔸 Что остаётся от менеджерского опыта без подчинённых Найти владельца системы, договориться об изменении, снять препятствие, взять ответственность — всё это пригодилось Никите в инженерной роли. Он допускает, что небольшим автономным командам понадобится меньше управленческих слоёв; это его прогноз, а не готовое правило для любой компании. 🔸 Где заканчивается автономность агента В Bluefish агент берёт небольшую задачу из Jira и доводит её до PR. Но необходимость задачи определяет человек, а за изменение основной системы отвечает инженер. В другом эксперименте Никита упёрся в собственный предел проверки — пять-шесть PR в день; отдельные циклы исправлений между агентами доходили до 60 итераций. Отсюда ограничения по деньгам, времени и числу повторов. 🔸 Как погружаться в код без микроменеджмента Разобраться в системе самому полезно, но дальше нужно уметь разговаривать с командой. Иначе новые технические знания легко превращаются в новые поводы вмешиваться в чужую работу. Материалы выпуска: 📌 Страница выпуска с таймкодами 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект разговора Если вы после нескольких лет управления снова вернулись к разработке, расскажите: что пришлось учить заново, а какой менеджерский навык неожиданно пригодился? #CodeOfLeadership #AI4SDLC #Management #Leadership #Engineering #Product

Harness engineering: как экспериментальная команда внутри OpenAI перестраивала разработку вокруг агентов для одного из внутренних продуктов(Рубрика #AI4SDLC) Готовясь к 35-му выпуску Research Insights, изучал статью OpenAI про harness engineering. Вышла она 11 февраля 2026 года, и для того момента здесь очень много интересных и прорывных мыслей о работе инженера. Особенно если читать её через вопрос: что нужно сохранить о системе, когда сам код становится всё дешевле? Команда Райана Лопополо строила внутренний продукт, сознательно запретив себе писать код руками. По их данным, за пять месяцев получилось около миллиона строк, включая документацию и инфраструктуру, и примерно 1500 принятых PR. Инженеры занимались средой, в которой Codex мог выполнять работу. Из статьи я бы выделил четыре вещи: 1️⃣ Знание должно быть доступно агенту. Короткий AGENTS.md служит картой документации. Требования и причины решений живут в репозитории. 2️⃣ Архитектуру нужно проверять. Допустимые зависимости и границы слоёв закреплены линтерами и структурными тестами. 3️⃣ Агенту нужны глаза. Доступ к интерфейсу, логам и метрикам позволяет ему воспроизводить ошибки и проверять исправления. 4️⃣ Сложность требует регулярной работы над ее снижением. Фоновые задачи ищут отклонения и предлагают небольшие рефакторинги. Ошибки становятся поводом улучшать правила и инструменты. Мне здесь нравится перенос инженерного суждения в среду: сформулированное требование можно многократно применять и проверять. Очень рифмуется с темой моего keynote на DotNext — знание о системе должно переживать её реализацию. А у этой истории оказалось занятное продолжение. В апрельском интервью Лопополо рассказал, что работал в Frontier Product Exploration, команде корпоративных агентных продуктов. И первые полтора месяца такой разработки, по его оценке, были примерно в десять раз медленнее ручной работы. Пришлось вложиться в инструменты и контекст, прежде чем эксперимент начал окупаться. Следующим узким местом стало переключение между сессиями агентов (мы про эту проблему говорили в выпуске Research Insights #34). Так появился Symphony: он забирает задачи из Linear, запускает агентов в отдельных рабочих пространствах и доводит работу до приёмки. Человек задаёт работу и оценивает результат. Интересно, что в репозитории Symphony есть спецификация SPEC.md и экспериментальная реализация на Elixir. Можно попросить агента построить свою версию по этой спецификации. Получается вполне предметный шаг к восстановлению реализации из сохранённого знания. К сентябрю Лопополо уже работал в Google Cloud и в новом разговоре советовал вкладываться прежде всего в инструменты и контекст: переносить исправления из разовых подсказок в документацию, линтеры и тесты. При этом исходный эксперимент начинался с пустого репозитория. В апреле автор уточнял, что перед выпуском приложения оставался человеческий smoke-тест. Переносить такой процесс в зрелую систему нужно с пониманием её рисков. Приходите на 35-й выпуск Research Insights в эту пятницу: про статью поговорим подробнее — где здесь воспроизводимая инженерная практика и что нужно уметь проверять, прежде чем отдавать агентам больше работы. P.S. Не смог приложить PDF, так как просто Ctrl + P на сайте OpenAI приводит к сохранению PDF, в котором теряется часть текста - пришлось читать статью по старинке, из браузера:) #AI4SDLC #AI #Agents #Engineering #Architecture #PlatformEngineering

Заходите на прямой эфир Research Insights #34, где я расскажу про прошлогоднюю статью, в которой ребята из Anthropic делились своим опытом передачи работы между разными сессиями одного и того же агента. Этот выпуск продолжает историю про SWE-agent, что мы разбирали в выпуске #33

Warp: поправили агента. Чему научилась система? (Рубрика #AI4SDLC) Интересная история от создателя Warp, которая продолжает разбор Factory, где мы обсуждали, как организовать исполнение и проверку агентных задач, а также разбор Conductor, где мы говорили о том, а как человеку управлять несколькими исполнителями. Но после обоих остаётся вопрос: если сегодня пришлось поправить агента, что изменится в его работе завтра? Zach Lloyd, основатель и CEO Warp, предлагает сделать такие исправления материалом для улучшения всего процесса. Его доклад «Software Engineering Is Becoming Factory Engineering» прошёл на AI Engineer World's Fair 30 июня 2026 года, а отдельная запись появилась 27 сентября. По мысли Lloyd, инженер будет всё больше заниматься системой, которая производит изменения в продукте. Warp продаёт инфраструктуру для такого процесса, поэтому интерес компании понятен. Сам процесс узнаваемый: разобрать задачу, подготовить спецификацию, написать код, проверить, выпустить и наблюдать за результатом. Люди у Lloyd продолжают проверять спецификации, код и поведение продукта. Мне здесь интереснее второй цикл — работа над самим процессом. Агент делает ревью, опытный инженер исправляет его замечание. Агент-наблюдатель разбирает эту обратную связь и предлагает обновить skill — инструкцию для следующих ревью. Так исправление может пережить текущий PR и помочь другим участникам команды. Это хорошо продолжает историю Vercel d0: там повторяющиеся запросы превращались в навыки, а я задавался вопросом, кто дальше проверяет и обновляет накопленное. Warp предлагает использовать для этого в том числе замечания людей. Причём после доклада идея стала конкретнее. В июльском руководстве Warp агент уже открывает PR с изменением навыка ревью. А в документации, обновлённой 24 сентября, предлагаемые исправления связаны с неудачными запусками и требуют человеческой проверки. Здесь «самоулучшение» означает изменение инструкций и процесса; обучение весов модели из этого не следует. Со способом оценивать успех я бы поспорил. В обращении к команде Lloyd предлагает считать работу с агентом в ручном интерактивном режиме неудачей, из которой нужно извлечь урок. Цель — увеличивать долю автоматических изменений. Повторные объяснения уже известного правила хочется убрать. А совместный поиск решения для новой задачи может быть полезной работой, даже если снижает долю автоматических изменений. Здесь снова вспоминается Dex Horthy из HumanLayer с его вниманием к проектированию и пониманию системы. Я бы оценивал, какие вмешательства удалось убрать и что стало с качеством результата. Процент автономных задач сам по себе этого не покажет. Правда надо отметить, что и человеческое замечание тоже может быть ошибочным. Если сразу превратить его в общую инструкцию, завтра агент начнёт старательно повторять уже нашу ошибку. Из этого я бы забрал три практических шага: 1️⃣ Найти одну повторяющуюся правку Посмотреть последние ревью, сформулировать правило и сохранить пример ошибки. Начать с небольшого навыка, пользу которого можно проверить. 2️⃣ Проверить новую инструкцию на других задачах Сравнить старую и новую версии, включая случаи, где раньше всё работало. Принимать изменение после проверки и сохранять возможность отката. 3️⃣ Посчитать полную стоимость результата Включить время на постановку, ревью и переделки, расходы на модели и обслуживание автоматизации. Затем проверить, стало ли меньше повторных исправлений при сопоставимом качестве. #AI4SDLC #AI #Agents #PlatformEngineering #Evals

Обвязка агента по Anthropic: как передавать работу между кодинговыми сессиями (Рубрика #AI4SDLC) Для Research Insights Made Sijmple #34 разбираю "Effective harnesses for long-running agents" — инженерный пост Джастина Янга из Anthropic почти годовалой давности (26 ноября 2025 года). Меня зацепил вопрос: что останется от работы агента, когда закончится его контекст и следующей сессии придется продолжать проект? В этой статье Anthropic описывает опыт сборки клона claude.ai. Агент пытался сделать слишком много за один заход, оставлял недоделанную функцию без понятного описания, а следующий экземпляр тратил время на восстановление. Или видел уже написанный код и радостно объявлял весь проект готовым. Сжатие истории разговора само по себе эти проблемы не устраняло. Получается разработка со сменами: каждый новый инженер приходит без памяти о предыдущем. Оставить ему «я тут поработал, все почти готово» — так себе передача дел :) Авторы собирают протокол вокруг нескольких вещей: — Инициализатор готовит среду, скрипт запуска и список функций с критериями проверки. Изначально все функции помечены как неготовые. — Следующие сессии берут по одной функции, проверяют результат, сохраняют изменения в Git и обновляют журнал прогресса. — В начале новой сессии агент читает журнал и историю коммитов, проверяет, что приложение работает, и выбирает следующую задачу. — Для веб-приложения проверка включает сценарии в браузере. Код может выглядеть убедительно, пока пользователь не нажмет кнопку. Кстати, «два агента» здесь — две фазы с разными стартовыми промптами. В сноске авторы уточняют, что системный промпт, инструменты и обвязка одинаковы. Доказательств пользы роя из этого не получается. Еще любопытная деталь: по наблюдению авторов, агент реже нежелательно переписывал список требований в JSON, чем в Markdown. Чисел и условий сравнения нет, так что я бы считал это гипотезой для проверки. Тем более JSON сам по себе ничего не запрещает: если важно сохранить требования, нужно отдельно проверять изменения. Просьба «не меняй тесты» технического ограничения не создает. Меня здесь интересует разница между сохраненным рассказом о работе и проверенным состоянием проекта. Журнал помогает понять намерение, Git — увидеть изменения, список функций — вспомнить обязательства, а тесты — проверить результат. У каждого артефакта своя роль. Галочка passes: true, которую агент поставил себе сам, без надежной проверки остается его мнением. Называть этот пост научным прорывом я бы не стал: это опыт команды производителя на веб-разработке, без контрольной группы и количественных сравнений. Зато он хорошо показывает, сколько обычной инженерной дисциплины требуется, чтобы агент мог продолжать большую задачу. И рецепт меняется вместе с моделью. В продолжении от марта 2026 года Anthropic описала отдельного оценщика и отказ от принудительных сбросов контекста при переходе с Sonnet 4.5 на Opus 4.5. Полезно разбирать, какую конкретную слабость компенсирует каждый элемент обвязки и нужен ли он в следующей конфигурации. Завтра, 7 октября, в прямом эфире Research Insights #34 подробнее поговорим про эту статью: как передавать работу между сессиями, чему доверять в отчете агента и когда разделение ролей действительно помогает. Приходите, будет что обсудить. #AI4SDLC #AI #Agents #Engineering #Research

Забегаайте на прямой эфир с Андреем Димтриевым из JUG.RU, где мы обсудим, что сейчас разработчик становится менеджером, хочет он этого или нет