Книжный куб

Люблю встречаться с интересными людьми на встречах CxO Community. Такие коммьюнити есть у разных компаний, но у Сбера это часто связано не только с нетворкингом, но и с интересным опытос. В прошлый раз событие было вокруг дегустации вин, а в этот раз мы слушаем Оскара Конюхова, руководителя штаба его отца, Федора Конюхова. Рассказ идет про планирование и реализацию сложных проектов на грани технических и человеческих возможностей. Спасибо организаторам Sber CxO TechCommunity, это реально интересные мероприятия.

Research Insights Made Simple #23 - Экономика AI в разработке (Рубрика #AI4SDLC) Голосование показало, что тема интересна и поэтому завтра в 17:00 в прямом эфире разберём экономику AI в разработке. Суть в том, что токены дешевеют, модели становятся быстрее, но AI-бюджет компании от этого не обязательно уменьшается. Чем больше появляется рабочих сценариев, тем больше становится задач, агентных цепочек, инфраструктуры, проверок и цены ошибок. Поговорим о том: - Почему удешевление фиксированного уровня качества расширяет спрос и способно увеличить общий бюджет; - Как агентная задача превращается в длинный trace с десятками вызовов, повторами и растущим контекстом — и почему ограничения нужны на весь workflow; - Как считать cost per accepted task, включая инструменты, инфраструктуру, человеческую проверку, переделки и цену ошибки; - Зачем сначала вводить общий quality gate и showback, а уже потом chargeback, роутинг и оптимизацию стоимости; - Где возникает vendor lock-in и когда локальная модель действительно выгоднее облачной после учёта качества и эксплуатации. Отдельно покажу рабочий сценарий до 2029 года: цена сегодняшнего уровня качества может снизиться в разы, а бюджет успешного AI-портфеля — вырасти. Это не обещание рынка, а рамка для разговора о том, что именно компания получает за эти деньги. Основной вопрос эфира про то, какая единица связывает качество, стоимость и риск? Токены удобны для счёта поставщика. Для инженерной организации полезнее принятая работа — задача, которая прошла проверку, не потребовала дорогой переделки и дала нужный результат. Материалы к эфиру: дека и лонгрид, а также можете закидывать свои вопросы в комментариях к этому сообщению. #AI #AI4SDLC #Engineering #FinOps #Agents #Management #Metrics

Вчера выступал на Podlodka AI Club и рассказывал свои мысли про экономику AI в разработке. Когда готовился, то собрал вот такой лонгрид и вот такую слайд деку, но само выступление не записывалось. Я могу записать отдельное видео для подписчиков канала, если вы хотите, но давайте соберем 👌 под этим постом, чтобы я понял, что вам эта идея нравится. Если их будет больше двадцати по итогу, то видео выйдет на Youtube, если нет, то останется только текстовые версии.

Грэм Уивер: как придумать игру, в которой хочется победить (Рубрика #Management) Посмотрел последнюю лекцию Грэма Уивера для класса Stanford GSB 2025 года - «How to Design a Winnable Game». Грэм - преподаватель менеджмента в Стэнфорде, основатель и партнер Alpine Investors. Но говорит он не об инвестициях, а о моменте, когда понимаешь: много лет ты успешно играешь не в свою игру. Начинается лекция с личного момента, когда во время кризиса 2008 года, по словам Уивера, фонд потерял 40%, крупнейший инвестор решил уйти, а он ночью считал, на сколько месяцев семье хватит сбережений, пока рядом спала новорожденная дочь. Вместо «как работать лучше, быстрее и больше?» появился другой вопрос: «а в ту ли игру я вообще играю?». И выигрышная игра в его понимании - та, в которой внешний успех не спорит с внутренним ощущением смысла. Ее не находят в готовом виде, а проектируют по четырем правилам. 1️⃣ Выбрать цель, которая по-настоящему зажигает Не ориентир «лишь бы не проиграть», а направление, ради которого хочется вставать утром. Большая цель меняет наши действия и готовность идти долго. 2️⃣ Придумать собственную игру Многие ограничения - не правила, а привычки отрасли. Стоит искать то, что ненавидят клиенты, чего не делают конкуренты, что лично не дает покоя, - и развивать уже работающие сильные стороны. 3️⃣ Играть с людьми, которыми восхищаешься Окружение формирует наши цели, ценности и характер. Важно выбирать людей, рядом с которыми можно оставаться собой и не приносить жизнь в жертву результату. 4️⃣ Начать сейчас «Не сейчас» - удобная форма страха. Жизнь не начинается после кредита, повышения или смены работы. Все, что мы пытаемся поскорее «пройти», и есть наша жизнь. Это очень глубокое и личное выступление. Оно не обещает быстрых ответов, но мотивирует остановиться, честно посмотреть на свою жизнь и начать изменения — не когда-нибудь, а сейчас. Ну и я забрал из этой истории идею о том, что прежде чем становиться эффективнее, стоит проверить саму систему координат. Хочу ли я победить в этой игре? Делает ли участие в ней меня тем человеком, которым я хочу быть? И с теми ли людьми я ее прохожу? P.S. Мне вспоминалась другая последняя лекция примерно того же уровня «Randy Pausch Last Lecture: Achieving Your Childhood Dreams», о которой я рассказывал раньше. Обе эти лекции построены похоже и мотивируют посмотреть на свою жизнь и понять, а занимаешься ли ты тем, что действительно хочешь ... и если нет, то это значит, что пора что-то менять. #Management #Leadership #Career #Goals #Stanford

ArchBench: хороший каркас, слабый лидерборд (Рубрика #Architecture) Прочитал короткую работу "ArchBench: Benchmarking Generative-AI for Software Architecture Tasks". Идея здравая: собрать разрозненные evals для software architecture в одну расширяемую систему. Но на 19 июля 2026 года это скорее каркас будущего бенчмарка, чем рабочий лидерборд для выбора модели (можете сами оценить лидерборд на сайте бенча). Команда SERC из индийского IIIT Hyderabad собрала открытую систему из CLI и React-сайта. Каждая задача - это плагин со своим загрузчиком данных, промптом, парсером и метриками. Общий конвейер проходит стадии загрузки, инференса и оценки, сохраняя промпты, сырые ответы, использование токенов и latency. Результаты и новые задачи предполагается принимать через PR. Но наполнение у самого бенча слабое - всего 5 задач - Генерация ADR (architecture decision records) - Генерация serverless-компонентов - Создание dynamic IoT сервисов - Создание микросервисов - Восстановление traceability Эти задачи не покрывают архитектурный анализ, размышление о зависимостях, масштабный рефакторинг или работу с компромиссами. Причем end-to-end автоматизированы в CLI только написание ADR и восстановление traceability, а еще три таблицы с метриками перенесены из исходных исследований, их пайплайны для оценок пока интегрируются. Метрики смешивают разные вещи - ROUGE и BERTScore измеряют похожесть текста (для написания ADR) - Test pass rate - функциональность кода при генерации сервисов и функций Правда, это далеко от оценки качества архитектуры. Агентных sandbox-окружений для использования инструментов у ребят пока нет пока нет. Набор моделей тоже удивляет: GPT-3.5, старые GPT-4, Flan-T5/T0, CodeQwen и DeepSeek прежних поколений. В генерации микросервисов есть Codex и Claude Code, но без точных версий и конфигураций, а значит сравнивать такие цифры сложно Авторы отмечают, что рассчитывают на коммьюнити рост (вот GitHub бенча, если захотите законтрибьютить), но в публичной истории на 19 июля не видно внешних контрибьютов с новыми задачами или результатами моделей. После статьи менялись интерфейс и код, но не сам измерительный корпус. Итого, этот бенч выглядит как концепт, но он станет реальным бенчом после расширения задач, полной автоматизации, запуска современных версионированных моделей и появления независимых участников. А пока это приглашение строить бенч. #Architecture #AI #AI4SDLC #Evals #Research

McKinsey про экономику AI-агентов: считать не токены, а результат (Рубрика #Management) Прочитал интервью McKinsey с Дэвидом Теппером, CEO AI-FinOps-платформы Pay-i, про экономику агентных систем. В этом разговоре интересно то, что это взгляд не изнутри ИТ с моделями, контекстом, evals и tool calls, а со стороны CIO, CFO и владельца процесса. Какие агенты заслуживают бюджета и как это доказать? Photo Основная мысль в том, что цена токена почти ничего не говорит о ценности системы. Токены - это счёт, а не результат, причем агент может сделать сотни вызовов, по-разному пройти одну задачу и потратить в 30 раз больше или меньше ресурсов. Считать нужно стоимость завершённой и принятой бизнес-задачи. McKinsey разделяет три сущности, которые рынок привык одинаково называть агентами. - Workflow - обычный процесс с AI на отдельных шагах; - Pipeline - заранее известная последовательность вызовов; - Настоящий агент - сам выбирает инструменты, порядок действий и длительность работы. У первых двух расходы ограничены архитектурой, у агента стоимость становится распределением с длинным хвостом. Автономность нельзя покупать «на всякий случай»: она должна окупать собственную неопределённость. Исследования агентного программирования, на которые ссылается статья, дают показательные оценки: до 1000 раз больше токенов, чем в обычном coding chat, и около 59% расхода на проверку и исправления (1 и 2). Это не нормативы для любого бизнеса, но механизм важен: дороже всего может оказаться доведение результата до приемлемого качества. Автор предлагает так оценивать, когда стоит внедрять агента: P(success) > T(verify) / T(do). Если человек выполняет задачу два часа, а результат агента проверяет за шесть минут, агенту достаточно для паритета с человеком примерно 5% успешных попыток. Но это верно, если ошибка не имеет внешних ээффектов. Плохой документ можно выбросить; неверное обещание клиенту уже создаёт стоимость восстановления. Проверку и переделку Теппер называет «налогом автономности» — agency tax. Здесь особенно заметен бизнес-взгляд гостя интервью - Технических метрик - latency, error rate, стоимость вызова - недостаточно. - До запуска нужно определить, какой KPI меняет агент: время обработки заявки, выручку, число ошибок, конверсию. - ROI - не KPI, а расчёт на основе KPI и полной стоимости сценария. Практический план поэтому организационный: провести инвентаризацию агентов, назначить владельцев и бизнес-KPI, измерять результат всего workflow, а не только счёт провайдера, и собрать общий контур управления из финансов, ИТ и бизнес-заказчика. KPI после пилота легко превращается в оправдание уже сделанных расходов. Этот ракурс полезен, но не самодостаточен. Бизнес-метрики не заменяют evals, безопасность и инженерную надёжность. Как и идеальная архитектура не отвечает на вопрос, зачем агент нужен компании. Для меня главный вывод: обсуждение агента стоит начинать с единици ценности, критериев приёмки, цены проверки и последствия ошибки, а уже затем думать про архитектуру и токены. Тогда AI становится не экспериментом внутри ИТ, а управляемой инвестицией бизнеса. #AI #Agents #Management #FinOps #Metrics #Engineering

Theo Browne про AI-разработку: мыслить шире, проектировать строже (Рубрика #AI4SDLC) Посмотрел заключительный keynote Theo Browne «Everything we knew about software has changed» с AI Engineer World's Fair 2026. Theo строит инструменты для разработчиков, поэтому его интересно слушать не как комментатора моделей, а как практика, у которого AI уже изменил масштаб проектов. Главная мысль его доклада: границу «слишком большого» пора провести заново. Сдвиг Theo показывает через собственную лестницу - Reddit scraper был проектом на два-три дня - Ping, сервис для совместных стримов, стал стартапом и прошёл Y Combinator - Full-stack cloud - условный Vercel с базами данных - казался затеей для большой компании. Теперь, считает Theo, вся лестница сдвинулась вниз: вчерашний стартап становится side project, а внутренний сервис - исполняемой инструкцией. Его агент каждое утро разбирает pull requests в четырёх репозиториях, расставляет приоритеты и публикует HTML-отчёт в S3. Вместо отдельного сервиса - Markdown и cron. Переход Theo связывает с тремя поколениями моделей: 1) Sonnet 3.5 для него дал надёжный tool calling 2) Opus 4.5 - длинные самостоятельные задачи 3) Mythos (Fable 5) - оркестрацию с дополнительными агентами. Это его личная карта, а не бенчмарк, но вопрос интересный: выдавая новой модели старую работу размером с Jira-тикет, не пропускаем ли мы возможность ставить задачи другого масштаба? Самая интересная часть - переход от узких продуктов к широким. Theo считает, что маленькая команда теперь может собрать большую поверхность продукта, а недостающую глубину отдать пользователям через расширения. Но разработка всё ещё живёт в «скевоморфной фазе»: мы работаем через естественный язык, сохраняя ограничения времён дорогого кода. Отсюда провокация в финале: почему бы не попробовать конкурировать со Slack, AWS или Salesforce? Здесь нужна инженерная оговорка. Ширина прототипа и зрелость продукта - разные вещи. AI удешевляет реализацию, но не отменяет модель данных, миграции, права доступа и наблюдаемость. Пользователь сможет достроить продукт только там, где есть стабильные контракты и безопасные примитивы. Смотреть доклад стоит не ради прогноза о победе маленьких команд над AWS. Он показывает путь Theo от двухдневного скрипта к проектам, которые раньше он сам отбрасывал как невозможные, и хорошо перенастраивает масштаб мышления. #AI #AI4SDLC #Engineering #Architecture #Product #Agents

Опубликовал лонгрид о конфигурациях агентного стека. Спор обычно сводят к выбору между «своим OpenCode» и «чужим Claude Code или Codex», но это ложная развилка: отдельно выбираются обвязка, модель и инструменты, а контроль нужен над всей цепочкой _ от данных и идентичности до фактического действия в системе. Разобрал восемь вариантов стека: их TCO, lock-in, характерные отказы и границы безопасности. Главный вывод: суверенность и безопасность — свойства всей архитектуры, а не отдельного компонента. Сегодня в 17:00 МСК будем разбирать эти идеи на стриме с Мишей Трифоновым: что выбрать для пилота, корпоративной платформы и регулируемого контура. #AI4SDLC #Agents #Architecture #PlatformEngineering

Бенуа Шиллингс: R&D после кода (Рубрика #AI4SDLC) Посмотрел keynote доклад Бенуа Шиллингса, VP из Google DeepMind на AI Engineer World’s Fair 2026. Его позиция мне интересна - он не лидер продуктового ИТ, внедряющий агента в SDLC, а руководитель R&D. Его команда создаёт технологии, которые понадобятся Gemini на горизонте от месяца до года. Поэтому вместо backlog, CI/CD и SLO он обсуждает, чему должна научиться следующая модель. У истории забавное начало. В 2018 году его команда в X запустила проект Pitchfork про применение ML к коду, но идею почти никто не воспринимал всерьёз. Сам Шиллингс отвергал программирование на естественном языке: для этого уже есть языки программирования. Теперь человек с 45-летним опытом - от ассемблера до Python - признаёт ошибку и использует vibe coding. Главный тезис: генерация кода и software engineering - это разные задачи. По мнению Шиллингса, модели уже генерируют синтаксис лучше человека. Но настоящая разработка начинается, когда нужно изменить систему с 35 миллионами строк PHP, учесть архитектуру, безопасность и последствия решения через десять лет. Узкое место переезжает в постановку задачи, декомпозицию и проверку замысла. Код для DeepMind - это удобная R&D-лаборатория: данных много, результат проверяется компилятором и тестами. Следующий шаг - self-play, где модель сама создаёт задачи, решает и проверяет их, как AlphaZero учился через игру с собой. Ограничением становятся compute и качество среды обучения. Исследовательский roadmap из доклада выглядит так: - Учить модель писать безопасный код сразу, а не только находить уязвимости постфактум; - Развивать планирование, декомпозицию и перенос идей между областями; - Менять evals: проверка «запустилось и выдало ответ» слишком узка для архитектуры; - Выходить за линейную цепочку токенов к мультимодальным представлениям; - Возможно, создавать строгие языки для моделей, даже если человеку их будет неудобно читать. Последний пункт особенно хорошо показывает R&D-оптику: снять ограничение читаемости кода человеком и переложить доказательство корректности на модель и язык. Шиллингс прогнозирует, что код станет почти бесплатным, его объём взорвётся, а через год люди почти перестанут читать результат агента - как сегодня редко проверяют ассемблер после компилятора. Это прогноз, не факт и есть определенная разница между агентом и компилятором - последний работает по строгой спецификации, а агент - в неоднозначном бизнес-контексте. За рамками остаются legacy, ownership, SLO, стоимость inference и rollout. Зато финал уходит в химию и биологию: для Шиллингса coding models - полигон для общего reasoning и научных открытий. Мне это выступление понравилось - это не инструкция по внедрению AI в ИТ (с этим у меня проблем нет), а скорее карта upstream-исследований. Условно - R&D спрашивает: «Что модель сможет открыть и построить?» - Продуктовое ИТ добавляет: «Как доказать, что результат нужен, безопасен и управляем?» #AI #AI4SDLC #Research #Engineering #Architecture #Evals

Алексей Миловидов и ClickHouse: от любопытства до компании в $15 млрд (Рубрика #Software) С большим интересом посмотрел большое интервью Елизаветы Осетинской (иностранного агента) с Алексеем Миловидовым, создателем и CTO ClickHouse. Формально это история компании с оценкой $15 млрд. Но мне она показалась интереснее как путь инженерного проекта: от любопытства и внутреннего инструмента до open source и глобального бизнеса. Программировать Алексей начал на советском БК-0010. Игру можно было загрузить с кассеты или вручную набрать десять страниц кода из журнала. Если ошибся, вспоминает он, игра могла работать «чуть-чуть по-другому». Старшие братья в итоге просто выдали ему книгу: «Разбирайся». Позже он поступил на мехмат МГУ, хотя хотел на ВМК, а затем выбрал «Яндекс» — несмотря на меньшую зарплату. В первый же отпуск руководителя система веб-аналитики, которую поддерживали два человека, перестала справляться с трафиком. Алексей её стабилизировал, а затем захотел отчёты в реальном времени с произвольными разрезами. Так из практической боли начал расти ClickHouse. Название сложилось из clickstream и data warehouse. Когда аналитики «Яндекса» вместо многочасовых Perl-скриптов получили ответы за секунды, технология выглядела как магия. При этом её долго почти не замечали — и это оказалось преимуществом: команде не мешали спокойно строить систему. В 2016 году ClickHouse открыли как open source. Алексей называет это способом «проникнуть на рынок, пока никто не видит». Сначала появились пользователи, контрибьюторы и митапы, а уже потом — компания. Бизнес построили вокруг того, чего нет в «голом» движке: масштабирования, резервного копирования, безопасности и интеграций. Самостоятельно можно бесплатно; тем, кто не хочет содержать отдельную экспертизу, продают ClickHouse Cloud. Сам стартап тоже собирался необычно. В 2021 году 12–14 человек переходили из «Яндекса», а трое кофаундеров знали друг друга только по Zoom — онлайн-дейтинг, шутит Осетинская. В компанию уже вложили $50 млн, хотя облачного продукта ещё не было, а у нанятой sales-команды оставался вопрос: «Да что продаём-то?» Роли разделили прагматично: Аарон Кац — бизнес и продажи, Юрий Израилевский — облако и команды, Миловидов — технология. Алексей не стал CEO: без опыта шанс убедить нужных людей он оценивал примерно в 5%. Сейчас в компании больше 600 сотрудников, но формально он не руководит никем, работает со всеми и соглашается с ролью «создателя тревоги». В истории много таких деталей. Квартиру в Амстердаме Алексею сдала хозяйка, чья сестра знала ClickHouse по Китаю. За четыре с половиной года он выучил по-нидерландски главным образом goedemorgen. А AI-сотрудник Groene AI чинит «красные» тесты и уже подружился с особенно угрюмым контрибьютором. Если сокращать, то получаются два основных момента - ClickHouse вырос не из гениального питча, а из цепочки хорошо решённых инженерных проблем (а я помню как лет 10 назад ClickHouse захватывал рынок аналитических решений в России, так как других решений такого класса в opensource не было) - Но одной технологии было мало, ее создателю пришлось увидеть продукт глазами клиентов, доверить продажи и компанию людям с другим опытом и продолжать строить крутой продукт #Software #Data #OpenSource #Engineering #Architecture #Management

Материалы про кодинговых агентов и важность экспертизы (Рубрика #AI4SDLC) Готовы материалы с подкаста Code of Leadership, который был в среду с Евгением Сергеым: - Презнтация: Слайд дека с разбором - Видео: Youtube, VK - Аудио: Podster, Ya Music - Текст: Краткая расшифровка #AI4SDLC #Agents #Architecture #Engineering #Software #Books

The Java Story: как язык стал долгоживущей платформой (Рубрика #Software) Посмотрел вчера в прямом эфире документалку «The Java Story» от CultRepo про историю Java. В кадре были James Gosling, Joshua Bloch, Brian Goetz, создатели Tomcat, Spring, Hibernate и Kotlin, а также инженеры Java-экосистемы. Но для меня это не столько история просто языка, скорее это история про целую технологическую платформу, что пережила собственные ошибки, смену владельца и попытки объявить её мёртвой. И кажется, что причина в том, что эта платформа научилась меняться, не разрывая экосистему. Совместимость, управление платформой и сообщество оказались важнее красоты отдельных языковых решений. Изначально java называлась Oak и ее создавали для бытовых вычислительных устройств. Интерактивное телевидение не взлетело, команда переключилась на веб, а настоящий масштаб Java в итоге нашла на сервере. Уже здесь видна повторяющаяся схема: технология сохраняет ядро, но меняет рынок и задачу вокруг него. Даже знаменитое мотто write once, run anywhere в фильме постепенно перестаёт быть рекламным лозунгом. Конфликт Sun с Microsoft показан как борьба за то, кто контролирует платформенный контракт. Если реализация Java под Windows становится несовместимой с остальными, переносимость исчезает, а вместе с ней - и сама причина существования платформы. Здесь Microsoft тех лет представлен в виде гиганта, что греб все под себя:) Но одной защитой совместимости экосистему не построить. Java Community Process формализовал участие компаний и сообщества в развитии спецификаций. Tomcat показал Sun, что открытый код не обязательно ведёт к хаосу. Позже OpenJDK закрепил ещё более важную мысль: платформу можно открыть, не отказываясь от общего контракта. Здесь история начинает переплетаться с другими фильмами. J2EE пыталась стандартизировать корпоративную разработку сверху, но стала слишком тяжёлой для повседневной работы. Spring и Hibernate ответили снизу: обычные объекты, тестируемость и более прямой контроль над кодом. В фильме это сформулировано довольно жёстко: сообщество открытого кода справилось там, где спецификации и поставщики платформы не услышали разработчиков. А когда после Java 5 развитие языка замедлилось, сама виртуальная машина Java (JVM) не опустела. Scala, Clojure и Kotlin предложили более современные модели, сохранив библиотеки, инструменты и среду выполнения Java. Это сильная платформенная конструкция: недовольство языком не обязательно означает уход из экосистемы. Иногда новая идея сначала появляется рядом, а затем заставляет основную платформу двигаться. Полезно сопоставить эту линию и с .NET. В фильме Microsoft сначала выступает угрозой из мира закрытой Windows-платформы. Но позднее C# и .NET сами прошли путь к открытому коду и кроссплатформенности. Получается не простая история «Java против Microsoft», а две разные траектории к одной задаче: как удержать разработчиков, не запирая их в технологическом тупике. Современная Java продолжает ту же логику. Java 8 добавила лямбды и Stream API, не создавая отдельный «новый Java». Шестимесячный цикл отделил готовность конкретной возможности от большого редкого релиза. А virtual threads в Project Loom меняют внутреннюю механику потоков, сохраняя знакомые API и последовательную модель thread-per-request. Инженерно это красивая часть истории: заменить фундамент дома так, чтобы людям наверху не пришлось учиться ходить заново. У фильма есть понятная оптика: его поддержали компании Java-экосистемы, а историю в основном рассказывают люди, которые эту платформу создавали. Поэтому я бы смотрел его как коллективную инженерную автобиографию, а не как независимое расследование. Особенно там, где участники оценивают решения Sun, Oracle или влияние отдельных проектов. Для меня главный вывод такой: зрелая платформа - это не только язык, среда выполнения и API. Это ещё бюджет совместимости, правила принятия решений, инструменты, открытый код, выпуск обновлений и возможность сообщества исправить платформу, когда её владельцы ошибаются. Практически это означает, что архитектору платформы мало проектировать расширяемое ядро. Нужны путь миграции, предсказуемый цикл релизов и место для альтернатив. Java выжила не потому, что всегда выбирала правильно. Она выжила потому, что экосистема снова и снова получала возможность скорректировать курс. Связанные разборы документалок в System Design Space: - Spring: The Documentary - IntelliJ IDEA и линия Kotlin - C#, TypeScript и эволюция .NET - Clojure как альтернативная линия JVM А вот они же но просто в виде фильмов, если вы решите почилить и продолжить после истории Java просмотр остросюжетных документалок про Spring, IntelliJ IDEA, Clojure и Apache Tomcat #Software #Java #JVM #Architecture #Engineering #OpenSource #History

Research Insights Made Simple #22: как собрать управляемый агентный стек (Рубрика #AI4SDLC) Что компания делает «своим» в агентной платформе: код клиента, модель, контур исполнения, данные или право агента менять внутренние системы? Эти вещи часто смешивают и сводят выбор к спору между «своим OpenCode» и «чужим Claude Code или Codex». В понедельник 20 июля в 17:00 по мск мы с Мишей Трифоновым из Cloud.ru разберём в прямом эфире эту ложную развилку и соберём полное описание агентного стека в рамках 22-м выпуска подкаста Research Insights Made Simple. Миша Трифонов - Директор департамента внутренней платформы разработки Cloud.ru Рабочая формула шире привычной пары «модель + обвязка»: агентный стек = обвязка + модель + инструменты + идентичность + технические границы исполнения. Обвязка управляет циклом работы и контекстом, модель предлагает план, инструменты создают реальный эффект. Идентичность, sandbox и policy engine определяют, от чьего имени и в каких границах действует агент. Поговорим о восьми конфигурациях: от автономного стека и локальной модели до внешнего планировщика, корпоративного tool gateway и полного SaaS. У каждой схемы своя цена контроля, скорости, lock-in и эксплуатации. Отдельно обсудим несколько неочевидных следствий: - open source ≠ local inference; - self-hosted ≠ безопасные действия; - доступы сотрудника ≠ доступы агента - внутренний MCP ≠ узкие полномочия; - внешний API ≠ внешнее право на действие; - multi-model router = отдельная платформа. Ключевая идея — разделить два пути. Модельный шлюз контролирует, какие данные и к какой модели уходят. Инструментальный шлюз решает, кто, что и от чьего имени может изменить. Между ними нужны единые identity, policy, trace и evals. И здесь разговор переходит к безопасности. Атакуют не абстрактную модель, а путь от недоверенного README, issue или tool result до действия с реальными полномочиями. Поэтому ограничения должна обеспечивать инфраструктура, а не системный промпт. В общем, мы обсудим не «какой агент лучше», а какую минимальную конфигурацию выбрать для пилота, корпоративной платформы или регулируемого контура — и кто отвечает за фактическое изменение системы. Добавляйте стрим в ваш календарь, чтобы не пропустить его. #AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Security #Engineering

Материалы про AI-assisted Engineering (Рубрика #AI4SDLC) Готовы материалы с подкаста Code of Leadership, который был в среду с Алексеем Литвиновым: - Презнтация: Слайд дека с разбором - Видео: Youtube, VK - Аудио: Podster, Ya Music - Текст: Краткая расшифровка #AI4SDLC #Agents #Architecture #Engineering #Software #Books

Через 5 минут стартуем стрим с Алексеем Литвиновым, где будем говорить про свежие бенчи интерактивной работы с агентами: SWE-Together и SWE-INTERACT Подключайтесь к стриму и задавайте вопросы в комментах - мы постараемся интреактивно на них отвечать:)

Мысли про архитектуру (Рубрика #Architecture) Поймал себя на мысли, что в своих пет-проектах я архитектуру улучшаю из идеи, что хочу быстро пилить фичи, но - Не хочу тратить много денег на обслуживание - нужны эффеrтивные CI/CD пайплайны и оптимальная схема для работы в проде - Не хочу тратить много времени на поддержание - приложения должны быть self-healing, а эволюция решения простой в нужную мне сторону - Не хочу тратить много слов на объяснение агентам как пилить новые фичи (на объяснение что пилим тратить время готов) - должны быть заданы понятные архитектурные рамки - Не хочу тратить много сил на ревью и разбираться с регрессионными багами - нужно много детерминированных проверок Вроде бы получается неплохо, но когда я косячу, то сразу вижу, что закончились лимиты или начал быстро уходить бюджет - дальше это прямой триггер, чтобы разобраться где я налажал:) В больших компаниях с такими триггерами и быстрой обратной связью плохо и поэтому к моменту, когда люди решают взяться за решение проблемы у систем уже не просто отдышка, а ожирение 4 степени и жировые бляшки в сердце, которое уже не может нормально прокачивать кровь для всего организма. P.S. Мысли появились после изучения whitepaper про AI для software architecture. #Architecture #Engineering #Software #SystemDesign