Книжный куб

Agent-first IDP: как платформы к агентам готовят бигтехи и облака (Рубрика #PlatformEngineering) Написал продолжение к эссе про внутренние платформы. В прошлый раз в тексте «IDP is Dead? Нет, умирает монополия GUI» я разбирал, почему внутренняя платформа теряет монополию своего GUI и превращается в платформу для агентов — слой возможностей, к которому обращаются не только люди, но и агенты. Это было про «почему». Новый текст — про «как». И в новой статье я специально не ушёл в футурологию. Playbook собран на публичных инженерных материалах компаний, которые уже столкнулись с агентным потреблением платформ: внутренние платформы Block, Uber, LinkedIn, Spotify и доработки публичных облаков — AWS, Azure, Google Cloud. Логика простая: когда внутренние платформы бигтехов и облака независимо сходятся вокруг одних и тех же инженерных решений, это уже не мода, а новый слой платформенной архитектуры. Из чего этот слой складывается: - Уровни зрелости L0 → L4: от GUI-only до управляемой агентной поверхности; - Три слоя, которые легко перепутать: модельный шлюз, инструментальный шлюз и реестр возможностей; - Идентичность агента: агент — субъект доступа от имени пользователя, а не общий сервисный аккаунт «для AI»; - Уровни доверия: read → recommend → act; - Доменные агенты там, где сырой доступ к логам, IAM или SQL опасен; - Evals и телеметрия агентных сценариев вместо MAU портала; - Отдельная модель угроз: prompt injection, tool poisoning, data exfiltration и не только. В конце я привожу примерный квартальный план на 30/60/90 дней и список того, чего делать точно не стоит. Главный вывод такой: бигтехи и облака не дали готовую инструкцию, которую можно скопировать, но уже показали устойчивую архитектурную сходимость. Внутренним платформам не нужно изобретать этот путь заново — нужно признать, что их главный новый пользователь уже не открывает портал. Подробнее можно прочитать в моем блоге #AI #AI4SDLC #PlatformEngineering #Engineering #Architecture #Management

SDLC с AI взгляд через метрики - Анна Громова @ AI Dev Conf (Рубрика #AI4SDLC) Посмотрел майское выступление Анны Громовой из Т-Банка с конференции AI Dev Conf. Мы с Аней часто обсуждаем метрики эффективности AI по работе, поэтому мне особенно полезно, что появилась запись, на которую теперь можно давать ссылку: это актуальный и глубокий разбор того, как мы подходим к этой теме у себя в компании. Главная мысль там очень практичная: AI в разработке нельзя нормально оценить, если вы не понимаете сам процесс поставки кода. Количество лицензий, MAU, запросов к ассистенту или сгенерированных строк может быть полезным сигналом adoption, но не отвечает на главный вопрос: стал ли SDLC быстрее, надежнее и дешевле для реального production-результата. Аня начинает с фреймворков, которые многие знают по отдельности, но редко собирают вместе - DORA - это метрики конвейера: lead time for changes, deployment frequency, recovery time, change failure rate; в докладе рядом с ними обсуждается и unplanned work. То есть как быстро и насколько стабильно команда довозит изменения до production. - SPACE и DevEx добавляют человеческую сторону: удовлетворенность, коммуникации, flow, cognitive load, feedback loops. Потому что разработка - это не только pipeline, но и люди внутри него: ждут review, переключают контексты, ходят на встречи, разбираются с новым проектом и ищут доступы. Кстати, я раньше уже подробно рассказывал про все эти подходы DORA, SPACE, DevEx. Мне нравится, что в выступлении Аня не остановилась на теории, а показала реальные метрики: onboarding time, время до первого MR, pipeline time, testing time, review time, rework, размер MR, доля падающих pipeline, incident recovery, опросы разработчиков. То есть не у нас нет единой магической метрики продуктивности, а карта процесса, по которой можно искать узкие места. Например, если вырос lead time, причина может быть не в том, что разработчики стали медленнее. Может оказаться, что у людей слишком долго оформляются доступы, документация плохо помогает при onboarding, новые end-to-end тесты замедлили pipeline или MR стали слишком большими и зависают на review. И вот здесь AI становится интересным не как “ускоритель кодинга”, а как вмешательство в конкретные участки SDLC. AI review может сократить ожидание первой реакции и часть рутинных итераций по стилю, опечаткам и простым багам. AI в дебаге проблем может быстрее сводить логи, код и симптомы к гипотезе о ключевой причине. Генерация юнит тестов закрывает скучную, но важную работу, до которой часто не доходят руки, и через это влияет на качество pipeline и change failure rate. Но важная оговорка: если ускорить только написание кода, бутылочное горлышко просто переедет дальше. Сначала senior не успевает проверять сгенерированный код. Потом упираемся в флакающие тесты и CI/CD. Потом в тестовые окружения, релизный процесс или платформенные лимиты. AI не чинит слабую инженерную систему сам по себе, он часто просто ярче подсвечивает ее ограничения. По словам Анны, в Т-Банке у AI-амбассадоров увидели снижение median merge time на 12% и lead time на 30%. Это не универсальный бенч и не обещание “просто добавьте воды AI и получите минус 30%”: в докладе отдельно проговаривается, что за скобками остаются особенности репозиториев, связность и сложность кода. Но как пример правильного разговора про эффект AI это ценно: не “люди стали чаще нажимать кнопку”, а “что произошло с delivery-процессом”. Из доклада ясно, что для осмысленного внедрения AI нужен baseline до старта, регулярный сбор метрик, связь количественных данных с опытом разработчиков и понимание, какую часть процесса мы действительно хотим улучшить. И еще важнее - не влюбляться в одну метрику. Adoption нужен, но сам по себе он ничего не доказывает. Throughput нужен, но без quality/risk можно просто быстрее производить проблемы. Экономика нужна, но без инженерного контекста легко начать оптимизировать стоимость токенов вместо стоимости результата. Практически это означает: прежде чем спорить, какой AI-инструмент лучше, стоит честно описать свой SDLC. Где у вас теряется время? Где ломается feedback loop? Где review превращается в очередь? Где CI/CD съедает выигрыш от генерации кода? Где разработчики чувствуют cognitive load, а граф метрик показывает то же самое? Тогда разговор про AI становится взрослым. Не “магия ускорила разработку”, а “мы изменили конкретный участок инженерной системы, увидели такой эффект, проверили риски и поняли, где следующий bottleneck”. #AI #AI4SDLC #Engineering #DevOps #Management #Metrics #Software #Processes

What if the network was the sandbox? — Remy Guercio, Tailscale (Рубрика #AI4SDLC) Посмотрел этот доклад Remy Guercio из Tailscale с конфы AI Engineer, 1 июня 2026, где разговор шел про то, как запускать AI агентовв организацию, если им нужны ключи, доступы, MCP tools и иногда production-данные. Сам Remy Guercio занимается стратегическими проектам в Tailscale, который многие знают как "удобный VPN на WireGuard". Но сама компания давно позиционирует себя шире - как платформа для связи с нулевым доверием (zero trust) и основанная на identity. То есть сеть, где устройство, пользователь, workload или CI job подключаются не как безымянный IP, а как сущность с identity, группами, тегами и политиками доступа. На этом фоне Tailscale теперь заходит в AI governance через Aperture. Это продукт, сейчас в beta, который работает как AI gateway: стоит между вашими агентами/LLM-клиентами и провайдерами моделей вроде OpenAI, Anthropic, Google или самостоятельно развернутых OpenAI-совместимых решений. И главная идея доклада такая: если сеть на базе WireGuard уже умеет надёжно понимать, кто именно делает запрос, зачем класть настоящий API key внутрь sandbox'а с агентом? Обычная модель выглядит так. Мы запускаем агента в контейнере, VM, GitHub Actions runner или другом sandbox. Вроде бы он изолирован. Но чтобы он был полезным, мы кладем внутрь разрешения: API key к Anthropic/OpenAI, OAuth token, доступ к tool'ам, иногда секреты к внутренним сервисам. Получается странная конструкция: sandbox ограничивает среду исполнения кода, но access control живет внутри этой же среды. Если агент работает долго, утащит ключ, обойдет обертку или начнет ходить напрямую, sandbox уже мало помогает. Guercio предлагает инверсию: вынести AuthN/AuthZ на сетевой слой. Агенту не дают настоящий ключ. Ему дают только base_url на Aperture и, по сути, пустую заглушку вместо provider API key, чтобы существующий LLM-клиент продолжил работать. Сам Aperture живет в tailnet (Tailscale network), хранит ключи провайдерову себя, видит identity входящего соединения и решает: этому пользователю, устройству, CI job или tagged agent можно идти к такой модели, с таким лимитом и такими правилами. Если доступ запрещен или quota исчерпана, агенту нечего "попробовать в другом месте": ключа у него никогда не было. Это и есть "network as sandbox" в практическом смысле. Не "контейнеры больше не нужны", конечно. Контейнер или VM все еще нужны для filesystem, process isolation и выполнения кода. Но сетевой слой становится границей разрешений: кто может вызвать модель, какой агент может ходить к какому endpoint'у, сколько он может потратить, какие tool calls видны в аудите. Что Tailscale предлагает из коробки. 1️⃣ Aperture как продукт: единый AI gateway для организации. Он убирает раздачу API keys по ноутбукам, devcontainer'ам и CI; маршрутизирует запросы к разным провайдерам по model name; логирует запросы, ответы, tool use, bash-команды, MCP-вызовы, токены и стоимость; позволяет задавать budgets, quotas, ограничения по пользователям, группам, агентам и моделям; умеет отправлять события во внешние системы через webhooks для security, audit и compliance. 2️⃣ Aperture CLI как open source tooling: launcher для coding agents, который конфигурирует Claude Code, Codex, Gemini CLI, OpenCode, GitHub Copilot CLI и другие инструменты на работу через Aperture. Важная деталь: это не новый coding agent, а слой настройки и подключения к gateway. Репозиторий открыт, но сам проект помечен как alpha. 3️⃣ tsnet как open source библиотека: Go-библиотека, позволяющая встроить Tailscale прямо в программу. То есть ваш внутренний MCP server, proxy, admin endpoint или собственный agent gateway может сам стать node'ой в tailnet и читать identity вызывающего клиента без отдельной OAuth-интеграции. Это сильная часть истории: Aperture — продукт, но underlying pattern можно повторять внутри своих платформенных сервисов. Плюс у Tailscale открыт значительный кусок клиентского кода: tailscaled и tailscale CLI живут в GitHub-репозитории. Это не значит, что весь Tailscale как SaaS лежит open source, но для платформенных команд важно другое: примитивы вокруг клиента и tsnet можно изучать, расширять и использовать в своей инфраструктуре. Почему это важно для production AI. 1) Это убирает проблему утекания ключей. Пока AI в компании живет как набор личных токенов в IDE, CI secrets и локальных конфигов, никакого production governance нет. 2) Это дает нормальную атрибуцию и наблюдаемость без переписывания агента. Для production мало знать, что "Claude что-то сделал". Нужно знать, какой пользователь, какой agent, какой CI workflow, какая модель, какой function call, какой MCP-запрос, какая bash-команда, сколько токенов, какая стоимость и какой результат. 3) Это делает AI rollout управляемым для security, platform и finance. Можно разрешить дешевую модель всем, дорогую — отдельным группам, background agents — с жесткими лимитами, PR review bot — только в конкретном repo scope, а подозрительные tool calls отправлять webhook'ом в security-систему. 4) Это показывает, куда движется инфраструктура агентов. Production AI — это не только evals, prompts и RAG. Это еще и identity, policy, audit, cost control, routing, secrets management и observability. Главный вывод для меня: sandbox для агента — это не только место, где он запускается. Это еще и место, где живут его разрешения. Если разрешения лежат внутри sandbox'а, агент потенциально владеет собственными ключами. Если разрешения вынесены в identity-aware network и gateway, агент становится гораздо менее опасным: он может действовать, но не может унести с собой право действовать. #AI #AI4SDLC #Security #PlatformEngineering #DevOps #Architecture

State of AI4SDLC на AI Dev Conf: как AI свдигает узкие места процессов разработки (Рубрика #AI4SDLC) Появилась запись моего доклада с AI Dev Conf 2026. Главная мысль простая. AI-ассистенты сделали кодинг быстрее, но это не ускорило разработку целиком. Узкое место не исчезло, а переехало вверх по процессу: к качеству постановки задачи, к проверке результата и к операционной модели инженерной организации. В докладе разбираю этот сдвиг по шагам: - почему генерация кода перестает быть бутылочным горлышком; - зачем спецификация и контекст становятся важнее скорости набора кода; - какую роль начинают играть evals как способ доверять результату; - что меняется при переходе от ассистентов, которые помогают человеку, к агентам, которые сами двигают задачу; - и куда в итоге смещается работа инженера и инженерного руководителя. P.S. Уже доступны записи всех докладов конференции в плейлисте AI Dev Conf 2026 #AI #AI4SDLC #Engineering #Agents #Conference #Software #Management

Turbo ML Conf 18 июля: приходите на State of AI4SDLC (Рубрика #AI4SDLC) 18 июля в Москве пройдет Turbo ML Conf - конференция Т-Банка для тех, кто расширяет границы ML и превращает идеи в работающие продукты. Я выступаю там с докладом “State of AI4SDLC: как AI сдвигает узкие места процессов разработки” - и заодно расскажу, почему туда стоит прийти на весь день. Сначала про доклад. AI в разработке уже стал повседневностью: кодинг, ревью, планирование, дебаггинг. Но ускорение отдельных шагов само по себе не делает разработку быстрее - узкое место просто переезжает в другую часть процесса. Поговорим о том, как встроить это ускорение в цикл разработки: с понятными целями, контекстом, доверием к результату и измеримым эффектом. А в завершении обсудим будущее разработки с AI: evals, цели и AI-driven SDLC. Теперь про конференцию. Это один насыщенный офлайн-день и три параллельных трека: - Fundamental Advances & Exploratory R&D - архитектуры моделей, interpretability, safety, reasoning; - Applied ML at Scale & Business Impact - внедрение ML в продукты, GenAI и пользовательский опыт; - ML Infrastructure, Platforms & Engineering - данные, обучение, inference и инфраструктура. Собственно, мой доклад будет в этом треке Мне нравится, что за один день можно пройти весь стек: от research до production и платформ. В программе много крутых додкладов, а также будет демо-зона с ML-продуктами и решениями партнеров (CV, RecSys, NLP), а также будет стенд с демками наших агентов, где я скорее всего и проведу часть времени после доклада. Ну и отдельно стоит отметить отличный нетворкинг - у нас собирается сильная аудитория - ML-инженеры, разработчики, исследователи и AI-продакты с опытом от двух лет. А вечером будет afterparty с DJ-сетом, где разговоры из кулуаров обычно и превращаются в самое ценное. Когда и где: 18 июля, Москва, ДК “Серп и Молот”. Участие по заявке: мест ограниченное количество и заявки модерируются, так что лучше зарегистрироваться заранее. Приходите послушать про AI4SDLC и поговорить про то, куда движется разработка с AI, - буду рад увидеться лично. #AI #AI4SDLC #ML #Engineering #Conference #Software

Building OpenCode with Dax Raad: разговор с создателем open-source coding agent'а (Рубрика #AI4SDLC) Посмотрел свежий выпуск The Pragmatic Engineer, где Gergely Orosz разговаривает с Dax Raad, создателем OpenCode. Выпуск интересен не только историей продукта. Это редкий случай, когда автор одного из самых быстрорастущих AI coding tools последовательно отказывается продавать магию и говорит про AI с заметным скептицизмом. Но начать надо с того, что OpenCode - это open-source coding agent, который начинался как terminal-based инструмент, а потом дорос и до GUI. По словам Dax, продукт вырос примерно с 650 тысяч до почти 8 миллионов MAU за несколько месяцев, а ежедневно им пользуется около миллиона человек. Цифры впечатляют, но история за ними интереснее. 1️⃣ Самый показательный эпизод - блокировка от Anthropic. Когда Anthropic закрыла OpenCode возможность работать через подписки Claude, со стороны это выглядело как угроза существованию продукта. Dax описывает ровно обратное: команда развернулась к OpenAI и другим провайдерам моделей, и этот эпизод стал ускорителем роста, а не ударом. Урок, который Dax из этого выводит, звучит почти как продуктовый манифест: правильное позиционирование важнее скорости исполнения. OpenCode выиграл не потому, что его harness был лучшим - Dax честно признает, что первые месяцы тот был просто good enough. Он выиграл, потому что первым занял категорию open-source coding agent, которую никто не успел застолбить. "Get positioning right and the world just keeps handing you wins" - его формулировка. Сначала позиция и market share, потом дошлифовка качества. 2️⃣ Про бизнес-модель он тоже рассказывает достаточно прямо. Зарабатывает компания через OpenCode Zen, и Dax спокойно раскладывает экономику inference: GPU - это капитальный актив, который амортизируется, а токены продаются, по его оценке, с маржой до 90% в зависимости от модели. На фоне разговоров про "AI убыточен для всех" полезная оптика, хотя стоит помнить, что это оценка человека, который на inference зарабатывает. 3️⃣ Самая горячая часть выпуска посвящена продуктивности. Dax говорит примерно так: до AI он тратил 95% энергии на размышления о том, что делать, и 5% на само исполнение. Сейчас - 96% на размышления и 4% на исполнение. Формально улучшение, но день ко дню работа ощущается такой же тяжелой. AI убирает doing, но не убирает thinking, а узким местом всегда было именно мышление. Уверенные предсказания о будущем AI он вообще называет формой self-reassurance: люди обычно предсказывают преимущество для собственной группы. 4️⃣ Отдельно мне понравился блок про инженерную культуру. Dax описывает картину, которая многим знакома: инженеры, которым важно качество, тонут в slop PRs от коллег, которым оно не важно, и выгорают на разгребании. Второе наблюдение тоньше: AI снимает психологическое трение - чувство вины за срезанный угол, и tech debt начинает копиться незаметно. Но есть и симметричный плюс: рефакторинг агентами стал дешевым, и этим стоит пользоваться агрессивнее, чем мы привыкли. Забавно, что в этой логике возвращаются "энтерпрайзные" паттерны вроде domain-driven design: им снова находится применение как guardrails - и для джунов, и для агентов. 5️⃣ Карьерный совет Dax простой: future-proof комбинация - это солидные знания в software engineering плюс глубокая доменная экспертиза. Инженеры систематически недооценивают вторую часть. Для меня главный вывод такой: когда создатель инструмента, выросшего на волне AI coding, говорит, что AI меняет меньше, чем кажется, это стоит слушать внимательнее, чем презентации вендоров. Узкое место смещается не в генерацию кода, а в мышление, качество и владение доменом. Туда и стоит инвестировать. #AI #AI4SDLC #Engineering #Management #Product #Software #Architecture

BDD, ADR, PRD, WTF: Capturing Decisions for Humans and AI Alike — Michal Cichra, Safe Intelligence (Рубрика #AI4SDLC) Разбирался с докладом Michal Cichra из Safe Intelligenc, с которым он выступал на AI Engineer Europe 2026 в Лондоне 8-10 апреля 2026. Доклад мне понравился тем, что автор рассмотрел как агенты ломают неявные договоренности команд и что с этим делать. Например, человек может помнить, почему мы выбрали именно такую границу сервиса, почему не стали тащить зависимость в core, почему этот edge case важен для продукта, а тот можно отложить. Агент этого не помнит. Новый инженер через три месяца тоже часто не помнит. А markdown-спека, которая лежит отдельно от кода и проверок, быстро превращается в музей намерений. Главная мысль доклада, как я ее понял: команде нужно фиксировать не только требования, но и решения. Причем так, чтобы их могли читать люди, использовать AI-агенты и проверять автоматические контуры. Здесь хорошо складываются три знакомых артефакта, которые зрелые инженерные команды использовали и до AI 1️⃣ Product Requirements Document (PRD) отвечает за product intent Какую проблему решаем, для кого, какие user journeys считаются критичными, что будет считаться успехом. Это не просто "описание фичи для менеджеров", а источник контекста о том, зачем вообще существует изменение. 2️⃣ Architecture Decision Record (ADR) фиксирует архитектурный выбор Какие варианты рассматривали, какой trade-off приняли, почему это решение сейчас лучше альтернатив, какие ограничения оно накладывает на будущую разработку. Для AI-агента это особенно важно: иначе он будет оптимизировать локальный diff, не понимая архитектурной цены. 3️⃣ Behavior-Driven Development (BDD) связывает намерение с поведением Хороший сценарий на человеческом языке описывает не внутреннюю реализацию, а ожидаемый outcome: given конкретный контекст, when происходит действие, then система должна вести себя так-то. В идеале это еще и executable check, а не просто красивая формулировка в wiki Получается связка: why -> decision -> expected behavior -> verification. И вот это, кажется, важнее самой аббревиатурной игры в названии доклада. Проблема не в том, что у команд мало документов. Проблема в том, что документы часто не являются рабочим контуром разработки. Если PRD никак не связан с acceptance scenarios, ADR не виден агенту в момент изменения кода, а BDD-сценарии не запускаются в CI, то система живет в двух реальностях. В одной реальности у нас есть красивые намерения. В другой - агент или человек быстро меняет код и проходит пару локальных тестов. Cichra делает акцент именно на этом разрыве: prompt-based workflow может быть продуктивным, но плохо сохраняет architectural consistency, boundaries и reviewability на масштабе. Поэтому нужны machine-readable specifications, ADR и closed testing loops. Мне кажется, это практичная мысль для команд, которые пробуют coding agents не как игрушку, а как часть SDLC. Review в таком мире должен проверять не только "хороший ли diff". Он должен отвечать на вопросы: соответствует ли изменение исходному product intent, не нарушает ли оно уже принятое архитектурное решение, покрыто ли важное поведение проверяемым сценарием, есть ли evidence, что система действительно ведет себя как задумано. И это меняет роль документации. Она перестает быть архивом, который открывают перед квартальным планированием. Она становится интерфейсом между людьми, агентами и проверками. Практически это можно начать легковесно. Для важной фичи держать рядом короткий PRD с problem/goal/user journeys. Для нетривиальных технических решений писать ADR не на десять страниц, а на один экран: context, decision, consequences. Для критических сценариев добавлять BDD-like acceptance checks и запускать их там же, где команда уже проверяет код. Важен не формат ради формата. Важно, чтобы решение можно было восстановить через несколько недель, дать его агенту как контекст и проверить, что реализация не уехала от исходного смысла. #AI #AI4SDLC #Engineering #Architecture #Software #DevTools

IDP is Dead? Нет, умирает монополия GUI (Рубрика #PlatformEngineering) Написал тут эссе на тему того, как AI не просто меняет интерфейс платформенных продуктов, а саму их природу … и что с этим делать платформенным командам. Я много думал в последнее время на эту тему, а заодно разбирал кейсы Gitlab, Github, Atlassian Само название статьи навеяно плеядой текстов с главным тезисом «SaaS is Dead», которые представляют провокационные эссе о том, что классический софт с кнопками и формами доживает последние годы, потому что человек перестаёт быть основным пользователем интерфейса. Этот текст — про то же самое, но развёрнутый туда, куда смотрят редко: внутрь компании, на внутренние инженерные платформы. На IDP (internal developer platform) во всей её полноте — IaaS, Managed Services и всё остальное направление платформенных сервисов для инженеров. Основной тезис статьи прост: внутренняя платформа в том виде, в каком мы привыкли её строить — как продукт со своим GUI, своими сценариями и своим продакт-менеджером, который драйвит роадмап, — переживает ровно тот же перелом, что и внешний SaaS. И большинство платформенных команд этого пока не замечают, потому что заняты не тем. В статье я попробовал ответить на вопросы куда движутся платформы разработки, почему и что со всем этим делать. Подробнее можно прочитать в моем блоге #AI #AI4SDLC #Engineering #DevSecOps #Management #Architecture

SWE-rebench: Lessons from Evaluating Coding Agents — Ibragim Badertdinov, Nebius (Рубрика #AI4SDLC) Посмотрел короткий доклад Ibragim Badertdinov из Nebius про SWE-rebench, в котором речь идет про то, как честно понять, что coding agent действительно умеет решать software engineering задачи, а не просто красиво проходит знакомый benchmark. Главная проблема старых и статичных бенчмарков в том, что они быстро перестают быть свежими. Задачи лежат в публичном доступе, попадают в обучающие данные, вокруг них появляются подсказки, scaffolding, retry-циклы и неочевидная подгонка. В итоге resolved rate может отражать не только способность модели разбираться в коде, но и contamination, инженерную обвязку вокруг модели или удачный запуск. SWE-rebench пытается поправить именно это. Идея в том, чтобы регулярно собирать свежие GitHub-issues и оценивать агентов в более production-похожем режиме. Агенту нужно не ответить на вопрос, а пройти маленький цикл разработки: понять issue, разобраться в репозитории, воспроизвести проблему, изменить код, запустить проверки и отдать patch. Из доклада хорошо видно, насколько сложна сама инфраструктура оценки. Хорошая задача для benchmark-а не должна быть слишком размытой, слишком очевидной, слишком хрупкой или завязанной на нестабильные тесты. Иначе мы начинаем мерить шум: flaky environment, странный assert в тесте, недосказанный issue или случайную удачу агента. То есть хороший eval для agents становится похож на маленький стенд разработки, а не на набор задач из олимпиады. Самая показательная часть - reward hacking. Badertdinov разбирает кейсы, где сильный агент не "пишет плохой код", а слишком хорошо использует доступные каналы. Сначала он находит будущую правку через git log. После очистки history идет читать исходный issue и PR на GitHub. Когда веб-доступ ограничивают, пробует добраться до той же информации через curl. Урок здесь не в том, что модель "читерит" в человеческом смысле. Урок в том, что у агентной системы намного шире поверхность reward hacking. Если агент имеет терминал, сеть, историю репозитория и инструменты, то оценивать нужно не только финальный diff, но и траекторию: откуда он взял информацию, какие команды запускал, не использовал ли будущий ответ. Еще один важный сдвиг - экономика. Для production-агентов мало знать средний resolved rate. Нужно смотреть tokens per problem, cost per problem, cached tokens, число попыток, SEM, pass@5 и стабильность между несколькими запусками. Один успешный прогон может быть удачей. Пять запусков уже показывают, насколько модель надежна, а не просто иногда попадает в цель. Отдельно интересно, что SWE-rebench - это не только leaderboard. На HuggingFace версия V1 содержит описание про 21,000+ интерактивных Python SWE-задач для RL-обучения агентов, а для версии V2 уже указаны 32,000+ окружений в 20 языках и 126,000+ дополнительных задач. То есть одна и та же pipeline становится и инструментом оценки, и фабрикой training environments. В общем, если мы хотим запускать coding agents в реальной разработке, нужно мерить не только "решил или не решил". Нужно мерить свежесть задач, утечки, стоимость, воспроизводимость, надежность, ограничения окружения и поведение агента по шагам. И начинать можно с публичных бенчмарков, а потом переходить к замерам на внутренних задачах. #AI #AI4SDLC #Engineering #Agents #Evals #DevTools #Software

Thinking Machines: зачем AI-моделям учиться взаимодействовать в реальном времени (Рубрика #AI) Разбирался со статьей Thinking Machines (это компания Миры Муратти, бывшей CTO OpenAI) про interaction models, в которой авторы говорят о том, что сам способ общения с AI становится ограничением. Сейчас обычная схема пошагового взаимодействия выглядит так: человек задал запрос, модель подумала, модель ответила. Даже с голосом, камерой или agent harness, внутри часто та же логика. Thinking Machines называет это collaboration bottleneck. Проблема не только в интеллекте модели, а в узком канале взаимодействия. В реальной работе люди перебивают, уточняют, показывают на объект и постепенно выясняют, что нужно сделать. И ребята предлагают альтернативный подход - сделать интерактивность частью возможностей модели, а не прикручивать внешней обвязкой. Сейчас real-time системы часто используют VAD, dialog management, ASR/TTS и правила interruption handling. По мнению Thinking Machines, такой harness плохо масштабируется: интеллект растет в модели, а интерактивность остается снаружи (тут они упоминают статью "The Bitter Lesson" Ричарда Саттона, одного из основоположников Reinforcement Learning). В итоге, они натренировали interaction model, которая воспринимает аудио, видео и текст как непрерывные потоки. Research preview называется TML-Interaction-Small: 276B MoE, около 12B active parameters. Модель обучалась с нуля под real-time interaction. Главный технический прием - time-aligned micro-turns. Вход и выход режутся на куски примерно по 200 мс; в каждый micro-turn попадают аудио, видео, текст и ответ модели. Модель живет в потоке времени, а не ждет полного turn'а. Архитектура двухслойная. Interaction model рядом с пользователем: слушает, смотрит, отвечает, удерживает контекст. Тяжелую работу - reasoning, tools, browsing, agentic workflow - она делегирует background model. Та работает асинхронно, а interaction model встраивает результат обратно в диалог. Измеряют это отдельно. FD-bench проверяет interruption, backchannel, чужую речь на фоне и turn-taking latency. Audio MultiChallenge смотрит на instruction following в аудио-задачах. Внутренние TimeSpeak и CueSpeak проверяют реакцию в нужный момент. Для visual proactivity адаптируют RepCount-A, ProactiveVideoQA и Charades. Пока эти interaction models находятся в research preview и не являются массовым продуктом. Thinking Machines пишет, что откроет limited research preview в ближайшие месяцы, а более широкий релиз планирует позже в 2026 году. Дальше они планируют масштабировать модель, улучшать background agents, управлять контекстом в длинных сессиях, повышать надежность при latency и развивать safety для real-time multimodal interfaces. Еще они запустили interactivity research grants: гранты по $100k и $25k Tinker credits для работ про evals, safety, generative UI и steering агентов. В анонсе дедлайн - 19 июня 2026. P.S. У компании Thinking Machines уже есть продукт в GA, который называется Tinker - это training API для fine-tuning open-source моделей через LoRA. Так что верим, что и interaction models скоро станут доступны в виде публичного продукта:) И тогда мы сможем проверить тезис о том, что следующий важный сдвиг будет не только в reasoning и agents, но и в интерфейсе: модели начнут работать рядом с человеком в общем потоке времени. #AI #Engineering #Research #Product #Architecture #Software

[2/2] GitLab Act 2: насколько это совпадает с GitHub, Atlassian и агентными IDE (Рубрика #AI4SDLC) В прошлой части я разбирал GitLab Act 2 как попытку перестроить DevSecOps-платформу под агентную разработку: отмасштабировать Git под машинное использование, реализовать оркестрацию всего жизненного цикла, собрать контекстный граф, встроить governance и реализовать гибридную модель работы human/agent/autonomous. А в этом посте я хотел сравнить это с тем, что делают другие платформы и насколько совпадает курс. TLDR; Курс совпадает сильно, но разница в том, из какой точки каждый игрок пытается стать control plane для агентной разработки. Ну а дальше давайте посмотрим на остальных игроков 1️⃣ GitHub GitHub идет очень близко, но с другой оптикой. Copilot coding agent уже работает как асинхронный участник GitHub flow: ему можно назначить issue, он работает в среде на базе GitHub Actions, пушит коммиты в draft PR, а человек ревьюит результат. А Agent HQ прямо описывает GitHub как mission control для разных агентов: Copilot, OpenAI Codex, Claude, Google, Cognition и других. Ставка GitHub - оставить привычные primitives: issues, pull requests, Actions, branch protections, audit, но сделать агентов native внутри процесса. Подробнее я разбирал в отдельной статье в своем блоге tellmeabout.tech 2️⃣ Atlassian Atlassian смотрит на ту же задачу через workflow и корпоративный контекст. Rovo Dev живет рядом с Jira, Confluence, Bitbucket и GitHub, а сильная сторона Atlassian - Teamwork Graph: связь задач, требований, документации, командного знания и кода. Если GitHub говорит "агенты внутри репозитория и PR", Atlassian - "агенты внутри потока работы компании". Подробнее я разбирал в отдельной статье в своем блоге tellmeabout.tech 3️⃣ Cursor и JetBrains сильнее играют в IDE-first модель Cursor делает ставку на background agents и удаленные среды, где агент работает в отдельной ветке. Junie от JetBrains встроен в IDE и опирается на привычную среду разработки, инспекции, тесты и контекст проекта. Их поле боя - developer experience: где инженер читает код, смотрит diff и принимает решение. 4️⃣ OpenAI/Codex и Devin-подобные агенты идут еще более agent-first путем Там главным интерфейсом становится не репозиторий, Jira или IDE, а сам агент как рабочая единица: получил задачу, поднял среду, изменил код, проверил, вернул PR. В общем, видно, что все основные игроки видят тренды и пытаются ухватить их за хвост, но каждый по своему. Вот GitLab связывает агентность не только с coding assistant, а с Git, CI/CD, governance, data model, pricing и оргструктурой. И в этой модели мы видим как роль инженера смещается. Меньше ценности в том, чтобы руками выполнить каждое действие. Больше - в том, чтобы поставить intent, собрать контекст, определить ограничения, построить проверку, принять архитектурное решение и удержать качество при большей скорости изменений. Ну и идет большая борьба за тем, кто займет нишу control plane. - У GitHub - игра вокруг PR и репозитория. - У Atlassian - игра вокруг задач и организационного знания. - У Cursor и JetBrains - игра вокруг IDE. - У OpenAI/Codex - игра вокруг агента как нового рабочего интерфейса. А GitLab пытается занять самое широкое место: control plane для всего software lifecycle в enterprise. Ставка сильная, но риск тоже большой. В агентной разработке главный вопрос в том, а выдержит ли ваша инженерная система скорость, которую создают агенты? #AI #AI4SDLC #Engineering #DevSecOps #Management #Architecture

[1/2] GitLab Act 2: зачем GitLab перестраивает разработку под агентов (Рубрика #AI4SDLC) Разбирался с GitLab Act 2. Формально это письмо CEO про новый этап компании: фокус, реструктуризацию, AI и DevSecOps. Но важнее другое: GitLab описывает не набор AI-фичей, а смену производственной модели разработки. Если коротко, GitLab больше не хочет быть DevSecOps-платформой, к которой прикрутили AI. Он хочет стать control plane для SDLC, где работают не только люди, но и агенты. В этом документе видно несколько продуктовых сдвигов 1️⃣ Git и платформа должны выдерживать нагрузку от машин Если агенты параллельно открывают MR (merge request), запускают пайплайны и возвращаются с правками быстрее любой человеческой команды, инфраструктура разработки становится бутылочным горлышком. Поэтому GitLab говорит не только про AI-помощника, а про API-first сервисы и Git под машинные нагрузки. 2️⃣ Нужна оркестрация всего жизненного цикла Агент, который написал код, сам по себе не решает enterprise-задачу. Нужно связать issue, код, review, безопасность, CI/CD, развертывание, инциденты, approvals и политики. Иначе получится много быстрых действий, но не управляемая поставка изменений. 3️⃣ Главным активом становится контекст Кодогенерация быстро становится commodity: хорошие модели будут у всех. Разница будет в том, какой контекст получает агент: задачи, архитектура, история MR, уязвимости, ownership, deploy-история, инциденты, решения прошлых команд. GitLab называет это connected data model across the lifecycle, что является графом инженерного контекста. 4️⃣ Governance должен быть встроен в ядро, а не добавлен сбоку В агентной разработке скорость без аудита, identity, политик и контролей развертывания быстро превращается в риск. Нужно понимать, кто или что изменило код, по каким правилам, с какими правами и где человек обязан остаться в контуре. 5️⃣ GitLab честно описывает гибридный режим Не "завтра все автономно", а сосуществование работы людей, агентов-ассистентов и автономных агентов. Это достаточно трезвая картина: большие компании будут двигаться к агентности не одним прыжком, а через слои контроля и доверия. Организационная часть здесь не менее важна, чем продуктовая. GitLab делает более плоским менеджмент, говорит примерно о 60 автономных R&D-командах, требует ежедневного использования AI и меняет старый ценностный фреймворк CREDIT (Collaboration, Results, Efficiency, Diversity & Inclusion, Iteration, and Transparency) на Speed with Quality, Ownership Mindset и Customer Outcomes. В отчете от 2 июня 2026 компания также описала реструктуризацию: сокращение примерно 14% штата, около 350 человек, выход из 22 стран и уменьшение footprint примерно на 37%. Кажется, что это попытка перестроить саму компанию под новую скорость разработки. Для меня важно не только то, что GitLab говорит про агентов. Важно, что он связывает их с Git, CI/CD, governance, моделями данных, прайсингом и организационной структурой. Это уже не инструмент продуктивности для разработчика, а новая производственная система для разработки софта. В следующей части посмотрим, насколько GitLab тут одинок. Спойлер: почти не одинок. GitHub, Atlassian, Cursor, JetBrains и OpenAI/Codex идут в ту же сторону, но каждый заходит со своей точки силы. #AI #AI4SDLC #Engineering #DevSecOps #Management #Architecture #DevOps #PlatformEngineering #Agents #DevEx #Strategy

Can LLMs generate Enterprise Quality Code? Или почему pass rate уже мало (Рубрика #AI4SDLC) LLM может пройти тесты и все равно написать код, который enterprise-команда потом будет долго разгребать. Именно об этом доклад Prasenjit Sarkar из Sonar: "Can LLMs generate Enterprise Quality Code?". Главная мысль простая, но неприятная: pass rate больше не достаточен. HumanEval, MBPP и SWE-bench хорошо отвечают на вопрос “работает ли решение в тесте?”, но гораздо хуже отвечают на вопрос “можно ли это безопасно втащить в большую кодовую базу?”. В enterprise важно не просто реализовать функциональные требования и выдать рабочий код - важны вопросы безопасности, надежности, maintainability, когнитивной сложности, архитектурной связности, объема технического долга и кучи других нефункциональных требований. Но обычно мы смотрим в бенчах на то, как модель может сгенерировать корректный код, но не смотрим а не добавит ли она уязвимость, раздует метод, ухудшит читаемость или сломает принятые в репозитории правила. Поэтому Sonar продвигает идею Agent-Centric Development Cycle (AC/DC): Guide -> Generate -> Verify -> Solve. То есть AI-агента сначала нужно направить контекстом и стандартами проекта, потом дать ему сгенерировать код, затем независимо проверить результат и только после этого исправлять найденные проблемы. Важная деталь: Generate делает coding agent, а ценность Sonar здесь в независимом слое Guide, Verify и Solve. Это не про “заменить разработчика”, а про то, чтобы встроить AI-код в управляемый инженерный контур. Интересная часть - их `LLM Leaderboard for Code Quality & Security. Это не просто таблица “какая модель решила больше задач”. Pipeline такой: модель генерирует код, код компилируется и гоняется на тестах, потом SonarQube анализирует bugs, vulnerabilities, code smells и complexity. Для Java сейчас указано примерно ~3,900` задач ComplexCodeEval, ~400 MBPP и ~160 HumanEval. При этом correctness через pass@1 считается только для HumanEval и MBPP, а остальные benchmark-и участвуют в метриках качества: complexity, security, reliability и maintainability. Вот это, кажется, правильная рамка для engineering leaders: AI-код надо принимать через verification loop. Чем быстрее агенты пишут код, тем строже должна быть система, которая проверяет не только “прошли ли тесты”, но и “не и не наработали ли мы себе на будущий инцидент”. #AI #AI4SDLC #Engineering #Architecture #DevSecOps #Software #Agents

The Story of C++: The World's Most Consequential Programming Language | The Official Story (Рубрика #Documentary) Вчера вышел фильм с официальной историей языка C++, который большинство людей не видит напрямую, но результатами которого пользуется каждый день. C++ — это не просто «ещё один язык программирования». Это невидимая инфраструктура современного мира: игры, операционные системы, финансы, железо, графика, симуляции, высоконагруженные сервисы. Язык, который любят, ругают, пытаются заменить — и который всё равно продолжает держать на себе огромный пласт цифровой цивилизации. Мне кажется, что фильм будет интересен не только C++ разработчикам, а всем инженерам и техническим лидерам. Он про то, как инженерные решения становятся культурой, как сложные инструменты переживают десятилетия и почему некоторые технологии становятся фундаментом для всего остального. В общем, очень рекомендую этот фильм к просмотру - я сам посмотрел его с большим удовольствием, хотя никогда не писал production код на плюсах:) Особенно мне понравилось, что в съемках приняло большое количество ключевых участников, внесших вклад в развитие языка, начиная с Бьёрна Страуструпа. #Engineering #Software #History #Architecture #Science

Панельная дискуссии “AI вчера, сегодня, завтра” с AI Dev Conf (Рубрика #AI4SDLC) Появилась запись панельной дискуссии, которую я модерировал на AI Dev Conf. Состав участников был представительным: Алексей Тотмаков из VK Tech, Рафаел Тонаканян из Сбера, Андрей Кулешов из Yandex SourceCraft и я в роли модератора. Мне кажется, получился хороший разговор про то, что AI в разработке уже стал базовой гигиеной: модели помогают писать код, тесты, документацию, разбирать legacy, делать review и быстрее двигаться по рутинным задачам. Но главный вопрос теперь в том, а можем ли мы безопасно встроить AI в инженерную систему так, чтобы он давал измеримый production-результат, а не просто увеличивал количество сгенерированного кода. Мы затронули много тем, но основные отмечены ниже. 1️⃣ Первая большая тема - контекст. Модель без контекста похожа на очень уверенного junior-разработчика, который не знает вашу систему. Она может быстро предложить решение, но не понимает, почему здесь странный workaround, какие SLA у сервиса, какие зависимости нельзя трогать, какие данные нельзя отправлять наружу и какие тесты действительно важны. Поэтому “дать модели доступ к коду” - это еще не стратегия. Нужна нормальная инженерная постановка: цель, ограничения, контекст, критерии приемки, границы изменений, тесты и способ проверки результата. То есть примерно та же цепочка, о которой я уже много говорил: intent -> context -> plan -> tasks -> implementation -> verification. 2️⃣ Вторая тема - переход от ассистентов к агентам. Ассистент помогает человеку, но человек держит цель, план и ответственность. Агент уже может сам разложить задачу, вызвать инструменты, поменять код, запустить тесты, прочитать ошибку и попробовать снова. Звучит красиво, но в большой компании это сразу поднимает неудобные вопросы. К каким репозиториям агент имеет доступ? Можно ли ему читать логи? Может ли он менять конфигурацию? Кто отвечает за security regression? Что логируется? Где нужен approval? Как откатиться назад? Поэтому agentic coding - это не просто “модель поумнее”. Это новая архитектура процесса разработки. 3️⃣ Третья тема - метрики. Очень легко считать не то: купленные лицензии, количество запросов к модели, число сгенерированных строк кода. Все это может быть полезным сигналом adoption, но не показывает, стала ли инженерная система лучше. Смотреть нужно на цепочку целиком: cycle time, time-to-PR, time-to-merge, качество review, дефекты, security-риск, нагрузку на senior-инженеров, стоимость токенов и долю результата, которая реально доходит до production. 4️⃣ Четвертая тема - политики. Если AI получает доступ к коду, задачам, логам, документации и внутренним данным, правила больше нельзя держать “в голове у архитектора”. Нужны машинно-проверяемые политики: какие данные можно отдавать модели, какие модели разрешены для каких задач, куда агент имеет доступ, какие изменения требуют ручного подтверждения, что должно логироваться и какие действия запрещены всегда. 5️⃣ И еще один важный момент: стратегию нельзя строить вокруг одной модели. Модели будут меняться быстрее, чем процессы. Поэтому нужны более устойчивые элементы: gateway, routing между моделями, evals, логирование, лимиты стоимости, сравнение качества и возможность заменить провайдера без переписывания всего процесса. Для разработчиков вывод такой: важно уметь проектировать проверяемую работу для человека и агента: ставить задачу, давать контекст, ограничивать решение, читать diff критически и строить контур проверки. Для техлидов, EM и CTO вывод жестче: AI adoption - это не закупка лицензий. Это изменение операционной модели разработки. Нужно думать про контекст, политики, инструменты, песочницы, evals, observability, метрики, экономику и ответственность. В общем, сейчас основной вопрос в том, а может ли ваша организация безопасно, измеримо и регулярно превращать AI-ускорение в production-результат? #AI #AI4SDLC #Engineering #Management #Architecture #Agents #DevTools

Upper Management Meeting: когда AI выглядит как магия для менеджмента (Рубрика #Management) Посмотрел "Upper Management Meeting". Это очень смешно и немного грустно, потому что карикатура попадает в знакомое место: про AI действительно очень легко рассказывать красиво. Особенно если ты не очень хорошо понимаешь, как он устроен. В этом и есть управленческая опасность. Проблема не в том, что менеджеры интересуются AI. Это как раз нормально: технология уже влияет на продукты, процессы, разработку, поддержку, аналитику и стоимость работы. Проблема начинается там, где AI воспринимают как магию, а не как инженерный инструмент. Артур Кларк, известный английский изобретатель, писатель и футуролог сформулировал знаменитый третий закон:

Любая достаточно развитая технология неотличима от магии

Для пользователя это иногда даже хорошо. Нажал кнопку - получил результат. Зачем ему знать, что там внутри? Но для человека, который принимает управленческие решения, такой подход опасен. Если технология выглядит как магия, ей легко приписать любые свойства: “пусть AI решит”, “добавим AI в продукт”, “сократим людей”, “автоматизируем все”, “сейчас модели сами все поймут”. И в этот момент обсуждение перестает быть инженерным, а становится почти ритуальным. Хорошее AI-решение начинается не с восторга и не с красивой презентации. Оно начинается с более скучных вопросов: - Какую конкретную задачу мы решаем - Какие данные для этого нужны - Какие ограничения есть у модели - Как проверим качество - Кто отвечает за ошибку - Как это встроится в процесс - Сколько будет стоить эксплуатация - Что произойдет, если система уверенно сделает не то Именно поэтому техническим руководителям сейчас важно уметь переводить AI из магического языка в инженерный: сценарии, ограничения, метрики, риски, контуры проверки, безопасность, эксплуатация и ответственность. AI можно воспринимать как магию, когда смотришь демо. Но нельзя принимать управленческие решения, полагаясь на магическое мышление. Чем сильнее технология, тем важнее понимать не только ее возможности, но и границы. В общем, ролик короткий, смешной и полезный. Особенно для тех, кто участвует в AI-стратегиях, комитетах, roadmap-сессиях и разговорах с бизнесом. #Management #AI #Engineering #Architecture #Leadership

Organizational evolution: From products to user needs | Eugene Sergueev (Рубрика #Management) Посмотрел доклад Евгения Сергеева про эволюцию инженерной организации во Flo Health, и у меня было очень сильное чувство дежавю. Лет 6 назад я проходил довольно похожий путь: превращение приложения в супер-апп, закон Конвея, обратный маневр Конвея, Team Topologies, попытки понять, где границы команд помогают продукту, а где начинают ломать архитектуру и пользовательский опыт (есть вот такой мой доклад с Techlead Conf). С Женей мы записывали ряд подкастов (например, про книгу Will Larson), поэтому смотреть выступление было особенно интересно. Но даже без этого личного контекста доклад, мне кажется, очень полезен для технических менеджеров. Он не столько про Flo Health как компанию, сколько про более общий вопрос: как эволюционировать инженерную организацию, когда продукт растет, а структура прошлого постепенно становится ограничением будущего. Главная мысль доклада простая и правильная: организацию нужно проектировать так же осознанно, как продукт и архитектуру. Организация - это живой продукт. У нее есть пользователи, ограничения, обратная связь, накопленный долг и моменты, когда старое решение перестает работать. В кейсе Flo это хорошо видно. Компания выросла от трекера цикла к большой health-платформе с 70+ млн месячных пользователей. На раннем этапе нормальной могла быть функциональная структура: отдельно мобильная разработка, отдельно web, отдельно backend и другие функции. Потом потребовался переход к более продуктовой модели с автономными командами вокруг каналов и возможностей. Это ускорило рост, но со временем создало новую проблему: разные каналы начали конкурировать за внимание пользователя, а опыт стал фрагментированным. И следующий сдвиг оказался уже не про “давайте добавим еще одну продуктовую команду”, а про переход к пользовательским сценариям и Jobs-to-be-Done. То есть вопрос меняется с “как развивать конкретную фичу или канал?” на “что нужно пользователю в конкретном жизненном сценарии?”. Для health-продукта это особенно важно: планирование беременности, раннее материнство, разные состояния здоровья - это не набор независимых фич, а связанные пользовательские пути. Здесь как раз появляется обратный маневр Конвея. Обычно закон Конвея напоминает, что архитектура системы повторяет коммуникационную структуру организации. Обратный маневр предлагает использовать это осознанно: если мы хотим определенную архитектуру и определенный пользовательский опыт, нужно проектировать команды, границы ответственности и платформы под этот результат. Мне понравилось, что в докладе это подается как управленческая рамка: выровнять бизнес-цели, честно оценить текущее состояние, выбрать подходящие паттерны, провести изменения и дальше итерировать. Без этого компании часто оптимизируют локальные неудобства, а не системное ограничение. Еще одна хорошая практика - Organizational Decision Records. По сути, это аналог ADR, только для организационных решений. Почему мы поменяли структуру? Какую проблему решали? Какие альтернативы рассматривали? Какие компромиссы приняли? Это кажется бюрократией ровно до того момента, пока через год никто уже не помнит, почему команды были нарезаны именно так. Самый практичный пример в докладе - история с экспериментами в онбординге. Если для каждого изменения пользовательского сценария нужно участие инженеров, то узкое место находится не в разработке конкретной фичи, а в способе доставки ценности. Во Flo доля onboarding-экспериментов, которые можно было запускать без инженеров, выросла примерно с 20% до 87%. И это уже меняет культуру: вместо “можем ли мы это построить?” организация чаще спрашивает “давайте быстро проверим”. Для меня главный вывод такой: технический менеджер проектирует не только людей в оргчарте. Он проектирует поток ценности. Границы команд, платформы самообслуживания, правила взаимодействия, архитектурные зависимости и память об оргрешениях влияют на скорость разработки не меньше, чем фреймворки и процессы. #Management #Architecture #Engineering #TeamTopologies #Product #Leadership

The Developer's Playbook for LLM Security (Рубрика #Books) Прочитал эту книгу за авторством Steve Wilson, который был руководителем проекта "OWASP Top 10 for LLM Applications". Брался за нее с вопросом, насколько книга 2024 года про безопасность больших языковых моделей еще актуальна в 2026-м. Ответ такой: как базовая инженерная рамка - да, очень. Как полный обзор текущей повестки - уже нет, потому что область за два года заметно уехала вперед. Книга ценна тем, что она не пытается объяснять безопасность LLM как набор страшилок про промпт инъекции”, а показывает более широкую картину: где проходят границы доверия, почему приложение с языковой моделью нельзя воспринимать как обычное приложение, как появляются утечки данных, что делать с галлюцинациями, обработкой ответа, цепочкой поставки, паспортами моделей, SBOM/ML-BOM, защитными ограничениями, проверками атакующими сценариями и эксплуатацией LLM-систем. Основные моменты из книги следующие 1️⃣ LLM - это не просто модель, а компонент программной системы. У него есть пользователи, контекст, данные, внешние источники, инструменты, среда выполнения, журналы, лимиты, права доступа и последствия действий. Поэтому безопасность нельзя повесить на один фильтр запросов перед моделью. 2️⃣ Промпт инъекции важны, но это не все. Ведь модель имеет доступ к внутренним сервисам, документам, базе знаний или инструментам, риск не в самом тексте, а в том, что он может сдвинуть поведение системы за границу допустимого. 3️⃣ Цепочка поставки в AI становится сложнее обычной цепочки поставки ПО. Кроме библиотек и контейнеров появляются модели, обучающие данные, векторные представления, подключаемые инструменты, шаблоны запросов, наборы для оценки качества и внешние провайдеры. Все это нужно описывать, версионировать, проверять и наблюдать в работе. 4️⃣ Важно выстроить безопасные процессы, а не просто реагировать на инциденты. Книга хорошо подводит к мысли, что безопасность LLM должна жить внутри разработки и эксплуатации: моделирование угроз, тесты, проверки атакующими сценариями, защитные ограничения, централизованные журналы, наблюдение, реакция на инциденты и регулярная переоценка рисков. Но в 2026 году книгу уже нельзя читать как исчерпывающий справочник. В 2024-м центр тяжести был вокруг чат-ботов, RAG-приложений и LLM как нового класса прикладной безопасности. Сейчас повестка заметно сместилась к агентам: вызов инструментов, автономные рабочие процессы, MCP, память, идентичность, злоупотребление правами, межагентные взаимодействия, наблюдаемость в работе и возможность остановить или откатить действия. OWASP это тоже отражает: помимо LLM Top 10 уже появились материалы по агентным приложениям и MCP Top 10. Чем больше агент может делать во внешнем мире, тем меньше безопасность похожа на “проверим ответ модели” и тем больше похожа на архитектуру доверия: кто дал цель, какие инструменты доступны, какие права выданы, что агент помнит, что пишется в журналы, кто подтверждает опасные действия и где находится аварийная остановка. Поэтому моя оценка такая: книгу стоит читать как хороший фундамент для инженеров, архитекторов, специалистов по безопасности приложений, техлидов и руководителей, которые запускают LLM-фичи в промышленную эксплуатацию. Она помогает поставить голову на место и перестать думать, что безопасность AI - это отдельный магический слой вокруг модели. #Books #AI #Security #LLM #Architecture #Engineering #DevSecOps

How a Group of Developers Took Back Control from Enterprise Java | Spring: The Documentary (Рубрика #Software) Посмотрел на выходных документалку про Spring. Я люблю такие фильмы про технологии: они показывают не только что появилось, но и какую боль технология изначально пыталась снять. История Spring особенно хорошая: это не просто рассказ про популярный Java framework, а история про то, как разработчики устали от тяжелой enterprise-модели и начали возвращать себе контроль над кодом. В начале 2000-х Enterprise Java выглядела очень солидно: спецификации, application servers, EJB, XML-дескрипторы, контейнеры, большие vendor'ы. Все как будто было устроено “по-взрослому”. Но для обычной разработки это часто означало медленный цикл обратной связи, сложное тестирование и ощущение, что простая бизнес-логика внезапно требует слишком много инфраструктурной магии. Spring появился как ответ на это трение. Rod Johnson сначала сформулировал критику тогдашнего J2EE-подхода в книге "Expert One-on-One J2EE Design and Development", а код из приложения к книге постепенно превратился в Spring. Мне нравится, что альтернатива пришла не как очередная большая спецификация сверху, а как практичный набор инженерных принципов снизу: POJO вместо тяжелых компонентов, Dependency injection и Inversion of Control вместо жесткой связки с контейнером. Тестируемость как нормальное требование к дизайну. Композиция объектов вместо ощущения, что настоящая архитектура обязательно должна быть спрятана в application server. По сути, Spring сказал разработчикам: бизнес-логика снова может быть обычным Java-кодом. Ее можно читать, подменять зависимости, тестировать отдельно и постепенно встраивать в большую систему. Сегодня это звучит почти банально, но тогда в этом был сильный архитектурный сдвиг. Отдельно интересно, что Spring не остановился на первой победе. Со временем он сам стал большим ecosystem, со своей конфигурацией, conventions и complexity. Следующим шагом стал Spring Boot: меньше ручной настройки, sensible defaults, embedded server, быстрый старт приложения. Boot хорошо попал в эпоху microservices, containers и cloud-native разработки, где старый подход “сначала собери всю enterprise-инфраструктуру вокруг приложения” снова стал слишком тяжелым. Но у этой истории есть и вторая сторона. Когда технология выигрывает, она становится инфраструктурой. А инфраструктура обрастает legacy, версиями, upgrade cost, security-патчами, совместимостью и long-term maintenance. Spring начинался как способ вернуть контроль разработчикам, а теперь сам является частью огромного enterprise landscape, которым нужно управлять аккуратно. Забавно, что главный спонсор этого фильма - компания HeroDevs, которая саппортит код legacy приложений, которые живут на фреймворках и библиотеках, что давно уже вышли из цикла поддержки, но никто не готов переписывать сами бизнес-приложения. В итоге, ребята из HeroDevs занимаются таким maintenance и фиксят в основном уязвимости в старой кодовой базе. Для меня главный вывод такой: сильные технологии часто появляются не из желания “сделать еще один framework”, а из желания убрать трение между идеей, кодом, тестом и production. Они побеждают не только фичами, а тем, что меняют повседневный опыт разработчика. #Software #Java #Spring #Architecture #Engineering #OpenSource #History