Книжный куб

Paper: как выглядит дизайн-инструмент эпохи агентов (Рубрика #AI4SDLC) Посмотрел выпуск Design Review от Y Combinator «How To Design In The Agent Era», опубликованный 7 августа 2026 года: Stephen Haney, основатель дизайн-инструмента Paper, вместе с партнером YC Aaron Epstein разбирает присланные зрителями сайты. Формально это шоу про редизайны, но мне интереснее другое: Paper — редкий пример инструмента, спроектированного под агентов с нуля, а не адаптированного к ним задним числом. Сначала контекст. Haney копает проблему designer-developer handoff давно: он сооснователь Modulz и один из авторов Radix UI — одной из самых популярных библиотек React-компонентов. После продажи Modulz компании WorkOS он два года отвечал там за продукт, а Paper — его второй заход на тот же разрыв, теперь с учетом агентов. Инженерная суть — в одном архитектурном решении. Классические дизайн-инструменты рендерят канвас проприетарными движками, и агенту приходится работать с ними через экспорт и plugin API: трансляция форматов стоит токенов, добавляет латентность и порождает отдельный класс галлюцинаций. В Paper канвас — это живые HTML и CSS: каждый объект на экране и есть код веба. Агент (Cursor, Claude Code и другие) подключается через MCP-сервер и пишет буквальный HTML, который канвас рендерит без слоя трансляции. Формула Haney: хороший handoff для людей автоматически оказывается хорошим handoff для агентов. Рабочий контур получается таким: дизайнер оставляет комментарии или снимает живой сайт в редактируемые слои расширением Paper Snapshot, агент генерирует варианты хоть за ночь, человек курирует — удаляет, ветвит, дорабатывает. По словам Haney, их собственный маркетинговый сайт brand-дизайнер собрал в Paper и довел до Next.js-кода с анимациями и шейдерами примерно за неделю, без участия инженеров. Практическая часть выпуска — каталог типовых признаков AI-генерированного дизайна: жирные начертания везде, пять-восемь размеров шрифта вместо трех, ALL-CAPS подзаголовки с разреженным letter-spacing, pill-бейджи на каждой карточке, фиолетовые градиенты (перекос обучающих данных после успеха Linear), перегруженные карточками секции, переключатель темной темы в MVP. Haney описывает это как неуверенного дизайнера, запеченного в веса модели, а лечит удалением: значительная часть дизайна — это deleting. На живых редизайнах (Legion Health, Sytex, Moreta) картина повторяется: тексты и value proposition обычно в порядке, проваливается визуальная сборка и иерархия. Отдельно занятно, как команда Paper использует агентов сама: 12 человек, Cursor, Claude Code и Bugbot, но каждую строку кода читают люди — канвас должен стабильно держать высокую производительность, и такого уровня системного качества агенты пока не выдают. Принцип Haney: use agents to accelerate the people. Это хорошо рифмуется с тем, что я уже разбирал. WebMCP — та же идея на уровне веба: вместо «посмотри на пиксели и угадай» сайт отдает агенту явные инструменты. Выступление Geoffrey Litt — про то, что генерация дешевеет, а узким местом становится понимание; у Haney та же логика про вкус: агенты быстро подтягивают тактику вроде весов, контраста и отступов, но выбор направления и поиск «следующей эстетики» остаются за человеком. А история продакта из Meta, который запускает продукты, почти не умея программировать, показывает ту же смену роли, только для дизайнера: меньше ручного производства, больше постановки задачи и кураторства. Для меня главный вывод такой: артефакты, рассчитанные только на человеческий глаз, становятся налогом на агентный стек. Выигрывают инструменты, где человеческий и машинный доступ — один контракт: дизайн, который агент читает и правит как код, и код, который дизайнер видит как канвас. Насколько Paper действительно «самый быстрорастущий дизайн-инструмент со времен Figma» — пока утверждение YC и самой команды, но направление мне кажется правильным. P.S. После этого видео, я решил, что надо попробовать этот инструмент в деле:) #AI4SDLC #AI #Agents #DevTools #Product #Engineering

Через 5 минут стартует прямой эфир с Михаилом Тюргановым, руководителем Департамента разработки цифровых сервисов Альфа-Банка, где мы поговорим про его путь от тестировщика, программиста и CEO малого бизнеса до технологического директора. Если кратко, то мы обсудим как меняется CTO, когда небольшая команда вырастает в организацию на тысячи человек? И что делать, если прежние методы сами становятся ограничением?

Материалы с первого выпуска подкаста "3 AImigo" (Рубрика #AI) Наша первая серия о том, где сейчас находится AI-разработка вышла очень бодрой. Мы обсуждали ее втроём: Евгений Сергеев, Алексей Литвинов и я, а ниже представлены материалы выпуска - Страничка эпизода - Видео: YouTube, VK Video - Аудио: Podster, Яндекс Музыка - Текст: Краткая расшифровка И бонусный лонгрид, что я написал, когда я готовился к этому выпуску. P.S. У Леши есть свой канал в tg @tip_podcast и на Youtube, а у Жени пока нет:) #AI #Management #Processes #Engineering #Software #AI4SDLC #Software #Agents #Leadership

Сегодня разбирала детскую бибилиотеку дома и вот вам подборка неочевидных детских книг, которые понравятся и взрослым: 1. Доктор Сьюз "Это только начало" - лучшее мотивационное чтение, если вдруг вы забыли как это, находить себя и не бояться ошибаться 2. Деби Глиори "Что бы ни случилось" - если вдруг вам стало одиноко и хочется просто тепла и знать, что вас любят 3. Жан-Люк Фроманталь "Не опаздывай медведь" - немного посмеяться над нашей вечной гонкой — и заодно подумать о том, какую власть над нами имеет время 4. Даниэла Кункель "Маленький Мы" - про то, что один в поле не воин и как в дружбе появляется что-то третье, наше "мы" Классные они не только смыслом, но и тем, что прочитать их можно за 3-5 минут, а удовольствия получить на целый день❤️

Мы разбирали эти книги вместе с моей женой, Настей, и она мне порекомендовала почитать "Доктор Сьюз "Это только начало" - лучшее мотивационное чтение, если вдруг вы забыли как это, находить себя и не бояться ошибаться. Эта книга отлично подходит для тех, кого ждут большие перемены:)

Boris Cherny: We Cut 80% of Claude Code's Prompt (Рубрика #AI4SDLC) Посмотрел выступление Boris Cherny, создателя Claude Code, на Y Combinator Startup School 2026 — записанное на следующий день после релиза Opus 5. Его интервью в подкасте Lightcone я уже разбирал, как и внутреннее устройство Claude Code, а тут главное — продуктовая философия: под новое поколение моделей команда вырезала больше 80% системного промпта, и, по словам Бориса, без измеримой потери качества на их кодинг-evals. Логика такая: системный промпт — это по большей части накопленные заплатки под ошибки конкретного поколения моделей. Новая модель этих ошибок уже не совершает, а старые инструкции и примеры начинают ее ограничивать: «ты хочешь ответы вот такие» — и модель послушно равняется на устаревший образец. Поэтому методология у команды жесткая: с каждым релизом модели промпт вычищается почти до нуля, а строки возвращаются только тогда, когда модель повторно спотыкается на одном и том же. По рассказу Бориса, есть даже флаг CLAUDE_CODE_SIMPLE=1, убирающий вообще все промпты, включая зашитые в тулы, — и в таком «голом» режиме модель на замерах оказывается даже чуть умнее. То же с evals: они насыщаются за 1-3 поколения моделей, после чего их нужно пересобирать. Продуктово мне понравился термин product overhang: у модели есть способности, которые продукт не раскрывает, потому что сам стоит у нее на пути. Claude Code родился именно из такого наблюдения: Sonnet 3.5 уже умел писать целые файлы и фичи, а продукты вокруг предлагали автокомплит и read-only чат. Получается, ценность харнеса не в том, что он добавляет поверх модели, а в том, чему он не мешает, — хорошая рифма к harness factory model из The New SDLC, который я разбирал. Про навыки: Борис описывает сдвиг от prompt engineering через context engineering к elicitation — умению дать модели задачу «чуть сложнее, чем кажется возможным» плюс механизм верификации, не переспецифицируя решение. Формула как с сильным коллегой: задача, ограничения, критерии готовности. Забавно смотрится на фоне книги Prompt Engineering for LLMs — за полтора года дисциплина прошла путь от «как правильно писать инструкции» до «как их правильно удалять». И это согласуется с исследованием Anthropic про экспертизу: успех с агентом определяется умением ставить задачу и проверять результат, а не магическими формулировками. Масштаб иллюстрируют две истории, обе со слов Бориса: команда Bun переписала с Claude больше 100 тысяч строк рантайма с Zig на Rust за 11 дней непрерывной работы (людьми — год с лишним), а его собственный эксперимент по переписыванию Electron-приложения на нативный Swift к моменту доклада шел третью неделю с тысячами порожденных агентов — и Claude сам завел Slack-канал, куда постит скриншоты прогресса. Для меня главный вывод: системный промпт и CLAUDE.md — это технический долг со сроком годности в одно поколение моделей. Инструкции, накопленные под прошлую модель, для новой превращаются из подпорок в ограничители, поэтому «press delete» — не жест смелости, а регулярная инженерная процедура, как чистка зависимостей. P.S. В общем, если у вас есть доступ к SOTA моделям, то вам все меньше надо императивно управлять потоком исполнения и загонять модель в рамки. Вместо этого вы переходите к классической инверсии контроля (IoC, Inversion of Control), где модель использует «голливудский принцип» («не звоните нам, мы сами вам позвоним») и модули низкого уровня не вызывают модули высокого уровня (а здесь это модель) напрямую. Вместо этого модель сама управляет вызовами и дергает доступные модули, когда ей это нужно. #AI4SDLC #AI #Agents #Evals #DevTools #Engineering

Материалы с третьей части 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-инженером становится заметно тоньше. Прототип теперь можно собрать за несколько дней, но главный вопрос начинается после демо: кто превратит продуктовое намерение в воспроизводимые проверки и возьмёт ответственность за поведение вероятностной системы?