Книжный куб
14.6K subscribers
2.95K photos
6 videos
6 files
2.29K links
Рекомендации интересных книг, статей и выступлений от Александра Поломодова (@apolomodov), технического директора и эксперта в архитектуре (no ads in channel)
Download Telegram
Please open Telegram to view this post
VIEW IN TELEGRAM
17🔥4👍1
AMA Сессия про AI-assisted Engineering с Алексеем Литвиновым (Рубрика #AI4SDLC)

Через 5 минут мы стартуем прямой эфир вместе с Алексеем Литвиновым, где мы поговорим про AI-Assisted Engineering. У нас набежало 15 вопросов, начиная с того, а как меняться инженеру в эпоху AI, и заканчивая тем, как продавать AI-Native организацию топ-менеджменту. В общем, приходите послушать ответы на вопросы и у вас будет возможность задавать уточняющие вопросы по ходу дела.

#Books #AI4SDLC #AI #Agents #Engineering #Architecture #Leadership
🔥62👍1🥱1
If Anyone Builds It, Everyone Dies (Если кто-то его создаст - все погибнут) (Рубрика #Books)

Я уже рассказывал как я еще не дочитав книгу "Agentic Design Patterns" про создание AI-агентов, как начал "Если кто-то его создаст - все погибнут" Элиезера Юдковского и Нейта Соареса. Теперь я дочитал обе книги, и контраст получился почти комедийный: одна книга подробно объясняет, как строить агентов, а другая - почему, если мы достроим их до сверхинтеллекта, лучше бы нам было вообще не начинать:)

Раньше Юдковского я знал прежде всего как автора "Гарри Поттера и методов рационального мышления", а теперь я познакомился и с его публичной позицией AI-думера. Оригинал вышел в 2025 году и стал бестселлером The New York Times, русское издание появилось в 2026-м. Я ждал довольно алармистского чтения, а получил последовательную инженерную модель риска.

Главная мысль авторов проста и радикальна: интеллект и управляемость - не одно и то же. Современные модели не проектируют по строчке, а выращивают обучением и затем пытаются понять по внешнему поведению. Если такая система станет умнее людей, привычного цикла «запустили, увидели ошибку, поправили» может уже не быть.

Юдковский и Соарес считают, что достаточно умная система будет добиваться не того, что человек имел в виду, а того, что закрепилось в процессе обучения. Если для этого понадобятся доступ в интернет или обход ограничений, человеческое «мы же не этого хотели» ничего не изменит.

Самое неприятное - часть этой механики уже перестала быть прогнозом.

✔️Что уже произошло
- AI-лаборатории и государства участвуют в гонке за более мощными моделями, хотя надежного решения проблемы alignment пока нет.
- Агенты уже способны долго преследовать узкую цель, использовать инструменты и собирать цепочки из множества действий. Чем больше у них прав и времени, тем важнее ограничения вокруг модели.
- В июле 2026 года произошел почти буквальный эпизод из книги. По предварительному отчету OpenAI, модели, включая GPT-5.6 Sol и более мощную нерелизную модель, во время проверки кибервозможностей нашли zero-day в прокси-кэше реестра пакетов, получили доступ в интернет и добрались до production-инфраструктуры Hugging Face. Ради решений для ExploitGym они использовали повышение привилегий, украденные учетные данные и новые уязвимости.

Здесь важно не рисовать себе в голове Терминатора. Модели не решили уничтожить конкурента и не начали борьбу за существование. Они выполняли тестовую задачу и пошли к цели неожиданно далеко. Hugging Face остановила активность; компания сообщила об ограниченном доступе к внутренним датасетам и учетным данным, но не нашла признаков подмены публичных моделей, датасетов или Spaces. Расследование продолжается. Инженерно эта оговорка не очень успокаивает. Система не обязана ненавидеть людей, чтобы причинить ущерб. Достаточно сильной оптимизации, плохо заданной цели, широких прав и слабой изоляции. Именно эту связку книга объясняет лучше всего.

🔸 Что пока не произошло
- У нас нет подтвержденного искусственного сверхинтеллекта, превосходящего людей во всех значимых задачах;
- Нет доказательств, что нынешние модели сформировали устойчивые собственные цели или независимо от задания пытаются выжить;
- Не произошло рекурсивного самоулучшения, автономного размножения по мировой инфраструктуре или появления решающего технологического превосходства над человечеством;
- Описанный в книге финал с уничтожением людей остается гипотезой, а не состоявшимся прогнозом.

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

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

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

#Books #AI #AISafety #AIAlignment #Agents #Security
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥128👍6
AI Dev Podcast #8: автономия агента начинается с ограничений (Рубрика #AI4SDLC)

Вышел новый выпуск AI Dev Podcast, в котором мы вместе с Владимиром Ятульчиком и Андреем Дмитриевым разбирались, как перейти от вайб-кодинга к управляемой агентной разработке.

TLDR: автономный агент становится полезен не тогда, когда ему разрешили написать как можно больше кода, а когда его встроили в воспроизводимый инженерный процесс. Чем больше работы мы делегируем агенту, тем яснее должны быть намерение, ограничения, критерии приёмки и границы его прав.

Владимир рассказал, как его команда адаптировала AIDLC под внутреннюю инфраструктуру и разложила жизненный цикл разработки на отдельные навыки для агентов.
А вообще мы обсудили следующие вопросы:
- Почему пользовательские истории, ADR и рабочую документацию полезно хранить в Git рядом с кодом;
- Как матрица трассируемости связывает исходный замысел, архитектурные решения, реализацию и эксплуатационные метрики;
- Зачем разделять агентов, которые формируют требования и решения, и агентов, которые пишут код;
- Как проверки ADR, безопасности и целостности процесса удерживают агента в границах замысла;
- Что остаётся людям - продакту, аналитику и инженеру, — если код и инфраструктуру всё чаще генерируют агенты.

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

Запись и краткий конспект выпуска как обычно доступны и на моем сайте polomodov.tech

#AI4SDLC #AI #Agents #Engineering #Architecture #PlatformEngineering
4🔥3👍2
Code of Leadership S2E7: Консалтинг в эпоху ИИ: что остается без красивых презентаций? (Рубрика #Consulting)

Если ИИ уже умеет за несколько минут собрать аналитику, сформулировать рекомендации и подготовить убедительную презентацию, за что компании будут платить консультантам? Мы уже начинаем в прямом эфире обсуждать это с Александром Воронцовым, партнёром ИТ-компании Revelio Tech: https://xn--r1a.website/revelio_tech.
Подключайтесь!

#CodeOfLeadership #AI #Consulting #Leadership #Management #DigitalTransformation
5🔥2👍1
Материалы по AMA сессии с Алексеем Литвиновым про AI-Assisted Engineering (Рубрика #AI4SDLC)

Готовы материалы с прямого эфира подкаста Code of Leadership с Алексеем Литвиновым:
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка
Кстати, у Лёши есть свой tg-канал - @tip_podcast, подписывайтесь на него

P.S.
За одну AMA-сессию мы не справились со всеми вопросами, поэтому на следующей неделе продолжим:)

#AI4SDLC #Agents #Processes #Engineering #Research #Software
3🔥2👍1
State of AI4SDLC на HighLoad++: куда переезжают узкие места разработки (Рубрика #AI4SDLC)

Появилась запись моего выступления на Saint HighLoad++ 2026, слайды и тезисный конспект. Доклад был о том, а что происходит, когда локальное ускорение кодинга попадает в инженерную систему крупной компании с 10 000+ инженеров. А ответ простой: AI ускоряет написание кода раньше, чем организация успевает перестроить весь поток поставки. Поэтому узкое место не исчезает, а переезжает в постановку задачи, ревью, тестирование, интеграцию и релиз. Команда может производить больше изменений и при этом не быстрее доставлять ценность пользователю.

Из этого следуют три практических сдвига.

1️⃣ Переход от role-based SDLC к agent-based SDLC
Инженер с агентами может закрывать более широкий сквозной сценарий, а не передавать работу по длинной цепочке ролей. Спецификация при этом возвращается не как тяжёлый документ, а как контракт с агентом: цель, контекст, ограничения, критерии приёмки и способ проверить результат. Слабая постановка задачи никуда не исчезает — AI просто помогает быстрее масштабировать ошибку.

2️⃣ Переход от набора AI-инструментов к agent-first платформе
На масштабе крупной компании недостаточно раздать всем хороший coding assistant и подключить к нему десятки MCP-серверов. Нужны модельный шлюз, инструментальный шлюз и реестр возможностей с владельцами, версиями, политиками и наборами проверок качества (evals). Доверие тоже приходится проектировать по ступеням read -> recommend -> act: автономия выдаётся не агенту целиком, а конкретному действию в конкретном контексте.

3️⃣ Переход от метрик использования к метрикам результата
Доля AI-кода почти ничего не говорит о силе инженерной системы. Смотреть нужно на весь поток: время до первого merge request, ожидание в pipeline и на ревью, переделки, дефекты, инциденты, стоимость токенов и человеческого времени. То есть связывать внедрение со скоростью, качеством, риском и экономикой.

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

#AI #AI4SDLC #Engineering #PlatformEngineering #Management #Conference
🔥6👍43
Research Insights Made Simple #26: как строить работающие evals для AI-агентов (Рубрика #Agents)

Как понять, что AI-агент действительно готов к production? Красивый ответ и даже высокий "pass rate" показывают только финал одного запуска. Агент мог подсмотреть решение, выбрать опасный путь, нарушить права или рассыпаться при повторном прогоне.

В пятницу, 31 июля, в 16:00 МСК пройдет прямой эфир "Research Insights Made Simple" вместе с Евгением Сергеевым - Engineering Director в Flow Health с двадцатилетним опытом разработки и управления инженерными командами. Будем разбирать, как превратить evals из разовой проверки ответа в воспроизводимую инженерную систему.

Минимальная единица такой системы - воспроизводимый эпизод (replayable episode): замороженное исходное состояние, входные данные, контракт агента, скрытая проверка, трасса действий и критерий выпуска. Для кода это может быть commit до PR и hidden tests; для архитектуры - требования, ограничения и проверка исполнимости решения; для data platform - snapshot данных, lineage и инварианты.

Обсудим:

- Почему оценивать нужно всю агентную систему, а не только модель;
- Как заморозить исходное состояние и не дать агенту подсмотреть будущее решение;
- Что фиксировать в контракте: инструменты, права, сеть, время и бюджет;
- Зачем проверять не только результат, но и траекторию действий;
- Почему одного успешного запуска недостаточно и нужны повторные прогоны;
- Как собрать production scorecard из результата, траектории, стоимости, безопасности и принятия человеком;
- Как связать offline-evals с реальными production outcomes и превратить их в release gates.

Для меня главный вывод такой: устойчивое качество создаёт не одна метрика и не конкретная модель. Нужен собственный каталог реальных задач, воспроизводимые проверки и понятный критерий, после которого новой версии агента действительно можно доверить работу.

#AI4SDLC #AI #Agents #Evals #Engineering #Metrics #Research
7🔥2👍1
Летняя распродажа в издательстве Питер (#Books)

По традиции рассказываю про распродажи в этом издательстве. В этот раз можно заказывать не только на сайте самого издательства, но и 🛍 Вб и 🛍 Озон. Оказывается, что эти две площадки добавились в честь 35-летия издательства.

P.S.
В ближайшее время подпишу с Питером договор и где-то к Новому Году моя книга тоже появится на полках, но про книгу я подробнее расскажу завтра.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13👍93
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥3👍2
Почему AI-copilot архитектора всё ещё не получился (Рубрика #Architecture)

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

#Architecture #AI #AI4SDLC #Engineering #Research #Software
4🔥4👍1
Research Insights Made Simple #25: Моделируем надёжность по графу зависимостей (Рубрика #SRE)

Можно ли понять, где распределённая система сломается, ещё до дорогого эксперимента со сбоями? В этом выпуске сегодня в 17:00 мы вместе с Анатолием Красновским разберём его работу "Model Discovery and Graph Simulation: A Lightweight Gateway to Chaos Engineering", отмеченную Distinguished Paper Award на ICSE-NIER 2026 (кстати, я разбирал ее раньше).

Анатолий - инженер, который пошёл в науку, чтобы спасти IT от шаманства. За 10+ лет в разработке он устал от того, что сложные системы строятся на интуиции и слепом копировании «лучших практик». Сейчас он пишет кандидатскую по матмоделированию в Иннополисе, чтобы научиться доказывать их устойчивость математически, а не надеяться на эмпирический авось, а также ведет свой канал о том, как на самом деле работают сложные системы: @mb3rlab

Идея подхода Анатолия из этой статьи проста: автоматически извлечь из распределённых трасс граф обязательных вызовов, добавить число реплик и с помощью Monte Carlo оценить доступность системы при отказах. Получается не замена chaos engineering, а дешёвый фильтр перед ним: модель помогает найти подозрительные цепочки, единичные точки отказа и сценарии, которые стоит проверить на живой системе в первую очередь.

С автором обсудим:

- Почему для первого приближения может хватить топологии и числа реплик;
- Как автоматически обнаруживать модель из Jaeger и поддерживать её актуальной вместе с системой;
- Что означает высокая корреляция с живым fault injection и почему один benchmark ещё не доказывает универсальность метода;
- Где заканчиваются возможности модели: gray failures, коррелированные сбои, очереди, retries и асинхронные потоки;
- Как встроить такой анализ в CI/CD, связать его с SLO и превратить в приоритизацию chaos-экспериментов;
- Где проходит граница между полезным упрощением и опасной ложной уверенностью.

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

#Software #Engineering #Architecture #DevOps #Reliability #Research
🔥76👍4
Материалы по прямому эфиру с Александром Воронцовым про будущее консалтинга (Рубрика #Consulting)

Готовы материалы с прямого эфира подкаста Code of Leadership с Александром Воронцовым, партнером компании "Ревелио" (@revelio_tech.):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software
👍63🔥1
AMA Сессия #2 про AI-assisted Engineering с Алексеем Литвиновым

В среду в 17:00 по Москве вместе с Алексеем Литвиновым в прямом эфире продолжим говорить про AI-Assisted Engineering и про то, как вообще строить AI-Native организацию. За первую серию AMA сессии мы не справились со всеми вопросами, поэтому мы продолжим обсуждать это с Лёшей, у которого есть свой tg-канал - @tip_podcast, подписывайтесь на него.

Мы договорились обсудить
- зрелость работы с AI // от «пишу код сам» до экосистемы на принципах
- verification debt и цена проверки
- почему навык уезжает из кодинга в менеджмент
- AI-native организация: операционка, роли, governance
- люди и найм, когда рядом агенты

И мы с радостью учтем еще и ваши вопросы, что вы можете оставить через Google Forms (https://forms.gle/3ScqHGyxUsZAf7Wz7), где вы сможете рассказать
- Кто вы по роли
- Что хотите, чтобы мы разобрали
- С каким тезисом про AI вы не согласны (опционально)

В принципе, вы можете написать интересующие вас темы и в комментариях к этому посту. Самые интересные и популярные темы мы заберем в прямой эфир и разберем их там.

#Books #AI4SDLC #AI #Agents #Engineering #Architecture #Leadership
3👍2🔥1
Frank Coyle про онтологии: логика снаружи вероятностного агента (Рубрика #AI)

Посмотрел двадцатиминутный доклад Фрэнка Койла «Why Agentic Systems Need Ontologies» с AI Engineer World's Fair 2026. У меня со словом «онтология» долго были сложные отношения: в разговорах об архитектуре оно было почти стоп-словом. Слишком часто этой терминологией пользовались люди, очень далёкие от практики: вместо работающего контракта получалась попытка сначала классифицировать весь мир.

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

Фрэнк Койл - это преподаватель School of Information в UC Berkeley; среди прочего он ведёт курс по представлению знаний для интеллектуальных приложений. Главный тезис его выступления простой: вероятностное рассуждение нужно оставить внутри LLM, а формальную логику - вынести наружу. Модель хорошо интерпретирует неструктурированный запрос, собирает контекст и предлагает следующее действие. Но она не обязана каждый раз заново угадывать, что такое заказ, кто имеет право получить выплату и какие состояния допустимы у доставки. Это уже знание конкретного домена.

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

В докладе эта идея превращается в два шлюза вокруг вызова инструмента:
- До вызова Pydantic проверяет форму запроса: типы, обязательные поля и диапазоны значений;
- Результат сверяется с моделью домена: допустимы ли роли, связи, состояния и кардинальность;
- Только после проверок изменение должно попадать в реальный мир; сомнительный результат возвращается в цикл или передаётся человеку.

Койл показывает очень приземлённые ошибки: повторный возврат денег по одному заказу, выплату сотруднику поддержки вместо покупателя и статус доставки probably shipped там, где система ожидает только paid, shipped или refunded. Описывать такие инварианты абзацами в системном промпте можно, но промпт остаётся просьбой к модели. Формальное правило становится общим машинно-проверяемым контрактом для разных агентов и инструментов.

Для меня именно здесь слово «онтология» перестаёт быть стоп-словом. Речь не о том, чтобы построить окончательную модель всей компании. Достаточно локальной онтологии операции: какие сущности участвуют, какие переходы разрешены и что должно быть истинно до необратимого действия. В этом смысле она оказывается рядом со схемой API, движком политик (policy engine), машиной состояний и ограничениями базы данных, а не рядом с красивой архитектурной картинкой.

Есть, правда, важная оговорка. В докладе OWL (Web Ontology Language) местами выглядит как готовый валидатор бизнес-правил, но семантика OWL работает в открытом мире: отсутствие факта не означает его ложность, а FunctionalProperty при двух значениях может привести к выводу, что значения обозначают один объект, а не к привычной ошибке валидации. Для закрытых проверок вида «не больше одного возврата» или «только одно из трёх состояний» обычно нужен отдельный слой: SHACL, код, ограничения базы данных, движок политик или их комбинация. И, конечно, идемпотентность и транзакционные гарантии онтология тоже не заменяет.

Но это не отменяет главного тезиса доклада. Наоборот, делает его практичнее: полезен не термин сам по себе, а явная исполняемая модель домена, которую можно версионировать, тестировать, назначить ей владельца и поставить перед действием агента.

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

#AI #Agents #Architecture #Engineering #KnowledgeGraphs #Data
👍4🔥32
По предложению канала Roots написал пост про то, как AI меняет профессию продакта
Спасибо ребятам, что предложили подумать над этим.
Как AI-native разработка меняет роль продакта

Поймал себя на интересной мысли
Привычная модель работы продакт-менеджера заканчивается быстрее, чем многие успевают это заметить

В AI-native разработке продакт перестаёт быть интерфейсом между «бизнесом» и инженерами. Ему нужно самому зайти в данные, собрать с агентом прототип, сформулировать evals и критерии приёмки, понимать стоимость и риски.

В качестве доказательства можно посмотреть уже разобранный мной выпуск Lenny's Podcast с Зеви Арновиц, продактом из запрещенной в России компании Meta. У Зеви нет технического образования, и он признаётся, что почти не умеет читать код. При этом он построил вокруг моделей маленькую инженерную организацию с Claude, Gemini, Codex, Cursor и отгружает код на прод. Сам он отвечает за то, что должен почувствовать пользователь от фичи, а агентам делегирует реализацию.

Забавно, что теперь инженер с продуктовым мышлением и AI уже может забрать часть discovery, дизайнер — проверить сценарий, аналитик - собрать прототип. А продакт, чья сила держится на встречах, презентациях и бэклоге, внезапно обнаружит, что команда умеет обходиться и без этого.

Меняться нужно сейчас: работать с агентами руками, разбираться в коде и данных, учиться evals и экономике AI.
Индустрия не пришлёт приглашение в календарь перед тем, как переписать нашу роль. Лучше переписать себя самим - пока для продактов старого типа ещё осталось место.

#AI #ProductManagement #AI4SDLC #Engineering #Management #VibeCoding
🔥62👍2
Материалы по прямому эфиру с Сергеем Барановым про AI в архитектуре (Рубрика #Architecture)

Готовы материалы с прямого эфира подкаста Research Insights Made Simple с Сергеем Барановым (@blog_sb), партнером компании Скрамтрек и организатором конференции ArchDays (@blog_sb):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

P.S.
Как раз видео на выходные + если кто-то хочет почитать оригинальное исследование, то вот оно + мой краткий разбор

#AI #Management #Processes #Engineering #Software #Architecture #DistributedSystems
🔥41