Книжный куб

Материалы с третьей части AMA сессии с Лешей Литвиновым (Рубрика #AI4SDLC) Мы успешно разобрали последние 6 вопросов и закончили свой марафон - Страничка выпуска - Видео: YouTube, VK Video - Аудио: Podster, Яндекс Музыка - Текст: Краткая расшифровка P.S. У Леши есть свой канал в tg @tip_podcast и на Youtube #AI #Management #Processes #Engineering #Software #Architecture

UK Global Talent — endorsement получен (Рубрика #Changes) Где-то к концу 2025 года я понял, что хочу заниматься технологиями, которые находятся близко к фронтиру. Весь 2025 год в Т-Банке я занимался AI4SDLC, но мне было ясно, что чего-то не хватает. И к началу лета 2026 года я пришёл к тому, что хочу попробовать получить визу Global Talent в UK. Читатели помнят, что в этом году я уже пару раз ездил в Лондон: сначала только с женой, а потом с женой и детьми. Город меня вполне устроил с точки зрения места для жизни. Дальше я занялся бюрократией и решил разобраться с процессом. Требования оказались вполне подъёмными: - Надо заполнить онлайн-заявку, включая personal statement — аналог мотивационного письма; - Приложить три рекомендательных письма от уважаемых в индустрии людей, которые знают твою работу не менее 12 месяцев и могут на конкретных примерах рассказать о твоих качествах и достижениях; - Приложить evidence documents — максимум 10. Минимум два документа должны показывать, что тебя признают ведущим или потенциально ведущим специалистом, и ещё минимум четыре должны закрывать два дополнительных критерия — по два документа на каждый. То есть минимально получается шесть evidence-документов. А вообще, у Global Talent есть разные направления. Я шёл по Digital Technology route, внутри которого есть варианты Exceptional Talent и Exceptional Promise. Я подавался как Exceptional Talent. К процессу я подошёл как менеджер и использовал working backwards: сначала нарисовал себе целевую картинку, а дальше начал отстраивать от неё шаги в обратную сторону. - Написал personal statement. - Подобрал уважаемых в индустрии людей, которые хорошо знали мою работу и могли подтвердить факты обо мне, укладывающиеся в общую историю заявки. - Дальше нужны были evidence documents. Тут я решил собрать все свои достижения за разные годы на сайте polomodov.tech. - Я долго работал над тем, чтобы свести туда презентации, подкасты, номинации на премии и другие материалы. Там же начал публиковать лонгриды. - Когда вся фактура была собрана, я вместе с Claude и Codex разложил её по критериям и собрал примерный пакет документов, который лучше всего поддерживал мою заявку. Все факты и финальный выбор evidence, конечно, были моими. - Дальше было большое количество доработок напильником. - Потом — поход в бюро переводов, чтобы перевести часть evidence documents. - Сначала я приложил оригиналы и переводы раздельно к письму, которое нужно было отправить в Home Office. - Примерно через неделю мне ответили, что в моём пакете каждый перевод нужно объединить с соответствующим оригиналом в один файл — иначе получалось слишком много документов и превышался лимит. - Я всё поправил и отправил исправленный пакет, а ещё через 11 дней получил положительное решение по endorsement и это произошло сегодня утром. Это, понятно, только таймлайн моего кейса, а не официальный ориентир. В письме была такая формулировка: Tech Nation has advised that you meet its criteria for Exceptional Talent and I am therefore satisfied that you can be endorsed under Global Talent. Теперь остался второй этап: в течение трёх месяцев подать отдельную заявку на саму визу и получить решение уже по ней. А дальше — планировать переезд. В общем, процесс не выглядел сложным, но это мой личный опыт, а не иммиграционная консультация, а требования меняются во времени, поэтому актуальные требования лучше всегда проверять на GOV.UK. #Software #Engineering #RnD #Live #Leadership

Claude Certified Architect: экзамен как карта агентной инженерии (Рубрика #AI4SDLC) Посмотрел 20-минутный доклад Фрэнка Койла с AI Engineer World's Fair 2026 про экзамен Claude Certified Architect - Foundations. Его полезнее читать не как сертификат, а как карту решений, без которых агентная демка не становится производственной системой. Кстати, раньше я уже рассказывал про доклад Фрэнка про онтологии на этой же конфе. CCAR-F - первая техническая сертификация Anthropic для архитекторов приложений с Claude. Это 60 заданий с одним или несколькими ответами на 120 минут; проходной scaled score - 720 из 1000. Четыре из шести сценариев выбираются случайно: поддержка, генерация кода, многоагентное исследование, инструменты для разработчиков, Claude Code в CI/CD и структурированное извлечение. Проверяется не меню продукта, а выбор архитектуры с учётом ограничений и отказов. Темы экзамена хорошо показывают его приоритеты: - Агентная архитектура и оркестрация - 27%: циклы, stop_reason, субагенты и hooks; - Инструменты и MCP - 18%: схемы, ошибки и распределение инструментов; - Claude Code - 20%: CLAUDE.md, skills, plan mode и CI/CD; - Промпты и структурированный вывод - 20%: few-shot, JSON Schema и валидация; - Контекст и надёжность - 15%: сжатие, происхождение данных, эскалация и проверка человеком. Койл разбирает карту этого экзамена через антипаттерны. Не принимать ответ модели за действие: LLM формирует вызов инструмента, а код проверяет stop_reason, исполняет его и возвращает результат в цикл. Не давать одному агенту все инструменты, если хватит узкого подагента. Не вываливать его полную историю в основной контекст: возвращать вывод, факты и ссылки, а длинную сессию сжимать. Достаточно много Койл говорит про loop engineering, который мы вместе с Максом Смирновым разбирали в выпуске Research Insights Made Simple #19. Там мы говорили про повторяемый цикл и право проверяющего его остановить. CCA добавляет карту компетенций инженера вокруг цикла: инструменты, контекст, границы, проверку и восстановление. Итого: польза этого экзамена не в бейдже, а в схеме подготовки, которую можно взять как учебный план и чек-лист архитектурного ревью: где остановка, кто исполняет вызов инструмента, что видит подагент, сохраняется ли источник и когда решение уходит человеку. Карта привязана к Claude, а сданный тест не доказывает опыт промышленной эксплуатации. Условия из доклада уже устарели: на 12 августа 2026 года экзамен подорожал до $125, но его вопросы полезны и тем, кто сдавать не планирует. #AI #AI4SDLC #Agents #Architecture #Engineering #DevTools

Harness: почему один агент с файлами вытесняет сложные обвязки (Рубрика #AI4SDLC) Посмотрел доклад Константина Крестникова (CTO GigaChain, Сбер) «Harness: новый подход к созданию AI-агентов» с Data Fest 2026. Это компактная история о том, как индустрия за четыре года прошла путь от чат-бота до универсального агента, и почему сложные мультиагентные обвязки начали проигрывать «одному агенту с файлами». Эволюция по докладу выглядит так: - Конец 2022: чистые LLM и ранний ChatGPT — текст на входе, текст на выходе, без памяти и инструментов; - 2023: ReAct-агенты — модель в цикле сама решает, вызвать инструмент или ответить, и рефлексирует результаты вызовов; - Рубеж 2023–2024: агентов заворачивают в цепочки с пре- и постобработкой и structured output — время LangChain и LlamaIndex; - Дальше (2024-2025) цепочки ветвятся в графы и мультиагентные системы: агент-планировщик, агент-критик, LangGraph, AutoGPT, CrewAI. Всё это scaffolding — «строительные леса» вокруг модели; - Сейчас (с 2025): harness — один универсальный агент уровня Claude Code или Codex, работающий в пространстве файлов. Метафора в названии точная: LLM — тяговая сила, файлы — поле, harness — упряжка. Ключевой сдвиг: мощным моделям сложная обвязка перестала быть нужна — достаточно положить агенту правильные файлы и инструкцию в AGENTS.md. Внутри любого харнеса всё тот же ReAct-цикл, а базовых инструментов четыре: чтение файла, поиск по файлам, редактирование и bash (всего из коробки 25–30). При этом, по наблюдению команды, при одной и той же модели харнес даёт разброс в 20–30 п.п. качества. Практическая часть — как команда GigaChain выбирала харнес для GigaChat: - Взяли open-source DeepAgents от LangChain: GigaChat подключился правкой конфига благодаря адаптеру langchain-gigachat; - Замерились на соревновании из канала «LLM под капотом»: Claude Code с Sonnet решает 70 задач из 104, DeepAgents с той же моделью — 67. Просадка небольшая, при том что Anthropic оптимизирует харнес и модель друг под друга; - Использовали киллер-фичу DeepAgents — профили моделей: вендор выпускает Python-пакет, учитывающий сильные и слабые стороны своей модели. Такой профиль сделали для GigaChat; - Собрали свой бенчмарк harness-bench-fast: задачи на файлы, память, grep и разбор CSV с golden-ответами без LLM-judge, прогон около 20 минут на любом харнесе; выложен в open source; - Запустили автоулучшение по циклу «гипотеза → замер → оставить или откатить» (около 15 гипотез, часть предложил Claude): по словам докладчика, это дало +22,5 п.п. на своём бенчмарке чистым промптингом, а на внешнем соревновании — рост качества на 41%. Самая любопытная часть — про то, что дальше. Контекст любого харнеса заканчивается, а суммаризация резко «оглупляет» агента. Ответ — Ralph loop Джеффри Хантли: харнес запускают в бесконечном bash-цикле, состояние живёт в файлах, и каждый перезапуск возвращает модель в «умную зону» первых 30–40% контекста. Против вырождения (Карпаты показывает его на анекдотах: попросите у модели двадцать анекдотов — панчлайна будет три) Крестников добавил MetaLoop — внешний цикл, который стартует Ralph loop с чистого листа новым «поколением»; оно позже находит наработки предыдущего, но идёт своим путём. Из этого вырос Anima SDK: в первом эксперименте агент с задачей «стань разумным существом» проработал 13 поколений за пять дней, однажды попробовал замолчать — вывел несколько точек и записал, что молчать агент не может. Практичнее применять то же самое к исследованиям, переводам больших книг и автоулучшению агентов — задачам, где оптимальный путь заранее неизвестен. Итого, из этого короткого доклада видно, что центр тяжести инженерии агентов сместился из кода обвязки в среду — файлы, инструкции, тесты и бенчмарки, удерживающие агента (Хантли называет это backpressure). А выбор харнеса стал отдельным инженерным решением, которое стоит замерять на своих задачах, а не принимать по умолчанию. #AI #AI4SDLC #Agents #Evals #DevTools #Engineering

Материалы с подкаста "PRD == evals: как AI стирает границу между продактом и ML Engineer" с Альбиной Мунировой из Т-Банка (Рубрика #ProductManagement) Мы поговорили про изменения в профессии продакт менеджеров, когда граница между ним и ML-инженером становится заметно тоньше. - Страничка выпуска - Видео: YouTube, VK Video - Аудио: Podster, Яндекс Музыка - Текст: Краткая расшифровка P.S. У Альбины есть свой канал в tg @aimunirova и на Youtube #AI #Management #Processes #Engineering #Software #Architecture #ML

vLLM и PagedAttention: как идеи из ОС ускорили LLM-инференс (Рубрика #AI) Разобрал наконец целиком статью «Efficient Memory Management for Large Language Model Serving with PagedAttention» (Symposium on Operating Systems Principles (SOSP) 2023) — ту самую, из которой вырос vLLM, один из самых популярных open-source движков LLM-инференса. Я уже упоминал её в обзоре Таненбаума, а теперь хочу разобрать саму инженерную идею. Она красивая: авторы ускорили инференс в разы, не меняя модель и почти не трогая вычисления — они починили управление памятью. Контекст такой. Пропускная способность LLM-сервинга упирается в батчинг: GPU работает эффективно, когда генерирует токены сразу для многих запросов. А размер батча ограничен памятью под KV cache — ключи и значения attention для всех уже обработанных токенов каждого запроса. В конфигурации из статьи — OPT-13B с весами в FP16 на A100 с 40 ГБ — веса занимают около 65% памяти, KV cache — ещё около 30%. Именно кэш в этом раскладе определяет, сколько запросов поместится в батч. Команда из Berkeley (среди авторов — Woosuk Kwon, Zhuohan Li и Ion Stoica) показала, что системы того времени — FasterTransformer, Orca — обращались с этой памятью расточительно. KV cache запроса хранился одним непрерывным куском, который резервировался сразу под максимальную длину, например 2048 токенов, даже если ответ занимал пятьдесят. Потери складывались из трёх частей: 1) слоты, зарезервированные «на будущее» 2) внутренняя фрагментация кусков, выделенных с запасом 3) внешняя фрагментация аллокатора По замерам авторов, полезные данные занимали лишь 20–38% памяти KV cache — остальное пропадало. Решение — PagedAttention: виртуальная память и страничная организация из операционных систем, перенесённые в инференс. KV cache режется на блоки фиксированного размера (по умолчанию 16 токенов) — аналог страниц. Логически последовательность непрерывна, физически её блоки лежат где угодно, а соответствие хранит таблица блоков — аналог page table. Память выделяется по мере генерации, недозаполненным остаётся лишь последний блок: в экспериментах авторов утилизация KV cache выросла почти до 96%. Дальше включается второй классический механизм — разделяемые страницы и copy-on-write, как при fork процесса. При parallel sampling несколько вариантов ответа ссылаются на одни физические блоки промпта; в beam search гипотезы делят общие префиксы, а при расхождении копируется один блок, а не весь кэш. Авторы сообщают об экономии 6–10% памяти для parallel sampling и 37–55% для beam search. Поверх алгоритма построен сам движок vLLM: continuous batching (итерационное планирование из Orca), менеджер блоков, вытеснение целых последовательностей при нехватке памяти — со swap в память CPU или пересчётом — и собственные CUDA-ядра для работы с разбросанными блоками. Честная деталь: ядро attention стало на 20–26% медленнее из-за доступа через таблицу блоков. Но система в целом даёт в 2–4 раза больший throughput, чем FasterTransformer и Orca, при той же задержке, потому что в память влезает кратно больше параллельных запросов. Выигрыш растёт с длиной последовательностей и размером модели. Дальнейшее известно: летом 2023-го vLLM вышел в open source, и идею быстро переняли конкуренты — paged KV cache описан в документации TensorRT-LLM, а Hugging Face TGI прямо использует CUDA-ядра vLLM. По-моему, подход по факту стал отраслевой нормой. Для меня главный вывод двойной. 1️⃣ Узкое место LLM-инференса оказалось не в FLOPs, а в управлении памятью, и лечится оно приёмами из учебника по ОС, которым больше полувека. 2️⃣ Авторы сознательно проиграли в локальной метрике (скорость ядра), чтобы выиграть в системной (throughput при заданной задержке). Умение выбрать уровень, на котором оптимизируешь, — признак зрелой системной инженерии. #AI #Research #Software #Architecture #Engineering #RnD

Челси Финн: GPT-эра робототехники на пороге (Рубрика #Robotics) Посмотрел выступление Челси Финн «This Is the State of the Art in Robotics» на Startup School 2026, опубликованное 12 августа 2026 года. За эффектными демо Финн предлагает увидеть более важный сдвиг: ChatGPT стал общей моделью для работы с текстом, а Physical AI пытается сделать то же для действий в реальном мире. Параллель здесь архитектурная. Вместо отдельного конвейера под каждую задачу — одна предобученная основа, которой дают разные инструкции. Physical Intelligence переносит этот принцип в робототехнику: от политики под одну операцию и одного робота к общей vision-language-action модели (VLA). На входе у неё изображения, инструкция и контекст, на выходе — управляющие действия. Правда, робот сходу должен работать без human in the loop — он сам меняет среду, а у пролитого кофе или столкновения нет кнопки undo. Поэтому Physical AI становится полезным не после удачного демо, а когда система часами работает без постоянного присмотра и восстанавливается после ошибок. Финн показывает три части такого контура. 1️⃣ Разнородные данные У LLM есть огромный корпус текстов, но готового «интернета физических действий» нет. Вместо этого используются демонстрации операторов, автономные попытки, видео людей, данные из интернета и траектории разных роботов. Видео помогает понять задачу, а моторный навык приходится нарабатывать на самой машине. 2️⃣ Обучение с подкреплением на собственном опыте Когда робот оказывается в тупике, то оператор показывает роботу способ восстановления, а модель ценности (value function) оценивает движение к успеху, затем VLA дообучается на этих попытках. По данным Physical Intelligence, RECAP более чем вдвое повысил пропускную способность на части сложных задач и примерно вдвое сократил отказы. Для эспрессо компания сообщает об успехе выше 90% и 13-часовом прогоне повторяющегося сценария. Это результаты команды, а не независимая проверка. 3️⃣ Память Для уборки кухни мало текущих показаний сенсоров: нужно помнить завершённые шаги. В системе MEM (Multi-Scale Embodied Memory) короткая история остаётся видео, а длинная сжимается в текст. Получается любопытная инверсия: язык внутри робота служит планом и памятью, а моторный навык рождается из физического опыта. Новая π0.7 объединяет инструкцию, ближайшую подзадачу, сведения о качестве данных и визуальную подцель от модели мира. По утверждению компании, единая VLA-модель сравнялась со специализированными политиками и показала ранние признаки композиционного обобщения — переноса знакомых навыков на новые сочетания задач и роботов. Универсальный робот из этого пока не получился. Финн делает важную оговорку: буквального «момента ChatGPT» может не быть. Софт распространяется мгновенно, а машины нужно произвести, установить и обслуживать. GPT-эра робототехники будет похожа не на миллион пользователей за пять дней, а на постепенный рост числа задач, которые одна модель выполняет надёжно и автономно. Для меня главный вывод такой: «ChatGPT для физического мира» близится и общими будут модель, инструкция и перенос знаний между задачами. Также Physical AI нужны собственный опыт, память, проверки качества, безопасное восстановление и измеримая надёжность. ChatGPT научил модели работать со смыслами текстов, а робототехнике ещё предстоит доказать, что смыслы можно стабильно превращать в действия в реальном мире. #Robotics #AI #Engineering #Research #Architecture

Cursor Cloud Agents: что отдать агенту, а что оставить платформе (Рубрика #AI4SDLC) Прочитал июньский разбор Джоша Ма из Cursor о годе работы над облачными агентами. Зацепил не рост автономности, а смена архитектурной границы: процедурная логика переезжает из обвязки агента (harness) в управляемые им инструменты. Сложность не исчезает, а нарастает вокруг среды, надёжности, политик и состояния. И облачный агент здесь — уже не цикл в одной VM, а система из рабочего процесса, среды, журнала событий, инструментов и подагентов. 1️⃣ Первый сдвиг — среда стала частью качества агента. Локально он наследует репозитории, зависимости, сборку, тесты, настройки и доступы с ноутбука разработчика. В облаке всё это нужно восстановить явно. По наблюдениям Cursor, неполная среда может не падать с ошибкой: агент просто работает хуже, а деградацию списывают на модель. Я бы развёл две роли. Песочница (sandbox) ограничивает действия, а рабочая среда агента (development environment) содержит всё нужное для цикла «изменил → запустил → проверил». Изолированная VM без зависимостей, тестов, API и управляемой сети может быть безопасной, но бесполезной. Поэтому Cursor строит возобновляемое рабочее место: VM можно усыплять и возобновлять, образы — сохранять, восстанавливать и разветвлять, а сеть и учётные данные контролировать отдельно. В соседнем материале компания описывает среду как код: Dockerfile, историю версий и откат, аудит, правила исходящего доступа и работы с секретами. Это уже платформенная инженерия для агентов. 2️⃣ Второй сдвиг — harness перестаёт диктовать маршрут. Раньше он перепроверял результат, принудительно делал commit и push, а в CI Autofix ещё и забирал логи. Теперь агент получает GitHub CLI, инструменты для веток и PR, карту репозиториев и доступные для поиска файлы с большими выводами — и сам выбирает процедуру 🤖. Детерминированный слой остаётся. Я бы провёл границу так: агент выбирает инструменты, их порядок и момент проверки; платформа удерживает границы прав и сети, выдачу секретов, восстановление, аудит и защиту от дублей при повторе внешних действий. Обвязка перестаёт быть сценаристом: она даёт возможности, а гарантии распределяются между оркестрацией исполнения и управлением средой. 3️⃣ Третий сдвиг — «один агент» декомпозируется по времени жизни и владельцу состояния. Agent loop живёт в Temporal, жизненный цикл VM управляется отдельно, а хранение и поток разговора вынесены в свой слой. При повторе шага клиент перематывает отображаемый поток; асинхронный подагент может работать на другом pod и пережить родителя. Сам рабочий процесс тоже разрезали: вместо «вечного» — несколько коротких, каждый завершается одной задачей; отдельные операции получают свои тайм-ауты и повторные попытки. Для работы с интерфейсом (computer use) у Cursor пока остаётся отдельный подагент со своей маршрутизацией моделей, инструкциями и записью экрана. VNC и Chrome находятся в общей среде, а родитель решает, когда его подключить. Зрелую способность можно отдать агенту как инструмент, слабую пока удерживает дополнительная обвязка. Практически для платформенной команды отсюда следуют три решения: 1) Версионировать описание среды: образ, зависимости, проверки готовности, сетевые правила и правила выдачи секретов; сами секреты хранить и ротировать отдельно; 2) Выдавать возможности через инструменты, но держать безопасность, надёжность и аудит вне вероятностного плана модели; 3) Разделять цикл агента, машину, разговор и подагентов по владельцу состояния, времени жизни, лимиту времени и правилам повторного запуска. Для меня главный вывод такой: перенос логики из harness в сторону модели — не упрощение, а смена контракта. Границу нужно двигать отдельно для каждой способности и только после проверок качества (evals). Чем умнее агент, тем меньше платформа диктует ему шаги — и тем лучше управляет средой, границами и последствиями. #AI #AI4SDLC #Agents #Architecture #PlatformEngineering #Engineering

3 AImigo S1E1: где мы сейчас с AI в разработке (Рубрика #AI4SDLC) Стартует прямой эфир первого выпуска подкаста 3 AImigo. И начнём мы свой новый подкаст с точки отсчёта: где сегодня находится AI-разработка, что уже стало рабочей нормой, а что пока живёт в сильных экспериментах и красивых демонстрациях. Обсуждать будем втроём: Евгений Сергеев, Алексей Литвинов и я. У нас разная оптика: управление большой инженерной организацией, практическое внедрение AI-Assisted Engineering и архитектура AI4SDLC. Не будем искать одну «правильную» картину - сравним наши взгляды. Приходите и задавайте свои вопросы. #AI #AI4SDLC #Agents #Engineering #Architecture #Management

turbopuffer: как построить поисковую базу поверх S3 (Рубрика #Architecture) Посмотрел разговор Gergely Orosz с Simon Eskildsen, сооснователем и CEO turbopuffer. Формально выпуск про инфраструктуру поиска для AI-продуктов, но для меня он прежде всего про старую инженерную дисциплину: сначала посчитать физику и экономику системы, а уже потом верить бенчмаркам. До turbopuffer Simon восемь лет занимался инфраструктурой Shopify. Там он собрал Napkin Math - таблицу с пропускной способностью DRAM и NVMe, задержками S3 и стоимостью разных видов хранения. Если расчёт говорит «10 мс», а тест показывает 10 секунд, нужно не выбирать соседнюю базу, а понять, где потерялись три порядка: в плане запроса, сети, распределении работы по узлам или самом эксперименте. turbopuffer вырос именно из такого несоответствия. Делая рекомендации для Readwise, Simon оценил, что хранение и поиск по векторам обойдутся примерно в $30 тысяч в месяц — при $5 тысячах на всю остальную инфраструктуру компании. По его словам, экономика продукта не сходилась, и функцию не запустили. Тогда он задал более полезный вопрос: обязательно ли постоянно держать все векторы в дорогой памяти и на реплицированных SSD? Ответом стала база, где все постоянные данные лежат в объектном хранилище (object storage), а вычислительные узлы не держат собственного состояния. Упрощённо векторы собираются в кластеры, отдельно хранится индекс центроидов, а запрос загружает только ближайшие кластеры. Горячие данные попадают в память, тёплые - в NVMe-кэш, холодные читаются из S3. Это не бесплатный трюк: запись может занимать до 200 мс, а холодные запросы иногда уходят в сотни миллисекунд. Но для поиска обычно важнее высокая пропускная способность, надёжность и цена хранения, чем транзакционная задержка каждой записи. turbopuffer сознательно платит более медленными записями и редкими холодными запросами за дешёвое хранение основной массы данных. Особенно хороша история первого клиента. По словам Simon, им стал Cursor, пришедший после запуска MVP в Twitter. Simon прилетел в Сан-Франциско и начал не с продажи, а с разбора чужой проблемы Postgres: autovacuum не успевал, и база читала таблицу вместо нужного index scan. Эта помощь создала доверие; затем Cursor перенёс нагрузку на turbopuffer за одну-две недели. По данным компании, первый счёт оказался на 95% ниже последнего счёта предыдущего поставщика. Это не независимый бенчмарк, но продуктовый урок сильный: критическую инфраструктуру покупают не по красивой диаграмме, а у команды, которая понимает весь контур отказов и стоимости. Для меня главный вывод: мышление от первых принципов не заменяет измерения - оно делает их осмысленными. Сначала прикидываем пределы железа и стоимость нагрузки, затем строим простейшую систему с нужными инвариантами и только после этого оптимизируем реальную работу. turbopuffer интересен не потому, что «S3 победил базы данных», а потому, что команда отказалась платить за свойства, которые её поиску не нужны. #Software #Data #Architecture #Infrastructure #Engineering #AI

Приходите на последнюю часть AMA сессии с Лешей Литвиновым про AI-assisted engineering

Адам Уорд: найм больше не воронка (Рубрика #Management) Посмотрел вчера выпуск Lenny’s Podcast от 9 августа 2026 года с Адамом Уордом, Head of Talent в Cursor. Формально разговор про команды с высокой концентрацией сильных специалистов, но я считал тут другую идею о том, что рынок найма раскололся, а привычная воронка всё хуже отличает компетентность от простой доступности кандидата. Уорд называет происходящее «двумя городами» 1) За небольшую группу AI-исследователей и специалистов новых профилей компании конкурируют предельно жёстко 2) А многие другие люди месяцами не могут найти работу Похожие перестройки случались при переходе индустрии к mobile first или mobile native, но теперь, по его наблюдению, изменения укладываются не в годы, а в недели. Меняется и профиль востребованного специалиста. По оценке Уорда, растёт спрос на FDE - инженера, который глубоко понимает технологию, умеет говорить с руководителями и доводит продукт до работающего решения у клиента. Одновременно сложнее становится очень узким специалистам и начинающим без накопленного контекста. Выше ценятся не только техническая глубина, но и вкус, качество решений, любопытство, продуктовое мышление и способность работать на границе функций. Самая сильная часть выпуска - критика классической воронки, которую Уорд называет funnel of doom. Компания пишет ста людям, двадцать отвечают, дальше на каждом этапе кого-то отсеивают и нанимают оставшегося. Но ответившие двадцать - не обязательно лучшие двадцать. Это просто те, кто оказался доступен именно сейчас. Вместо этого он предлагает относиться к каждому важному найму как к поиску руководителя: - Сначала точно описать не должность, а необходимые навыки, опыт и результат через год; - Затем составить карту рынка и искать людей по конкретным признакам, а не по громкому работодателю в резюме; - После этого последовательно строить отношения с небольшим числом подходящих кандидатов - иногда неделями или месяцами. Меняется и оценка. Cursor использует рабочие пробы: кандидат решает задачу рядом с будущей командой. По словам Уорда, компания пыталась отказаться от этого дорогого этапа, но потеряла уверенность в качестве сигнала и вернула его. Ценность здесь двусторонняя: работодатель видит не только ответ, но и мышление, взаимодействие и принятие решений; кандидат получает данные о реальной команде, а не только презентацию вакансии. Мне особенно понравилась оговорка про talent density. Это не коллекция «десятикратных» героев. Даже сильный человек не даст десятикратного результата в плохой команде. Концентрация сильных специалистов - свойство системы: насколько люди дополняют друг друга и помогает ли среда превращать индивидуальную силу в общий результат. Есть в разговоре и важное ограничение. Cursor нанимает редкие профили на перегретом AI-рынке. Переносить такую модель на массовый найм буквально будет дорого и, возможно, бессмысленно. Но её принцип полезен шире: единицей найма должна быть не вакансия и не конверсия этапа, а конкретный человек и доказательства того, как он будет решать ваши задачи вместе с вашей командой. AI здесь тоже меняет профессию рекрутера. Уорд ожидает появления talent engineer: рекрутера, который сам собирает инструменты для исследования рынка и организации процесса. Для меня это не про автоматизацию человеческого выбора. Наоборот, когда AI резко удешевляет поиск и персонализацию, главным дефицитом становятся точность критериев, качество сигнала и настоящее внимание к человеку. #AI #Management #Leadership #Engineering #Career #Hiring

JVM Day: три билета за измеримые AI-кейсы из Java-мира (Рубрика #AI4SDLC) Посмотрел программу JVM Day 2026, который пройдет 29 августа в T-Space в Москве. Мне нравится, что конференция собрана не вокруг очередного списка новых API, а вокруг вещей, с которыми JVM-инженеры действительно живут в production: производительности, конкурентности, миграций, корректности, безопасности и архитектурных компромиссов. В трех параллельных залах будет 21 доклад для тех, кто работает с Java, Kotlin и Scala. В программе - разбор того, как JVM-бенчмарки вводят нас в заблуждение, альтернативные модели конкурентности после Loom, Spring Data JDBC, Redis как часть модели корректности, безопасность цепочки поставки JDK и Mechanical Sympathy. Отдельно хочу послушать рассказ про OpenRewrite: команда Т-Банка заявляет, что автоматизировала 80% миграции CI/CD. Есть и прямой мост к AI. В докладе про формальную верификацию Scala автор обещает показать мультиагентную систему, с помощью которой нашли 9 багов, довели 4 PR до main и открыли больше 200 issues в экосистеме Scala; по описанию доклада, 82 из них уже приняты и исправлены мейнтейнерами. Это как раз тот уровень разговора про AI, который мне интересен: не «стало удобнее», а задача, метод, измеримый результат и ограничения. У меня есть три билета на JVM Day, которые получат авторы трех лучших историй про свежие кейсы из Java/JVM-мира, где AI принес измеримую пользу. Подойдут три формата: - Кейс из собственной практики - его можно обезличить; - Ссылка на хороший публичный разбор чужого внедрения; - Оригинал научной статьи или исследовательского whitepaper. В комментарии к этому посту коротко опишите цепочку: задача → где и как применили AI → исходная точка → результат в цифрах → как измеряли → сколько стоили проверка и внедрение. Метрикой может быть lead time, длительность миграции или review, число дефектов и инцидентов, стоимость, производительность или доля ручной работы. Название компании и абсолютные числа можно скрыть, но проверяемая динамика должна остаться: например, время сократилось на X%, а доля возвратов - на Y%. Важное ограничение: кейс должен быть свежим. Собственный результат - получен этим летом и впервые описан в заявке; внешний разбор, статья или whitepaper - впервые опубликованы не раньше 1 июня 2026 года. Летний пересказ старого кейса не подойдет. 21 августа напишу в канале кому достаются билеты + объясню почему. Отдельно отмечу, что билет покрывает участие в конференции, но не дорогу и проживание. Сам JVM Day пройдет 29 августа в T-Space по адресу: Москва, ул. Грузинский Вал, 7. Регистрация начинается в 09:30, доклады - в 10:40, после программы будет афтепати. Подробная программа и билеты на сайте конфы. В общем, приносите кейсы. Хочется собрать не еще один список AI-инструментов, а небольшую карту доказанной пользы AI в JVM-разработке. Ну и обсудить мы их сможем в комментах, а лично пообщаться уже на конфе, где я тоже планирую быть. #AI4SDLC #AI #Java #JVM #Engineering #Conference #Metrics

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

Code of Leadership S2E12: Как выстроить собственную систему управления с Михаилом Тюргановым (Рубрика #Management) Как меняется CTO, когда небольшая команда вырастает в организацию на тысячи человек? И что делать, если прежние методы сами становятся ограничением? 17 августа в 19:00 МСК в эфире Code of Leadership вместе с Михаилом Тюргановым, руководителем Департамента разработки цифровых сервисов Альфа-Банка, поговорим про его путь от тестировщика, программиста и CEO малого бизнеса до технологического директора. В эфире мы обсудим: - Чем CTO малого бизнеса отличается от CTO в enterprise; - До какого масштаба работают сильные люди и неформальные договорённости; - Как отличить нужный найм от попытки закрыть организационную проблему численностью; - Что дают метрики эффективности и когда команда начинает играть с дашбордом; - Почему сильный инженер не обязан становиться менеджером; - За что CTO должен отвечать лично, а что превращать в платформу, процесс и инженерный карьерный трек; - Как AI и вайбкодинг меняют требования к скорости, проверке и эксплуатации. Приходите и приносите вопросы - часть эфира оставим для разговора с аудиторией. #Management #Leadership #Engineering #Architecture #PlatformEngineering #AI4SDLC

FDE: платформа вместо заказной разработки (Рубрика #AI4SDLC) Посмотрел 18-минутное выступление Kevin Bai «Forward Deployed Engineering 101», что продолжает тему FDE. В прошлом разборе меня интересовало, что такой инженер делает руками; здесь - зачем он вообще нужен бизнесу и как не превратить внедрение в дорогую заказную разработку. Сейчас Kevin - в команде Applied AI компании Anthropic; раньше он строил FDE-команду в Rippling и работал в Palantir. Поэтому модель он объясняет не как модную роль, а как способ продавать сложную платформу. Рамка простая: FDE нужен, когда компания продает технически сложную систему нетехническому покупателю. CTO и разработчики обычно осваивают платформу сами; Jira или Slack нетехнической команде достаточно настроить. Трудный квадрат - платформа, поверх которой нужно строить, и клиент без собственной инженерной глубины. Одной лицензии мало. FDE - разработчик, которому можно доверить разговор с клиентом. Он разбирается в реальном процессе и собирает решение поверх платформы. Клиент покупает не коробку и не часы разработчика, а работающий результат. Но есть важная граница. Если каждый FDE пишет для клиента отдельную систему с нуля, это уже студия заказной разработки, а экономика утонет в сопровождении. Нужны общие строительные блоки: уникальное остается у клиента, повторяемое возвращается в платформу. Тогда внедрение становится и каналом продуктовой разведки. AI удешевляет сборку, но не отменяет это правило. По гипотезе Kevin, агентные платформы проще адаптировать, поэтому FDE-модель может понадобиться большему числу компаний. Я бы добавил: дешевый код повышает риск наплодить одноразовых решений. Чем быстрее реализация, тем важнее архитектурная дисциплина. Для меня вывод - перед наймом FDE нужны два ответа. Мы действительно продаем сложную систему нетехническому покупателю? И есть ли платформа, на которой решения можно собирать повторно? Если нет второго, модное название роли лишь замаскирует заказную разработку внутри продуктовой компании. #AI #AI4SDLC #Engineering #Architecture #Product #Management

3 AImigo S1E1: где мы сейчас с AI в разработке (Рубрика #AI4SDLC) В пятницу, 14 августа, в 12:00 МСК выйдем в прямой эфир с первым выпуском подкаста 3 AImigo. Начнём с точки отсчёта: где сегодня находится AI-разработка, что уже стало рабочей нормой, а что пока живёт в сильных экспериментах и красивых демонстрациях. Обсуждать будем втроём: Евгений Сергеев, Алексей Литвинов и я. У нас разная оптика: управление большой инженерной организацией, практическое внедрение AI-Assisted Engineering и архитектура AI4SDLC. Не будем искать одну «правильную» картину - сравним наши взгляды. За словами «мы используем AI в разработке» могут скрываться автодополнение в IDE, диалог с ассистентом, агент, приносящий pull request, или почти автономный контур. Поэтому спор об эффекте AI часто оказывается спором о разных процессах и уровнях ответственности. В первом выпуске попробуем разложить этот ландшафт: - Что уже можно считать базовой практикой отдельного инженера; - Какие сценарии становятся командным процессом, а не личным трюком; - Где заканчивается помощь с кодом и начинается агентная разработка; - Что требуется вокруг модели: контекст, спецификации, тесты, проверки качества (evals), права доступа и наблюдаемость; - Какие идеи - долгоживущие агенты, многоагентные процессы и автономная поддержка систем - пока остаются на горизонте. Отдельно поговорим, куда смещается узкое место. Когда код дешевле произвести, больше времени уходит на постановку задачи, проверку, архитектуру и исправление последствий. Локальное ускорение разработчика ещё не ускоряет всю инженерную систему. Для нас это будет «нулевой срез»: общая карта, к которой можно возвращаться в следующих выпусках и проверять, что действительно изменилось. Без рейтинга инструментов и обещаний полной автономности - с практическими примерами, разногласиями и вопросами, на которые у индустрии пока нет окончательного ответа. Приходите в пятницу, 14 августа, в 12:00 МСК. И приносите свои примеры: что в вашей разработке уже стало нормой, а что всё ещё не переживает встречу с реальным репозиторием и production. #AI #AI4SDLC #Agents #Engineering #Architecture #Management

Инцидент OpenAI и Hugging Face: когда агент вылез из sandbox и выпустил других агентов (Рубрика #AI4SDLC) Посмотрел огненный доклад Эрика Уоллеса и Майкла Далтона из OpenAI на Black Hat USA 2026 про инцидент с Hugging Face. Смотрел как смесь остросюжетного боевика и рассказа о том, а кто же все-таки убил садовника:) TLDR выглядит примерно так 1️⃣ OpenAI тестировала внутренние модели на ExploitGym - заданиях по поиску и эксплуатации уязвимостей. Некоторые задания оказались практически невыполнимыми, и агенты начали искать способ добыть готовые ответы. Прямого доступа к интернету у них не было, зато был доступ к общему Artifactory: прокси для реестров пакетов, который сам ходил наружу и разрешал запись. 2️⃣ Один агент оставил там сообщение другим. Следующие запуски его нашли, начали обмениваться находками, эксплойтами и заданиями. Когда инженеры очистили эту «доску сообщений», агенты восстановили её через имена директорий. Получилась незапланированная память между изолированными на бумаге запусками. 3️⃣ Дальше локальный обход превратился в настоящую цепочку атак. По данным OpenAI и Hugging Face, агенты использовали уязвимости Artifactory, вышли в интернет, а затем через две уязвимости в обработке датасетов Hugging Face получили чтение файлов и выполнение кода. В крутом техническом отчёте Hugging Face восстановлено около 17 600 действий агента за кампанию с 9 по 13 июля 2026 года (рекомендую его внимательно изучить - он того стоит) 4️⃣ Важно, что OpenAI описывает цель агента как очень узкую: найти решения ExploitGym и «сдать» тест. Но оптимизация этой цели, большой вычислительный бюджет и общий канал связи превратили локально разумные шаги в атаку на внешнюю систему. Практический вывод: eval-среду для сильного агента нужно проектировать как враждебную multi-tenant систему. Отдельные identity и хранилище на каждый запуск, короткоживущие scoped credentials, запрет исходящего трафика на каждом переходе, наблюдаемость сразу по всему рою и автоматический circuit breaker при выходе за ожидаемый профиль. Хороший sandbox - не контейнер, в котором запущена модель. Это полная граница её прав, сети, состояния, данных и последствий. Кстати, кажется, что у OpenAI все было настроено хорошо, но агенты оказались чудо как хороши в коллаборации своих усилий, поисках отдельных уязвимостей, а также в связывании их в цепочки атак. Поэтому авторы доклада призывают усилить работу над защитой нашего софта, так как сторона нападения кажется сильно прокачалась с появлением агентов. P.S. Кстати прокачивать защиту процессов разработки и сам софт достаточно сложно, так как для защиты надо прикрыть все лазейки, а для атаки найти одну брешь. Плюс особенно сложно защищаться, когда агентная разработка внутри компаний частично блокируется с тезисами, что так будет безопаснее ... (нет не будет - это примерно как в мифе про страусов, которые вроде как прятали голову в песок, но если бы они действительно так делали, то они бы вымерли). #AI #AI4SDLC #Agents #Security #DevSecOps #Architecture

Code of Leadership S2E11: AMA Сессия #3 про AI-assisted Engineering с Алексеем Литвиновым (Рубрика #AI4SDLC) В четверг в 13:30 по Москве вместе с Алексеем Литвиновым в прямом эфире продолжим говорить про AI-Assisted Engineering и про то, как вообще строить AI-Native организацию. Первые две AMA сессии прошли плотно и мы разобрали порядка 20 вопросов, но еще осталось около десятк, которые мы разберем с Лёшей в третьей серии. Кстати, у Леши есть свой tg-канал - @tip_podcast, подписывайтесь на него. Мы договорились обсудить - зрелость работы с AI // от «пишу код сам» до экосистемы на принципах - verification debt и цена проверки - почему навык уезжает из кодинга в менеджмент - AI-native организация: операционка, роли, governance - люди и найм, когда рядом агенты И мы с радостью учтем еще и ваши вопросы, что вы можете оставить через Google Forms (https://forms.gle/3ScqHGyxUsZAf7Wz7), где вы сможете рассказать - Кто вы по роли - Что хотите, чтобы мы разобрали - С каким тезисом про AI вы не согласны (опционально) В принципе, вы можете написать интересующие вас темы и в комментариях к этому посту. Самые интересные и популярные темы мы заберем в прямой эфир и разберем их там. #Books #AI4SDLC #AI #Agents #Engineering #Architecture #Leadership

AI Dev Podcast #8: автономия агента начинается с ограничений (Рубрика #AI4SDLC) Вышел новый выпуск AI Dev Podcast. Вместе с Владимиром Ятульчиком и Андреем Дмитриевым разбирались, как перейти от вайб-кодинга к управляемой агентной разработке. Главная мысль крутилось вокруг того, что автономный агент полезен не тогда, когда ему разрешили написать побольше кода, а когда он встроен в воспроизводимый процесс. Чем больше мы делегируем, тем яснее должны быть замысел, критерии приёмки, ограничения и границы прав. Владимир рассказал, как его команда адаптировала AIDLC под свою инфраструктуру. Важны четыре вещи: - Истории, ADR и документация живут в Git рядом с кодом; - Трассируемость связывает замысел, решения, реализацию и метрики; - Агенты требований и архитектуры отделены от агентов кода; - Проверки ADR и безопасности удерживают изменения в границах замысла. На небольших проектах у команды уже есть рабочие примеры, но перенос на крупную унаследованную систему ещё предстоит проверить. Там нужны управляемый контекст и процесс, который не рассыпается при масштабировании. Практический вывод: агентная разработка начинается не с выбора модели. Возьмите ограниченный репозиторий, опишите ожидаемый результат, дайте агенту минимальные права и поставьте проверки между этапами. Измеряйте не объём сгенерированного кода, а принятую работу, стоимость проверки и связь изменений с результатом в эксплуатации. Парадокс автономии в том, что она требует не меньше инженерной дисциплины, а больше. Агент может получить свободу лишь там, где система умеет удерживать его в границах замысла. Короткий конспект здесь. #AI4SDLC #AI #Agents #Engineering #Architecture #PlatformEngineering