Research Insights Made Simple #20: почему coding agents не отменяют экспертизу (Рубрика #AI4SDLC)

Что остаётся человеку, когда coding agent выбирает файлы, запускает команды и пишет реализацию? В четверг, 16 июля, с 16:00 до 17:00 МСК обсудим это с Евгением Сергеевым в прямом эфире "Research Insights Made Simple - Season 1, Episode 20". Мы разберем whitepaper Anthropic "Agentic coding and persistent returns to expertise".

Евгений Сергеев — Director of Engineering в Flo Health. Он развивает продуктовые инженерные команды и занимается практическим внедрением AI в разработку: coding agents, eval-driven development, quality gates и AI-assisted workflows. Женю интересует, как сделать работу с агентами управляемой и проверяемой — и что происходит с инженерной экспертизой, когда код писать становится дешевле, а цена неправильных решений остаётся высокой.

Если же возвращаться к папире, то авторы проанализировали 398 198 интерактивных сессий 234 751 пользователя Claude Code и пришли к выводу, что экспертиза пользователей в задаче связана с более глубоким делегированием агенту и более частым успехом сессии. Но это наблюдательная выборка одного продукта, а не эксперимент о производительности всей индустрии. Поэтому обсудим не только цифры, но и границы того, что они доказывают:
- Почему экспертиза здесь - знание конкретной задачи, а не грейд или стаж;
- Что означает разделение труда: человек принимает около 70% решений о том, что делать, но лишь 20% - о том, как;
- Почему экспертные сессии запускают примерно вдвое больше действий агента, но это ещё не означает вдвое большую продуктивность;
- Можно ли считать рост "verified success" с 14,5% до 32,9% эффектом экспертизы или мы видим только корреляцию;
- Где граница между успешной сессией, принятым PR, надёжным продакшен кодом и пользой для бизнеса;
- Как командам измерять время проверки, переделки, дефекты и сохранение знаний, а не только скорость генерации.

Отдельно поговорим об организационном парадоксе: опытный инженер способен сильнее разогнать агента, но если всё исполнение отдавать машине, откуда возьмутся следующие опытные инженеры?

Для меня это разговор не о том, заменит ли Claude Code разработчика. Вопрос практичнее: какая экспертиза становится дефицитной, когда код дешевеет, а цена неверного решения остаётся у команды. Приходите на прямой эфир в четверг, 16 июля, с 16:00 до 17:00 МСК. Будем разбирать методологию, спорить с выводами и переводить whitepaper в вопросы к реальному AI4SDLC.

P.S.
Сам whitepaper я уже разбирал в двух частях: 1 и 2.

#AI #AI4SDLC #Research #Engineering #Agents #Metrics #DevEx

AI-Assisted Engineering: от удачного промпта к инженерной системе (Рубрика #Books)

Недавно прочитал книгу Алексея Литвинова "AI-Assisted Engineering", с которым сегодня мы обсудим его книгу в прямом эфире. Изначально Алексей предложил мне прочитать его книгу и дать обратную связь. Я с удовольствием взялся за чтение книги, чтобы оценить как можно собрать разрозненные практики работы с AI-агентами в одну систему. В итоге, самым полезным в книге оказалась не отдельные паттерны или методологии, а карта взросления: как перейти от удачных экспериментов с агентом к управляемой и воспроизводимой разработке.

Книга выстроена как большой учебник и идёт от простого к сложному. В самом начале Алексей задаёт лестницу из девяти уровней работы с AI, а дальше все 650+ страниц ведёт читателя по этой модели зрелости: от общего языка и одиночного агента - через спецификации и команды агентов - к внедрению на уровне организации.

Мне понравилось, что внутри разведены три типа материала:
- Уроки дают общую инженерную рамку: контекст, делегирование, петлю обратной связи, контроль результата;
- Паттерны описывают переиспользуемые детали - инварианты, AGENTS.md, послойную подачу контекста, проверки качества, worktree, разделение агента и человека;
- Методологии показывают, как из этих деталей собираются более крупные процессы: GitHub Spec Kit, OpenSpec, Kiro, Tessl, BMAD-METHOD, AI-DLC и другие.

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

Все эти идеи Алексей демонстрирует на сквозном примере Audit Log Service. Один и тот же сервис проходит через правила проекта, спецификации, CI/CD, проверки, работу нескольких агентов и след для аудита. К концу книги этот audit log уже физически не можешь видеть, но педагогически приём работает: меняется не предметная область, а зрелость системы вокруг агента.

Для меня главный тезис книги такой: AI-native разработка - это не ситуация, где модель пишет как можно больше кода. Это система, в которой мы можем делегировать исполнение, не теряя понимания, проверяемости и ответственности за результат. Поэтому выбор очередной модели здесь вторичен по сравнению с контекстом, спецификацией, обратной связью и качественными ограничениями.

Книга хорошо подойдёт инженерам уровня middle и выше, архитекторам и техническим руководителям, которые уже используют coding agents, но пока собирают свой процесс из отдельных находок. Её стоит читать тем, кто хочет не набор «магических промптов», а подробный маршрут к AI-native разработке - включая масштабирование на несколько агентов и внедрение в организации. А вот если нужен быстрый туториал на вечер или готовый рецепт «поставьте три файла и получите x10», книга вряд ли зайдёт. Это именно учебник: подробный, местами повторяющийся и требующий времени. Здесь это одновременно и ограничение, и главная ценность.

Сегодня, 15 июля, в 13:00 МСК мы поговорим с Алексеем о его инженерном опыте и книге на стриме Code of Leadership. Хочу отдельно обсудить, как эта лестница зрелости появилась на практике, какие паттерны переживают смену моделей и где при масштабировании агентной разработки возникает настоящее узкое место.

Присоединяйтесь к стриму и задавайте вопросы.

#Books #AI4SDLC #AI #Agents #Engineering #Architecture #Leadership

Research Insights Made Simple #21: как измерять кодинговых агентов в диалоге (Рубрика #AI4SDLC)

Что меняется, если требования к кодинговым агентам приходят не идеальным промптом, а уточняются по ходу?
17 июля в 16:00 МСК обсудим это с Алексеем Литвиновым в выпуске подкаста "Research Insights Made Simple #21". Мы поговорим про новые бенчи SWE-Together и SWE-INTERACT, опубликованные в один день. Оба я уже по отдельности разбирал в этом канале (SWE-Together и SWE-INTERACT). Вместе они показывают одну важную вещь: способность агента автономно выдать код по готовому, исчерпывающему ТЗ (как в классическом SWE-bench) ещё не означает, что он будет полезен в реальной совместной работе. На практике требования редко приходят идеальным промптом - они дорабатываются на лету, и здесь на первый план выходит способность адаптироваться под меняющийся контекст.

Алексей Литвинов — Principal Engineer, автор книги и [образовательной программы по AI-Assisted Engineering](https://edu.alekseilitvinau.com/). Он исследует и внедряет способы превратить работу с AI-агентами из набора удачных экспериментов в управляемый, воспроизводимый и проверяемый инженерный процесс на реальных кодовых базах. У Лёши есть и Telegram-канал — @tip_podcast.

Если же возвращаться к самим бенчам, то
- SWE-Together (от исследователей из запрещенной в России компании Meta) идёт от реальных пользовательских сессий и вводит метрику User Correction - сколько раз человеку пришлось вернуть агента на курс
- SWE-INTERACT (от исследователей из Scale.ai) делает обратный эксперимент: берёт те же задачи и те же проверки, но раскрывает требования постепенно. У сильных моделей доля решённых задач в таком режиме падает примерно вдвое, а работа становится длиннее и дороже.
Интерес этих исследований не в очередном рейтинге моделей. Они позволяют увидеть цену диалога: корректирующее руление, забытые требования, повторные проверки и зависимость результата от обвязки агента. Multi-turn работа оказывается отдельной инженерной способностью.

Мы поговорим о том, какая из двух методик ближе к реальной разработке, можно ли доверять симулятору пользователя, почему агент забывает требования из ранних реплик и как командам строить собственные multi-turn evals.

17 июля, 16:00 МСК. Приходите разбираться и спорить вместе с нами.

#AI #AI4SDLC #Agents #Evals #Engineering #Research

Как я с агентами запил сегодня себе прямые эфиры на статический сайт без обычного бэкенда (Рубрика #Architecture)

На этой неделе у меня четыре разговора с экспертами в прямом эфире: два уже прошли, два ещё впереди. Формат общения в реальном времени перестал быть для меня разовым экспериментом, и в какой-то момент стало странно, что мой сайт polomodov.tech об этом ничего не знает. Я хотел простое поведение: если в ближайшие семь дней запланирован эфир, сайт сам показывает анонс. Когда трансляция начинается, блок переключается в состояние live. Если эфира нет, ничего не нужно править руками, пересобирать или выкладывать специально ради одной плашки.

Здесь было интересное ограничение. Сайт статический, собран на GitHub Pages и работает на собственном домене. Обычного бэкенда у него нет, и заводить отдельный сервис с сервером и базой данных ради статуса трансляции мне не хотелось. Но совсем без серверной части не обойтись: YouTube API требует OAuth, а значит, где-то должны безопасно жить client secret и refresh token.

В итоге, я сегодня утром пообщался с Codex и мы спроектировали такую схему
- Добавили не полноценный бэкенд, а один узкий динамический слой - Cloudflare Worker.
- Раз в две минуты Worker через OAuth запрашивает у YouTube списки active и upcoming трансляций;
- Отбрасывает непубличные эфиры и эфиры другого канала, затем выбирает текущий либо ближайший запланированный;
- Сохраняет в Workers KV нормализованный снимок из трёх состояний - offline, upcoming, live - и отдельно кэширует access token;
- Наружу отдаёт только публичный read-only endpoint /status, без OAuth-данных и лишних деталей YouTube API;
- Браузер опрашивает этот endpoint раз в минуту, но только пока вкладка видима.

Отдельно предусмотрено не только как показать эфир, но и как безопасно перестать его показывать. Клиент проверяет версию схемы и все поля ответа. Если снимок старше десяти минут, он считается устаревшим и интерфейс возвращается в offline. Так же скрывается анонс, если трансляция запланирована дальше чем на семь дней. Ошибка YouTube или Worker не превращается в вечную плашку «мы в эфире».

Сам плеер тоже не загружается заранее. Для активной трансляции iframe появляется только после клика. Если я впаду в маразм и запрещу встраивание Youtube-фрейма, то сайт покажет превью и ссылку на страницу YouTube. А в навигации индикатор появляется только для состояния live. Операционную часть я тоже не оставил «на потом»: изменения Worker выкладываются отдельным сценарием GitHub Actions, а ещё один сценарий раз в час проверяет схему /status и свежесть данных. При этом посещения сайта не увеличивают число запросов к YouTube - к API обращается только Worker по расписанию.

Круто, что все это от начала и до релиза заняло меньше дня:
- Сегодня утром с агентом мы договорились об архитектуре
- Основной PR открылся в 12:46
- В 15:48 ветка синхронизировалась с main (я поревьювил и принял измения)
- Дальше я настроил все токены и доступы по инструкции агента между Google Cloud Console, Cloudflare, Github
- А в 17:09 изменения были смержены и дальше раскатаны
- К 18:00 на сайте уже отображался завтрашний стрим с Женей Сергеевым про whitepaper Anthropic

В общем, сейчас разработка своих пет-проектов - это чистый фан, особенно если ты разбираешься в инженерии и настроил кучу детерминированных проверок, которые позволяют агенту безопасно достигать поставленных целей:)

#Architecture #Engineering #Web #Cloudflare #DevOps #YouTube

Стрим стартанул, приходите смотреть https://www.youtube.com/watch?v=__4xRni7V6c

Материалы про Loop Engineering (Рубрика #RnD)

Готовы материалы с подкаста Research Insights Made Simple, который был во вторник с Максимом Смирновым:
- Презнтация: Слайд дека с разбором
- Видео: Youtube, VK
- Аудио: Podster, Ya Music
- Текст: Краткая расшифровка

#AI4SDLC #Agents #Architecture #Engineering #Research

AI для software architecture: почему в 2026-м copilot архитектора всё ещё не получился (Рубрика #Architecture)

Бегло пролистал систематический обзор литературы "Artificial Intelligence Support for Software Architecture Practice", в котором поставлен практичный вопрос - а какие архитектурные задачи AI уже умеет поддерживать и почему отдельные успехи пока не складываются в целостную практику. Первая версия появилась в 2025 году, но в 2026 году ее обновили и 2 июля 2026 года статья вышла в ACM Transactions on Software Engineering and Methodology. При обновлении обзор литературы доведен до августа 2025-го, добавлен срез массовых инструментов на март 2026-го.

Авторы начали свой анализ с 874 публикаций из четырех научных баз, отдельно проверили ICSA и ECSA и оставили 51 рецензируемое исследование. Затем сопоставили результаты с проблемами из предыдущих интервью с 32 практиками. И выяснили следующее

1️⃣ В ограниченных задачах AI уже полезен
Модель для выбора одного из трех паттернов по требованиям показала точность 70%; извлечение архитектурных зон ответственности из текста - около 75% полноты (recall) на четырех проектах. На корпусе из 95 ADR GPT-4 давал связные решения, но уступал человеку по полноте. Это не готовый «архитектор», а ускоритель первого прохода с обязательной проверкой.
2️⃣ Убедительнее всего выглядят задачи с измеримым контуром
На небольшом стенде Kubernetes комплексный фреймворк с прогнозированием нагрузки сократил время развертывания контейнеров на величину до 34%; RL-агенты лучше случайного chaos monkey находили критические отказы, правда, пока в симуляции. Промышленное подтверждение есть в автомобильных, аэрокосмических и киберфизических системах - там, где задача узкая, а quality attributes можно посчитать.
3️⃣ Ранний дизайн и стратегические решения остаются в основном академическими прототипами
Модели умеют предложить границы, паттерн или ADR по текущему контексту, но плохо удерживают организационные ограничения, регуляторику, историю компромиссов и последствия изменений.
4️⃣ В отдельном срезе 21 массового инструмента авторы увидели ту же асимметрию
Больше всего AI-функций уже есть в observability, governance, conformance и локальной генерации. Слабее всего - в рассуждении на уровне всей системы, двусторонней связи intent/ADR/code/runtime и накоплении сигналов архитектурной эрозии во времени.

В общем, если обобщить, то на уровне текущего среза AI инструменты уже помогают с архитектурными решениями, но на уровне helicopter view и эволюции архитектуры во времени они пока не тянут.

Если смотреть на подход авторов к анализу, то они выделили (картинки приложил)
- Software Architecture challenges
- AI-specific challenges
- И список тем, в которых есть AI инструменты
И сделали маппинг между ними и дальше из этого получили инсайты выше

Если анализировать актуальность работы в 2026 году, то можно увидеть, что с 2025 года появились ArchBench, R2ABench, CAKE и SAKE - то есть один из пунктов роадмапа авторов этого обзора (архитектурные датасеты и бенчи)уже начали закрывать. Но результаты пока скорее подтверждают диагноз авторов
- В R2ABench модели хорошо строят синтаксически корректные диаграммы и извлекают сущности, но слабо связывают их отношениями, из-за чего архитектура получается фрагментированной; агентные процессы (agentic workflows) добавили нестабильности, а не устойчивого выигрыша
- SAKE отдельно предупреждает: знание архитектурных терминов - необходимый фильтр, но не доказательство способности проектировать конкретную систему с ее trade-offs.

Роадмап развития AI в архитектуре от авторов статьи вообще выглядит примерно так
- Живая архитектурная база знаний: требования, решения, код, телеметрия со сквозной traceability
- Живые арх метрики и проверяемые бенчи
- Поверх этого уже можно строить архитектурный интеллект, который развивается вместе с системой: AI играет роль сильного аналитика, а человек остается стратегом и отвечает за контекст, приоритеты и компромиссы.

Вообще можно использовать такие 2 вопроса как лакмусовую бумажку:
- Если меняется требование, то мы можем понять затронутые ADR, компоненты, код, атрибуты качества и рантайм сигналы?
- Если случился инцидент, то можем ли мы отследить в обратном направлении до архитектурного запашка, а дальше вообще к решению, которое его породило?
Если нет, LLM лишь сделает красивее очередной статический снимок - полезный архитектурный AI со связности инженерных данных и способности проверить рекомендацию на истории системы.

В общем, AI повышает цену архитектурной дисциплины - чем дешевле локальная генерация решений, тем важнее удерживать намерение, границы, trade-offs и последствия во времени.

#Architecture #AI #AI4SDLC #Engineering #Research #Software #SystemDesign

Мысли про архитектуру (Рубрика #Architecture)

Поймал себя на мысли, что в своих пет-проектах я архитектуру улучшаю из идеи, что хочу быстро пилить фичи, но
- Не хочу тратить много денег на обслуживание - нужны эффеrтивные CI/CD пайплайны и оптимальная схема для работы в проде
- Не хочу тратить много времени на поддержание - приложения должны быть self-healing, а эволюция решения простой в нужную мне сторону
- Не хочу тратить много слов на объяснение агентам как пилить новые фичи (на объяснение что пилим тратить время готов) - должны быть заданы понятные архитектурные рамки
- Не хочу тратить много сил на ревью и разбираться с регрессионными багами - нужно много детерминированных проверок

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

P.S.
Мысли появились во время изучения whitepaper про AI для software architecture, ну и в рамках фиксов очередных проблем, где я чуток архитектурно залажал.

#Architecture #Engineering #Software #SystemDesign

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

Материалы про AI-assisted Engineering (Рубрика #AI4SDLC)

Готовы материалы с подкаста Code of Leadership, который был в среду с Алексеем Литвиновым:
- Презнтация: Слайд дека с разбором
- Видео: Youtube, VK
- Аудио: Podster, Ya Music
- Текст: Краткая расшифровка

#AI4SDLC #Agents #Architecture #Engineering #Software #Books

Research Insights Made Simple #22: как собрать управляемый агентный стек (Рубрика #AI4SDLC)

Что компания делает «своим» в агентной платформе: код клиента, модель, контур исполнения, данные или право агента менять внутренние системы? Эти вещи часто смешивают и сводят выбор к спору между «своим OpenCode» и «чужим Claude Code или Codex».

В понедельник 20 июля в 17:00 по мск мы с Мишей Трифоновым из Cloud.ru разберём в прямом эфире эту ложную развилку и соберём полное описание агентного стека в рамках 22-м выпуска подкаста Research Insights Made Simple.

Миша Трифонов - Директор департамента внутренней платформы разработки Cloud.ru и у него есть свой интересный канал @trifonovit

Рабочая формула шире привычной пары «модель + обвязка»:
агентный стек = обвязка + модель + инструменты + идентичность + технические границы исполнения.

Обвязка управляет циклом работы и контекстом, модель предлагает план, инструменты создают реальный эффект. Идентичность, sandbox и policy engine определяют, от чьего имени и в каких границах действует агент.

Поговорим о восьми конфигурациях: от автономного стека и локальной модели до внешнего планировщика, корпоративного tool gateway и полного SaaS. У каждой схемы своя цена контроля, скорости, lock-in и эксплуатации.

Отдельно обсудим несколько неочевидных следствий:
- open source ≠ local inference;
- self-hosted ≠ безопасные действия;
- доступы сотрудника ≠ доступы агента
- внутренний MCP ≠ узкие полномочия;
- внешний API ≠ внешнее право на действие;
- multi-model router = отдельная платформа.

Ключевая идея — разделить два пути. Модельный шлюз контролирует, какие данные и к какой модели уходят. Инструментальный шлюз решает, кто, что и от чьего имени может изменить. Между ними нужны единые identity, policy, trace и evals.

И здесь разговор переходит к безопасности. Атакуют не абстрактную модель, а путь от недоверенного README, issue или tool result до действия с реальными полномочиями. Поэтому ограничения должна обеспечивать инфраструктура, а не системный промпт.

В общем, мы обсудим не «какой агент лучше», а какую минимальную конфигурацию выбрать для пилота, корпоративной платформы или регулируемого контура — и кто отвечает за фактическое изменение системы.

Добавляйте стрим в ваш календарь, чтобы не пропустить его.

#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Security #Engineering

The Java Story: как язык стал долгоживущей платформой (Рубрика #Software)

Посмотрел вчера в прямом эфире документалку «The Java Story» от CultRepo про историю Java. В кадре были James Gosling, Joshua Bloch, Brian Goetz, создатели Tomcat, Spring, Hibernate и Kotlin, а также инженеры Java-экосистемы. Но для меня это не столько история просто языка, скорее это история про целую технологическую платформу, что пережила собственные ошибки, смену владельца и попытки объявить её мёртвой. И кажется, что причина в том, что эта платформа научилась меняться, не разрывая экосистему. Совместимость, управление платформой и сообщество оказались важнее красоты отдельных языковых решений.

Изначально java называлась Oak и ее создавали для бытовых вычислительных устройств. Интерактивное телевидение не взлетело, команда переключилась на веб, а настоящий масштаб Java в итоге нашла на сервере. Уже здесь видна повторяющаяся схема: технология сохраняет ядро, но меняет рынок и задачу вокруг него.

Даже знаменитое мотто write once, run anywhere в фильме постепенно перестаёт быть рекламным лозунгом. Конфликт Sun с Microsoft показан как борьба за то, кто контролирует платформенный контракт. Если реализация Java под Windows становится несовместимой с остальными, переносимость исчезает, а вместе с ней - и сама причина существования платформы. Здесь Microsoft тех лет представлен в виде гиганта, что греб все под себя:)

Но одной защитой совместимости экосистему не построить. Java Community Process формализовал участие компаний и сообщества в развитии спецификаций. Tomcat показал Sun, что открытый код не обязательно ведёт к хаосу. Позже OpenJDK закрепил ещё более важную мысль: платформу можно открыть, не отказываясь от общего контракта.

Здесь история начинает переплетаться с другими фильмами. J2EE пыталась стандартизировать корпоративную разработку сверху, но стала слишком тяжёлой для повседневной работы. Spring и Hibernate ответили снизу: обычные объекты, тестируемость и более прямой контроль над кодом. В фильме это сформулировано довольно жёстко: сообщество открытого кода справилось там, где спецификации и поставщики платформы не услышали разработчиков.

А когда после Java 5 развитие языка замедлилось, сама виртуальная машина Java (JVM) не опустела. Scala, Clojure и Kotlin предложили более современные модели, сохранив библиотеки, инструменты и среду выполнения Java. Это сильная платформенная конструкция: недовольство языком не обязательно означает уход из экосистемы. Иногда новая идея сначала появляется рядом, а затем заставляет основную платформу двигаться.

Полезно сопоставить эту линию и с .NET. В фильме Microsoft сначала выступает угрозой из мира закрытой Windows-платформы. Но позднее C# и .NET сами прошли путь к открытому коду и кроссплатформенности. Получается не простая история «Java против Microsoft», а две разные траектории к одной задаче: как удержать разработчиков, не запирая их в технологическом тупике.

Современная Java продолжает ту же логику. Java 8 добавила лямбды и Stream API, не создавая отдельный «новый Java». Шестимесячный цикл отделил готовность конкретной возможности от большого редкого релиза. А virtual threads в Project Loom меняют внутреннюю механику потоков, сохраняя знакомые API и последовательную модель thread-per-request. Инженерно это красивая часть истории: заменить фундамент дома так, чтобы людям наверху не пришлось учиться ходить заново.

У фильма есть понятная оптика: его поддержали компании Java-экосистемы, а историю в основном рассказывают люди, которые эту платформу создавали. Поэтому я бы смотрел его как коллективную инженерную автобиографию, а не как независимое расследование. Особенно там, где участники оценивают решения Sun, Oracle или влияние отдельных проектов.

Для меня главный вывод такой: зрелая платформа - это не только язык, среда выполнения и API. Это ещё бюджет совместимости, правила принятия решений, инструменты, открытый код, выпуск обновлений и возможность сообщества исправить платформу, когда её владельцы ошибаются. Практически это означает, что архитектору платформы мало проектировать расширяемое ядро. Нужны путь миграции, предсказуемый цикл релизов и место для альтернатив. Java выжила не потому, что всегда выбирала правильно. Она выжила потому, что экосистема снова и снова получала возможность скорректировать курс.

Связанные разборы документалок в System Design Space:
- Spring: The Documentary
- IntelliJ IDEA и линия Kotlin
- C#, TypeScript и эволюция .NET
- Clojure как альтернативная линия JVM

А вот они же но просто в виде фильмов, если вы решите почилить и продолжить после истории Java просмотр остросюжетных документалок про Spring, IntelliJ IDEA, Clojure и Apache Tomcat

#Software #Java #JVM #Architecture #Engineering #OpenSource #History

Материалы про кодинговых агентов и важность экспертизы (Рубрика #AI4SDLC)

Готовы материалы с подкаста Code of Leadership, который был в среду с Евгением Сергеым:
- Презнтация: Слайд дека с разбором
- Видео: Youtube, VK
- Аудио: Podster, Ya Music
- Текст: Краткая расшифровка

#AI4SDLC #Agents #Architecture #Engineering #Software #Books

Алексей Миловидов и ClickHouse: от любопытства до компании в $15 млрд (Рубрика #Software)

С большим интересом посмотрел большое интервью Елизаветы Осетинской (иностранного агента) с Алексеем Миловидовым, создателем и CTO ClickHouse. Формально это история компании с оценкой $15 млрд. Но мне она показалась интереснее как путь инженерного проекта: от любопытства и внутреннего инструмента до open source и глобального бизнеса.

Программировать Алексей начал на советском БК-0010. Игру можно было загрузить с кассеты или вручную набрать десять страниц кода из журнала. Если ошибся, вспоминает он, игра могла работать «чуть-чуть по-другому». Старшие братья в итоге просто выдали ему книгу: «Разбирайся».

Позже он поступил на мехмат МГУ, хотя хотел на ВМК, а затем выбрал «Яндекс» — несмотря на меньшую зарплату. В первый же отпуск руководителя система веб-аналитики, которую поддерживали два человека, перестала справляться с трафиком. Алексей её стабилизировал, а затем захотел отчёты в реальном времени с произвольными разрезами. Так из практической боли начал расти ClickHouse.

Название сложилось из clickstream и data warehouse. Когда аналитики «Яндекса» вместо многочасовых Perl-скриптов получили ответы за секунды, технология выглядела как магия. При этом её долго почти не замечали — и это оказалось преимуществом: команде не мешали спокойно строить систему.

В 2016 году ClickHouse открыли как open source. Алексей называет это способом «проникнуть на рынок, пока никто не видит». Сначала появились пользователи, контрибьюторы и митапы, а уже потом — компания. Бизнес построили вокруг того, чего нет в «голом» движке: масштабирования, резервного копирования, безопасности и интеграций. Самостоятельно можно бесплатно; тем, кто не хочет содержать отдельную экспертизу, продают ClickHouse Cloud.

Сам стартап тоже собирался необычно. В 2021 году 12–14 человек переходили из «Яндекса», а трое кофаундеров знали друг друга только по Zoom — онлайн-дейтинг, шутит Осетинская. В компанию уже вложили $50 млн, хотя облачного продукта ещё не было, а у нанятой sales-команды оставался вопрос: «Да что продаём-то?»

Роли разделили прагматично: Аарон Кац — бизнес и продажи, Юрий Израилевский — облако и команды, Миловидов — технология. Алексей не стал CEO: без опыта шанс убедить нужных людей он оценивал примерно в 5%. Сейчас в компании больше 600 сотрудников, но формально он не руководит никем, работает со всеми и соглашается с ролью «создателя тревоги».

В истории много таких деталей. Квартиру в Амстердаме Алексею сдала хозяйка, чья сестра знала ClickHouse по Китаю. За четыре с половиной года он выучил по-нидерландски главным образом goedemorgen. А AI-сотрудник Groene AI чинит «красные» тесты и уже подружился с особенно угрюмым контрибьютором.

Если сокращать, то получаются два основных момента
- ClickHouse вырос не из гениального питча, а из цепочки хорошо решённых инженерных проблем (а я помню как лет 10 назад ClickHouse захватывал рынок аналитических решений в России, так как других решений такого класса в opensource не было)
- Но одной технологии было мало, ее создателю пришлось увидеть продукт глазами клиентов, доверить продажи и компанию людям с другим опытом и продолжать строить крутой продукт

#Software #Data #OpenSource #Engineering #Architecture #Management

Бенуа Шиллингс: R&D после кода (Рубрика #AI4SDLC)

Посмотрел keynote доклад Бенуа Шиллингса, VP из Google DeepMind на AI Engineer World’s Fair 2026. Его позиция мне интересна - он не лидер продуктового ИТ, внедряющий агента в SDLC, а руководитель R&D. Его команда создаёт технологии, которые понадобятся Gemini на горизонте от месяца до года. Поэтому вместо backlog, CI/CD и SLO он обсуждает, чему должна научиться следующая модель.

У истории забавное начало. В 2018 году его команда в X запустила проект Pitchfork про применение ML к коду, но идею почти никто не воспринимал всерьёз. Сам Шиллингс отвергал программирование на естественном языке: для этого уже есть языки программирования. Теперь человек с 45-летним опытом - от ассемблера до Python - признаёт ошибку и использует vibe coding.

Главный тезис: генерация кода и software engineering - это разные задачи. По мнению Шиллингса, модели уже генерируют синтаксис лучше человека. Но настоящая разработка начинается, когда нужно изменить систему с 35 миллионами строк PHP, учесть архитектуру, безопасность и последствия решения через десять лет. Узкое место переезжает в постановку задачи, декомпозицию и проверку замысла.

Код для DeepMind - это удобная R&D-лаборатория: данных много, результат проверяется компилятором и тестами. Следующий шаг - self-play, где модель сама создаёт задачи, решает и проверяет их, как AlphaZero учился через игру с собой. Ограничением становятся compute и качество среды обучения.

Исследовательский roadmap из доклада выглядит так:

- Учить модель писать безопасный код сразу, а не только находить уязвимости постфактум;
- Развивать планирование, декомпозицию и перенос идей между областями;
- Менять evals: проверка «запустилось и выдало ответ» слишком узка для архитектуры;
- Выходить за линейную цепочку токенов к мультимодальным представлениям;
- Возможно, создавать строгие языки для моделей, даже если человеку их будет неудобно читать.

Последний пункт особенно хорошо показывает R&D-оптику: снять ограничение читаемости кода человеком и переложить доказательство корректности на модель и язык.

Шиллингс прогнозирует, что код станет почти бесплатным, его объём взорвётся, а через год люди почти перестанут читать результат агента - как сегодня редко проверяют ассемблер после компилятора. Это прогноз, не факт и есть определенная разница между агентом и компилятором - последний работает по строгой спецификации, а агент - в неоднозначном бизнес-контексте.

За рамками остаются legacy, ownership, SLO, стоимость inference и rollout. Зато финал уходит в химию и биологию: для Шиллингса coding models - полигон для общего reasoning и научных открытий.

Мне это выступление понравилось - это не инструкция по внедрению AI в ИТ (с этим у меня проблем нет), а скорее карта upstream-исследований. Условно
- R&D спрашивает: «Что модель сможет открыть и построить?»
- Продуктовое ИТ добавляет: «Как доказать, что результат нужен, безопасен и управляем?»

#AI #AI4SDLC #Research #Engineering #Architecture #Evals

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

Сегодня в 17:00 МСК будем разбирать эти идеи на стриме с Мишей Трифоновым: что выбрать для пилота, корпоративной платформы и регулируемого контура.

#AI4SDLC #Agents #Architecture #PlatformEngineering