AI PDLC Inside

Оркестратор для агентов: от отдельных сессий — к единому процессу

Кодинг-агенты уже пишут код, тесты, готовят пул-реквесты. Но между этапами разработки процесс по-прежнему держится на человеке. Рассказали в статье на Хабре, как попробовали устранить этот разрыв с помощью оркестратора Human Guided SDLC.

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

В AI-Disrupt PDLC представлен термин Zero Friction — максимально бесшовный процесс разработки. Устранение ручной пересборки задачи для агента — один из шагов в эту сторону.

Как это устроено
Оркестратор HG SDLC — система для запуска управляемого процесса «поверх» кодинг-агента. По аналогии с BPM-движком: процесс представлен как версионированный граф с этапами, переходами, проверками и циклами возврата.

Узлы графа:
• AI Node — запускает агента с инструкцией и контекстом
• Command Node — выполняет shell-команды: сборку, тесты, линтеры
• Human Input Gate — запрашивает данные или выбор
• Human Approval Gate — показывает результат для акцепта или возврата
• Terminal — завершает маршрут

Что важно
Переход к связанному AI-процессу начинается не с установки оркестратора, а с освоения подхода Specification-Driven Development (SDD) — разработки через спецификации. Cпецификация становится «рабочим контрактом»: по нему агент выполняет изменения и предъявляет результат на проверку.

Главная ценность HG SDLC — единая история работы над задачей: версия сценария, результаты, точки доработки, решения человека. Это позволяет разбирать запуски и находить зоны роста.

👉 HG SDLC — открытый проект на GitVerse. Можно попробовать в своей команде: начать с одного класса задач, настроить проверки и точки участия человека.

🔗 Читать статью полностью

#Практика

Готовы ли вы к агентной разработке: модель зрелости AI PDLC

Мы уже познакомили вас с AI-Disrupt PDLC — концепцией, которая описывает, как выстроить процесс создания продуктов вокруг ИИ. Но прежде, чем начинать трансформацию, важно понять, готова ли к ней компания. Разобраться в этом поможет модель ИИ-зрелости от Сбера.

Что это такое
Это шкала, которая помогает оценить, насколько процессы компании готовы к внедрению агентов. Она показывает, где компания находится сейчас и как ей достичь своих стратегических целей.

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

Зачем это нужно
Если внедрять ИИ точечно и не менять процессы, ускоряются отдельные этапы — но не создание продукта в целом. Код пишется быстрее, но ревью, тестирование и релиз за ним не поспевают. Накапливается техдолг и уязвимости, а продукт выходит на рынок не раньше, чем прежде.

Модель зрелости AI PDLC дает честную картину: что уже работает, где есть пробелы, что улучшить. Это инструмент для управленческих решений — помогает понять, куда направить инвестиции и что принесет реальный результат.

С чего начать
Пройдите бесплатную экспресс-оценку на сайте за 20 минут. Это поможет определить ваш уровень ИИ-зрелости, точки роста компании и базовые рекомендации по развитию.

👉 Скачать руководство по оценке зрелости

#ИИнструменты

AI-Disrupt PDLC: как построить разработку вокруг ИИ

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

В мае 2026 Сбер выпустил открытое руководство AI-Disrupt PDLC — концепцию, которая описывает, как выстроить процесс создания продуктов вокруг искусственного интеллекта.

Что такое AI-Disrupt PDLC

Это стратегия ИИ-трансформации разработки и бизнеса в новой технологической реальности. Руководство объясняет:
· как меняется архитектура, процессы и роли в компании,
· почему ключевым активом становится не модель, а среда ее использования,
· как перейти к ИИ-нативной разработке и сохранить безопасность и масштабируемость.

Ключевые принципы

→ Среда важнее модели. Модели меняются постоянно, а среда накапливает знания о компании и остается долгосрочным активом.
→ Двухпетлевой цикл. Человек определяет намерение, проводит исследования, ставит задачу и валидирует результат. ИИ-агенты занимаются исполнением и генерацией кода.
→ Разработка через спецификации. Человек формулирует бизнес-требования в виде спецификации, а агенты их реализуют — от кода до внедрения.
→ Контроль встроен в процесс. Проверки и ограничения сопровождают все действия агента.

Почему это важно

К 2028 году кодирование вручную сократится вдвое. К 2030-му ключевым фактором станет не работа с ИИ, а зрелая ИИ-культура — управление агентами и баланс автономии с человеческим контролем.

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

👉 Полную версию руководства читайте по ссылке

А в следующих постах расскажем, как AI-Disrupt PDLC помогает повышать производительность и быстрее запускать продукты.

#AI-стандарт

Несем вам большой дайджест статей про ИИ. Сегодня в подборке — четырнадцать прикладных материалов: от развертывания приватных LLM на VPS и в Kubernetes до ручного строительства RAG, обучения стилевых LoRA и создания агентов на LangGraph.

▪️ AI-контур на VPS: LiteLLM, OmniRoute, Codex/Claude Code
Полный путь от голого VPS до собственного LLM-шлюза с доменом. Блог хостера, но шаги переносимы.

▪️ Приватная LLM и RAG в Managed Kubernetes
AIBrix + vLLM + Qdrant + n8n манифестами, инфраструктурный уровень.

▪️ Ollama + OpenClaw на серверном GPU
 Локальный агент в своём контуре, systemd и разбор конфига.

▪️ Qwen3.8-27B на RTX 3090 под Windows
Сборка llama.cpp из исходников, нумерованные шаги.

▪️ Deep Agents на LangGraph  
От минимального агента до навыков, HITL и middleware.

▪️ Строим RAG вручную
Chunking, retrieval, rerank, generation с кодом без фреймворков.

▪️ Честный RAG eval set
Cхема кейса, runner, как собрать 120 кейсов; закрывает то, что в п.6 не измеряется.

▪️ Персональная wiki без Claude Code
Агент аннотирования плюс сборщик, два репозитория.

▪️ Стилевая LoRA для SD 1.5 на 30 картинках
Датасет, OneTrainer, ComfyUI, готовая модель.

▪️ Скилл для ИИ-агента: от пожелания к правилу
Структура скилла с валидатором.

▪️ От капстоуна к продакшену
Fail-fast, structlog, Prometheus, ONNX вместо torch; дешёвый чек-лист для любого LLM-сервиса.

▪️ 73 замечания начальника как датасет
Извлечение комментариев из docx и кластеризация, маленький, но целый пайплайн.

▪️ Крестики-нолики с подкреплением
TD и Monte Carlo руками, репозиторий.

▪️ Семантический индекс для Obsidian без векторной БД
Частичный гайд, но устройство локального индекса разобрано целиком.

Читайте, сохраняйте полезное и делитесь с коллегами!
#tech_inside

🚀 Обновляем концепцию: встречайте AI PDLC Inside!

Друзья, вы могли заметить, что мы всё чаще говорим об ИИ-нативной разработке — как перестроить весь цикл создания ПО вокруг искусственного интеллекта.

Сегодня встраивать ИИ в отдельные процессы уже недостаточно. Мы хотим помочь компаниям перейти от экспериментов к промышленному внедрению. Поэтому AI Inside становится AI PDLC Inside — каналом о новом стандарте, где ИИ встроен в каждый этап создания продуктов.

Здесь мы будем показывать агентную разработку на промышленном масштабе — с цифрами, метриками и кейсами. Разберем, как трансформируются процессы, роли и среда в эпоху ИИ.

Что вас ждет

✔️ Концепции и принципы ИИ-нативной разработки
✔️ Архитектурные решения и живые кейсы
✔️ Разбор изменений в командах и процессах
✔️ Метрики и инструменты, которые работают в реальных проектах

Что останется неизменным

Наша экспертиза, честные обзоры и практическая польза. Мы по-прежнему говорим о том, что помогает понять рынок и внедрить ИИ в процесс создания ПО.

🤝 Оставайтесь с нами — будем разбираться в тонкостях нового стандарта вместе. Добро пожаловать на новый этап канала!

Отрасль спорит о качестве моделей, а агенты падают на исполнении

Отраслевая дискуссия вокруг ИИ-агентов сосредоточена на качестве рассуждений: какая модель лучше планирует, где меньше галлюцинаций, чей reasoning глубже.

Практика промышленных внедрений смещает фокус в другую сторону. 

Значительная часть отказов агентных систем в продакшене приходится не на модель, а на исполнение.

Чат-бот отвечает на вопрос, агент выполняет работу

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

Схема «запрос пользователя, API агента, вызов LLM, ответ» закрывает вопросы-ответы, суммаризацию, поиск и базовый tool calling. Реальный сценарий выглядит иначе:
▪️ агент поддержки анализирует логи,
▪️ ищет по базе знаний,
▪️ поднимает похожие исторические инциденты,
▪️ проверяет политику эскалации,
▪️ ждет review инженера
▪️ и только потом формирует рекомендацию.

Такой процесс занимает минуты, часы или дни. Это уже не диалог, а долгоживущий бизнес-процесс с ИИ внутри.

Неудобные инженерные вопросы

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

Ответ «обработаем в коде агента» означает, что архитектура уже в состоянии долга.

Типичные сценарии отказа

1️⃣ состояние workflow хранилось только в памяти;
2️⃣ сессия фронтенда исчезла;
3️⃣ бэкенд-запрос превысил таймаут;
4️⃣ транзиентная ошибка внешнего API перезапустила процесс с нуля
5️⃣ шаг человеческого согласования жил вне workflow;
6️⃣ механизма возобновления с последнего завершенного шага не существовало;
7️⃣ повторная попытка неидемпотентной операции создала дублирующую работу.

Во всех этих случаях модель отработала корректно. Отказал рантайм.

Проблемы не новые, новые — те, кто строит

Стоит отметить, что ни один из перечисленных режимов отказа не является новым. Durable-execution рантаймы решили задачу persist-and-resume годы назад, чекпоинтинг старше их, а ключи идемпотентности лежат в фундаменте платежной индустрии.

Изменился не набор проблем, а состав тех, кто строит системы.

Команды, которые сегодня выкатывают агентов, в массе своей не застали эпоху workflow-движков, поэтому дисциплина осваивается заново.

Сдвиг в проектировании

Практический сдвиг в проектировании формулируется одной фразой: приложением является workflow, модель является одной активностью внутри него.

Из этого следует конкретный список требований, который не имеет отношения к промпт-инжинирингу:
• устойчивое состояние
• явные политики retry
• трекинг прогресса
• correlation ID
• чекпоинты человеческого согласования
• обработка частичных отказов
• возобновление по внешним событиям
• аудируемость
• версионирование workflow

Деструктивный тест

Проверить, работает ли это, архитектурной диаграммой невозможно. Единственный надежный тест — деструктивный:

▪️ убить процесс в произвольной точке, желательно неудобной.
▪️ обнулить все состояние в памяти и в контексте,
▪️ поднять систему и посмотреть на поведение.

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

Вывод

Следующий этап корпоративного ИИ определится не размером модели и не качеством промптов, а архитектурой исполнения.

#tech_inside

Кейс Klarna: как 700 агентов поддержки стали городской легендой, которую не проверили

Кейс Klarna стал стандартной иллюстрацией провальной замены людей на ИИ. При проверке первоисточников выясняется, что большинство деталей, которые обычно приводят вместе с этим кейсом, в них отсутствуют.

Что было опубликовано на самом деле

В феврале 2024 года Klarna заявила
, что ее AI-ассистент выполняет объем работы, эквивалентный 700 агентам поддержки. За первый месяц он закрыл 2,3 млн диалогов, около 75% всех обращений, на 35 языках.

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

Как на самом деле сокращался штат

Штат при этом действительно сокращался, но по другому механизму.

Найм был заморожен в конце 2023 года, за последующий год численность упала на 22% до 3 500 человек, и, по словам самого CEO, преимущественно за счет естественного оттока. Это заморозка найма, а не замещение конкретных людей конкретной системой.

Почему вернули операторов

В мае 2025 года Себастиан Семятковский разворачивает стратегию и возвращает наем операторов. Публичная формулировка причины у него ровно одна:

ИИ обходился дешевле, но качество получалось ниже.

Ни метрик по жалобам, ни данных по CSAT, ни статистики по доле нерешённых обращений компания не приводила.

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

Деталь, которая обычно теряется

Еще в феврале 2024 года независимое тестирование бота, проведённое Гергеем Орошем, показало, что система выдавала точные ответы из документации и быстро передавала диалог живому оператору. То есть уже на старте она работала скорее фильтром на входе, чем полной заменой первой линии.

Цепочка искажения

Теперь — как выглядит цепочка искажения:

➡ Исходная формулировка: работа, эквивалентная 700 агентам;
1️⃣ Первый пересказ: заменили 700 сотрудников;
2️⃣ Второй: уволили 700 человек;
3️⃣ Третий: количество жалоб резко выросло, поэтому людей вернули

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

Почему цифра выжила

Цифра выжила потому, что оказалась удобна обеим сторонам спора:

1️⃣ сначала как доказательство того, что ИИ заменяет людей в промышленном масштабе.

2️⃣ через год как доказательство того, что не заменяет
Один и тот же непроверенный показатель обслужил два противоположных нарратива.

Практическое следствие

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

Реальный урок

Реальный урок формулируется иначе.

Компания опубликовала метрику производительности до того, как у нее появилась метрика качества. Экономия на обращение измерялась, деградация качества не измерялась.

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

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

#кейс

ГигаКонф-2026: два дня, один цикл ИИ-трансформации

Как сделать ИИ не просто инструментом, а управляемой частью компании? Обсудим на технологической конференции ГигаКонф-2026. Она пройдет в два дня, разделенных по аудиториям, но связанных одной логикой: от стратегии ИИ к работающему продукту.

🤝 23 сентября — день для бизнеса
Топ-менеджеры и архитекторы ИИ-трансформаций обсудят, как компаниям стать AI-native. Разберут тренды в России и за рубежом и практические подходы к внедрению ИИ. Участие — по персональным приглашениям.

🧑‍💻 16 октября — открытый день для инженеров
Фокус — на практической реализации подхода AI PDLC: в архитектуре, коде, инструментах и производственных процессах. Если хотите разобраться, как AI PDLC меняет весь жизненный цикл создания продукта — от работы с требованиями до запуска и масштабирования решений, — обязательно подключайтесь.

В программе четыре трека:
• ИИ-инструменты — продукты для AI-native разработки: от IDE-плагинов до агентных сред. Архитектура, метрики эффективности, ограничения и примеры внедрения.
• Модели и инфраструктура — хардкор для инженеров: инференс-кластеры, оптимизация работы с моделями, как выжать максимум из железа.
• Harness — как сделать генерацию кода предсказуемой: спецификации, контекст, политики.
• AI-native организация — как меняются команды, роли и процессы при агентизации. Только реальные кейсы.

Для инженеров, разработчиков, архитекторов, которые создают продукты и перестраивают разработку в условиях GenAI-трансформации, это must-have.

Ждем на ГигаКонф! Вместе обсудим ИИ-трансформацию, подход AI PDLC и разберемся, как сделать агентные системы управляемой частью компании, масштабировать в реальном секторе и объединить в агентную экономику.

#место_встречи #AIPDLC

Билл Гейтс о скорости AI: барьеров больше нет, ограничивающий фактор — экономика

Билл Гейтс опубликовал эссе объемом около 6000 слов о переходе к эпохе AI. Наиболее содержательная его часть посвящена не возможностям моделей, а скорости их распространения. И объяснение этой скорости лежит в области инфраструктуры, а не архитектуры нейросетей.

Почему аналогии с прошлым вводят в заблуждение

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

Каждый этап представлял собой отдельный барьер с собственным сроком.

Ни одного барьера не осталось

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

Гейтс формулирует это точно: адаптируется не человек к технологии, а технология к человеку.

Более того, система способна учиться на тех же материалах, по которым вводят в должность нового сотрудника, и на данных, которые компания и так накопила.

Ограничивающий фактор — экономика

Отсюда следует практический вывод. Ограничивающим фактором внедрения перестает быть технология и становится экономика.

Гейтс описывает соответствующий контур:
▪️ первая компания в отрасли внедряет автоматизацию;
▪️ направляет экономию в снижение цены;
▪️ конкуренты оказываются под давлением и вынуждены повторить
если действующие игроки медлят, это делают новые.

Петля усиливающая, и тормозящих элементов внутри нее нет.

Что изменилось по сравнению с переходом от сельского хозяйства

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

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

Первые количественные признаки

Гейтс ссылается на исследование Stanford Digital Economy Lab:
➡ После массового распространения генеративных моделей занятость заметно снизилась среди молодых работников на позициях, наиболее подверженных замещению.
➡ При этом среди их старших коллег изменений не зафиксировано.

Удар приходится на входные и средние роли, а новые позиции требуют навыков, на приобретение которых уходят годы.

Последний барьер — надежность, но он тоже исчезнет

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

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

Робототехника: физические ограничения сохраняются

Отдельно стоит отметить оценку по робототехнике. Здесь физические ограничения пока сохраняются, но кривая стоимости идет вниз, а основная часть передовых разработок сосредоточена за пределами США, преимущественно в Китае.

Конкуренция роботов с людьми на отдельных физических задачах в строительстве и гостиничном секторе ожидается к концу десятилетия.

Общий вывод

Окно для подготовки измеряется не темпом выхода новых моделей, а темпом их проникновения в процессы, а он определяется отсутствием барьеров. Гейтс прямо констатирует, что плана входа в эту эпоху не существует ни у государств, ни у отраслей.

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

#радар_трендов

Руководство Anthropic по AI SDLC: ИИ ускорил написание кода, но выявил узкие места

Компания Anthropic опубликовала практическое руководство (playbook) о переходе с традиционного цикла разработки ПО (SDLC) на модель AI SDLC, в которой агенты участвуют на всех этапах разработки, а человек сосредоточен на решениях, требующих ответственности.

Делимся главными выводами из обзора.

1️⃣ Код перестал быть узким местом разработки, но узкое место не исчезло

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

2️⃣ Цикл разработки (AI-Native SDLC) превращается в замкнутый контур из 6 этапов: планирование, дизайн, разработка, тестирование, развертывание, поддержка

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

3️⃣ Время от идеи до технического задания сократилось с нескольких недель до нескольких часов

Диалог с агентом фиксируется в описании задачи (intent.mdть прото-), которое агент превращает в черновик ТЗ (спецификацию, proto-spec), а владелец продукта проверяет и утверждает.

4️⃣ Институциональные знания команды закрепляются в файле правил проекта (до 1 страницы текста, CLAUDE.md) и в навыках (skill.md)

Файл правил обновляется при каждой повторяющейся ошибке агента и прочитывается в начале каждой сессии. Навыки – это инструкции по политикам безопасности, комплаенса и пользовательского опыта (UX), которые команда записывает один раз, а агент применяет автоматически при каждой подходящей задаче.

5️⃣ Агент обязан проверить собственную работу перед тем, как показать ее человеку: прогнать тесты, сборку или сравнить скриншот с макетом

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

6️⃣ Ревью трансформируется: агент проверяет все изменения по единому набору правил, человек оценивает первоначальное намерение автора и риски вместо построчной проверки кода

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

Подробный отчет читайте по ссылке

#AIPDLC

«Програмисты»: сериал 2020 года, который угадал инженерные проблемы 2026-го

«Програмисты» Алекса Гарленда вышел в марте 2020 года. GPT-3 появился через два месяца, до массового распространения генеративных моделей оставалось еще два года.

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

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

Первое попадание: изображение без источника

Машина в сериале показывает видео событий, записи которых не существует. Картинка реконструирована вычислением, но выглядит как съемка. Персонажи спорят о ее достоверности, не имея способа проверить.

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

Второе попадание: устройство доверия

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

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

Ограничение вскрылось на практике. Метрики на тесте молчат о границах применимости и не сообщают, при каком сдвиге распределения модель начнет ошибаться.

Третье попадание: объяснимость

Компьютер Amaya выдает результат без промежуточных шагов и без обоснования. Люди принимают решения, опираясь на выход, который не могут разобрать.

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

Четвертое попадание: физическая инфраструктура

Devs показан как отдельное сооружение с экранированием, вакуумной изоляцией и собственной энергетикой. В 2020 году это выглядело декорацией.

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

Пятое попадание: организационная конфигурация

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

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

Промахи: что авторы не угадали

Промахи тоже стоит зафиксировать:

▪️ Квантовые вычисления такого класса не появились и в обозримом горизонте не появятся, реальные квантовые машины решают узкие задачи и не подходят к моделированию физического мира.

▪️Детерминистский расчет вселенной остается чистой фантастикой.

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

Общий счет

Физику авторы не угадали, инженерные и организационные последствия угадали почти полностью. Сценарий 2020 года описывал систему, которой доверяют без возможности проверить, потому что она пока не ошибалась.

Источник изображения
#ИИшница

Организационная культура важнее ИИ-навыков: данные Microsoft

Microsoft опросила 20 000 сотрудников, использующих ИИ, и проанализировала статистику использования Microsoft 365. По результатам исследования выявили паттерны использования ИИ и тренды ИИ-трансформации организаций.

1. ИИ помогает, но не заменяет
66% отметили, что ИИ позволяет уделять больше времени действительно ценной работе. 58% выполняют работу, которую не могли бы делать год назад. 86% используют ИИ как отправную точку, но завершают задачи сами.

2. Как используют ИИ
Почти 50% сотрудников — для анализа, рассуждений и решения проблем, 19% — для взаимодействия с контрагентами, 17% — для выполнения работы.

3. Сотрудники хотят использовать ИИ активнее, но боятся
65% считают, что отстанут, если не начнут применять ИИ быстрее. 45% из них уверены, что безопаснее не экспериментировать и не менять привычную работу.

4. Результат определяет компания, а не навыки
Организационные условия (культура, поддержка руководителя, работа с талантами) объясняют 67% влияния на результат использования ИИ. Личные навыки сотрудника — только 32%. Инвестиции в управленческие практики окупаются сильнее, чем обучение сотрудников ИИ-инструментам.

5. Четыре группы пользователей
· Фронтир (19%) — идеальный баланс: высокие навыки сотрудников и сильная поддержка компании.
· Застрявшие (16%) — низкие навыки и слабая поддержка.
· Заблокированная инициатива (10%) — сотрудники готовы, но компания не даёт применять ИИ.
· Невостребованный потенциал (5%) — компания готова, но сотрудники отстают.

Подробности — в источнике по ссылке


#AIPDLC

Терпение как техническая стратегия: почему инварианты важнее моделей

Терпение принято считать личным качеством. В индустрии, где новая флагманская модель выходит каждые несколько месяцев, оно превращается в техническую стратегию.

Алекс Хормози в июльском эпизоде The Diary of a CEO формулирует это жестко:
фокус и терпение остаются двумя устойчивыми конкурентными преимуществами именно потому, что они «античеловечны».

Природа требует всего и сразу, рынок усиливает это требование, и дефицит сохраняется.

Экономическая логика: цена скорости реакции

Компании, которые перестраивают стек под каждый релиз, платят за скорость реакции дважды:
1️⃣ стоимостью миграции
2️⃣ потерей накопленной оптимизации.

Хормози задает таким командам один вопрос: выросла ли выручка. По его наблюдению, чаще растет лишь счет за токены.

Тонкие надстройки над моделями поглощаются следующим поколением этих же моделей, и гонка начинается заново.

Инварианты Безоса для технологических систем

Операционная форма терпения давно описана: Хормози ссылается на принцип Джеффа Безоса. Строить стоит не вокруг того, что изменится, а вокруг того, что не изменится. Клиенты через десять лет все так же предпочтут ниже цену, шире выбор и быстрее доставку.

Для технологических систем инварианты свои:
▪️ качество данных
▪️стоимость интеграции
▪️латентность
▪️цена транзакции
▪️надежность

Эти параметры сохранят значение независимо от того, какая модель возглавит бенчмарки в следующем квартале. Архитектура, собранная вокруг инвариантов, переживает смену моделей. Архитектура, собранная вокруг особенностей конкретной модели, устаревает вместе с ней.

Горизонт планирования: 10 миллионов vs 100 миллионов

Горизонт планирования меняет фундамент, а не только темп. В эпизоде звучит формула: самый быстрый путь к бизнесу на 10 миллионов долларов не совпадает с самым быстрым путем к 100 миллионам.

С системами то же самое: пилот, собранный за квартал, и платформа, рассчитанная на десятилетие, различаются не скоростью, а тем, что заложено в основание.

Отсюда типовой паттерн плато:
➡быстрый взлет,
➡упор в потолок,
➡вынужденные два шага назад;
➡перестройка фундамента, которую можно было заложить сразу.

Когнитивное препятствие: люди дисконтируют отдаленный результат

Главное препятствие здесь когнитивное. Люди дисконтируют отдаленный результат почти до нуля, даже когда он гарантирован. Поэтому инвестиции с длинным горизонтом (инфраструктура, данные, удержание клиентов) системно проигрывают бюджетные битвы эффектным демо.

Кто корректирует это смещение, получает преимущество, которое трудно скопировать.

Терпение нельзя подсмотреть со стороны, его можно только прожить.

Наблюдатель видит сделанный выбор, но не видит отвергнутые опции.

Терпение = дисциплина различения

Терпение в этой оптике не равно медлительности. Это дисциплина различения:
✅ менять курс, когда опровергнуто фундаментальное допущение;
✅ держать его, когда результат просто приходит медленнее желаемого

В отрасли, которая измеряет себя недельными релизами, длинный горизонт становится инженерным решением, а не добродетелью.

#tech_inside

Jetbrains: доля полностью агентного кода выросла до 47%, доля ручного снизилась до 27%

JetBrains, разработчик сред для написания кода (IDE) и смежных инструментов для разработки, провел опрос более 15 000 профессиональных разработчиков по всему миру и сравнил, сколько кода они пишут сами, а сколько отдают ИИ-агентам.

В частности эксперты пришли к следующим выводам:

1️⃣ Ручное написание кода перестало быть основным способом работы. В среднем разработчики сообщают, что 47% их кода полностью написано агентами, 38% написано ими самими с помощью ИИ и 27% написано вручную без ИИ.

2️⃣ Среди разработчиков сформировались три группы по способу работы с кодом.

▪️ Агентные кодеры (31%) в среднем перекладывают на агентов 84% кода.
▪️ ИИ-ассистируемые кодеры (47%) пишут с помощью агентов 40% кода и предпочитают режим совместной работы с ИИ.
▪️ Ручные кодеры (23%) пишут вручную около 75% кода и обращаются к ИИ реже.

3️⃣ Использование конкретного инструмента не гарантирует переход в группу агентных кодеров.

Среди активных пользователей Claude Code и OpenAI Codex доля тех, кто относится к агентным кодерам, составляет от 46% до 57%, то есть значительная часть даже среди этой аудитории продолжает работать в смешанном или ручном режиме.

4️⃣ Опыт работы не определяет напрямую степень доверия к агентам.

Среди разработчиков с 6 и более годами опыта 25% отдают агентам более 80% кода, тогда как среди разработчиков с опытом 1-2 года таких 18%, и они чаще выбирают режим совместной работы с ИИ, а не полную передачу задачи агенту.

5️⃣ Регион определяет скорость перехода на агентные рабочие процессы сильнее, чем стаж.

В Китае, Японии и Южной Корее от 32% до 35% разработчиков передают агентам более 80% кода, тогда как в Европе и Великобритании таких около 16%, то есть почти в два раза меньше.

Продолжение – в источнике по ссылке

#AIPDLC

Уровень стресса: когда нейросеть выдала гениальный результат с пятой попытки, а ты случайно закрыл вкладку и не сохранил итоговый промпт 😭

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

#ИИшница

От новичка до многоагентных команд: карта навыков agentic-разработки и открытые курсы Сбера

Чем больше агентов внедряется в разработку, тем острее встает вопрос: как сделать их работу предсказуемой, контролируемой и масштабируемой?

Vibe Coding создает риски накопления технического долга. Поэтому профессиональная инженерия переходит к Agentic Engineering: дисциплине, где разработчик управляет контекстом, инструментами и результатами работы агентов, делегируя агентам выполнение целых задач.

Именно для системного освоения этого подхода Сбер открыл доступ к трем бесплатным курсам и карте развития навыков Agentic Coding Roadmap.

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

Что внутри курсов

В основе обучения — карта развития навыков agentic-разработки. Это не разрозненные курсы по отдельным инструментам, а структурированная траектория: от базовых принципов до организации многоагентных команд.

Такой подход позволяет выстроить единую картину дисциплины и понять, как отдельные компетенции складываются в промышленный процесс.

Карта включает восемь этапов:

1️⃣ Основы и мышление — чем Agentic Engineering отличается от Vibe Coding и как меняется роль инженера.

2️⃣ Инструменты — выбор моделей и рабочей среды для agentic-разработки.

3️⃣ Постановка и выполнение задачи — полный цикл работы с coding agent: от задачи до приёмки результата.

5️⃣ Harness Engineering — проектирование среды, правил и обратной связи для стабильной и безопасной работы агента.

6️⃣ Agentic Workflows — построение управляемых процессов вокруг спецификаций, тестов и графов.

7️⃣ Skills — создание, проверка и поддержка собственных навыков агента.

8️⃣ Tools / MCP — проектирование инструментов, подключение внешних систем и обеспечение безопасности.

9️⃣ Agent Teams — совместная работа нескольких агентов: роли, контекст, параллельное выполнение.

Практический навигатор на базе курсов

За каждым этапом карты стоят открытые курсы и практические материалы. Три курса — три направления, которые можно последовательно изучить.

✅ AI-Driven PDLC — как GenAI меняет весь жизненный цикл продукта: от идеи и требований до релиза и сопровождения.
✅ Agentic Coding. Базовый уровень — что такое coding-агенты, как ставить им задачи, передавать контекст и контролировать результат.
✅ Введение в GitVerse — как использовать AI-инструменты внутри git-платформы GitVerse для автоматизации рутинных задач.

Материалы созданы на основе практического опыта и представляют собой базу знаний для профессиональной работы с coding-агентами в production-среде.

Если вы уже используете агентов в повседневной работе или только начинаете встраивать их в процессы — эти материалы помогут выстроить системный подход и избежать типичных ошибок.

📎 Подробности и запись — по ссылке

#AIPDLC

MIT о когнитивной капитуляции: сданная работа перестала быть свидетельством обучения

Специальный комитет MIT по использованию ИИ в обучении, преподавании и исследовательской подготовке опубликовал интересный отчет. Документ вышел ровно перед началом нового учебного года и по сути описывает развилку, на которой одновременно оказались университеты, преподаватели и сами студенты.

Проблема: артефакт без навыка

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

Сданная работа перестала быть надежным свидетельством того, что человек чему-то научился.

Для описания риска комитет использует термин, который стоит запомнить: 

❗cognitive surrender — когнитивная капитуляция.

Студент откатывается на ИИ при первом же признаке трудности. Правильный ответ, полученный от модели, создает иллюзию обучения: артефакт выглядит так же, как результат освоенного навыка, но за ним ничего не стоит.

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

Детекторы ИИ признаны непригодными

При этом отчет далек от призыва запретить инструменты. Детекторы ИИ комитет признал непригодными — любой детектор это:

❌ гонка вооружений с маскировкой,
❌ ложные срабатывания на неносителях языка,
❌ разрушение доверия между преподавателем и студентом.

Вместо контроля артефакта предлагается сменить единицу оценки:

✅ устные экзамены,
✅ семестровые портфолио,
✅ задания, выполняемые вне аудитории и защищаемые в аудитории.

Проверяется способность объяснить, а не файл на выходе.

Возможности: augmentation, а не automation

Возможности отчет описывает не менее подробно:

▪ Персональные ИИ-наставники сняли неловкость публичной практики у студентов, обучавшихся навыкам медиации — они стали тренироваться охотнее и в результате выросли в мастерстве.

▪ Курсовые-проекты по программной инженерии, которые раньше приходилось искусственно сужать до размеров семестра, теперь доводятся до состояния, близкого к промышленному.

▪ Студенты-архитекторы получили способ быстро визуализировать и проверять идеи за пределами традиционных техник представления.

Комитет формулирует принцип разграничения коротко: augmentation, а не automation.

Инструмент должен расширять то, что человек способен сделать, а не устранять необходимость этому научиться.

Новый общественный договор

Самое интересное в отчете — не про технологии. Комитет говорит о новом общественном договоре между преподавателем и студентом.

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

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

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

Главный разделитель нового учебного года

В новом учебном году это и станет главным разделителем.

1️⃣ Институт может создать условия, в которых учиться выгодно и осмысленно.

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

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

#радар_трендов

Несем вам свежий дайджест статей про ИИ. Сегодня в подборке — семь прикладных материалов: от сжатого русского эмбеддера до архитектуры торгового агента, RAG-эволюции и безопасности вайб-кодинга. Читайте, сохраняйте полезное и делитесь с коллегами!

▪️ От Naive RAG до ReAct-агента: как мы строили корпоративного AI-помощника

Эволюция корпоративного RAG-помощника от наивной версии до полноценного ReAct-агента — с реальным стеком (Qdrant, Giga-Embeddings, Qwen2.5-72B на vLLM) и конкретным фиксом парсинга Confluence, который у всех рано или поздно всплывает.

▪️ Гайд по безопасности вайб-кодинга: что сделать, чтобы не слить данные в прод

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

▪️ Как я ужал русский эмбеддер до 24 млн параметров

Автор сжал русскоязычную эмбеддинг-модель до 24М параметров и превратил ее в GGUF с квантизацией — работающий рецепт для тех, кому RAG на проде нужен без видеокарты за миллион. Все гиперпараметры, команда запуска и ссылки на репозиторий с моделью — открыты.

▪️ Как я обучил русский RAG-сплиттер

Пошаговое дообучение модели, которая режет документы на чанки по смысловым границам, а не как попало каждые 500 токенов. С конфигом LoRA, командой запуска и патчем токенайзера — можно повторить один в один.

▪️ Анатомия ИИ-трейдера: как создать своего автономного ИИ-агента и зарабатывать на бирже

Полный код торгового агента на LangChain/StateGraph по паттерну ReAct — от промпта до cron-джобы, которая его запускает. Читать не как обещание заработка, а как чистый образец архитектуры автономного агента с инструментами.

▪️ Контекстуальный ретривал: техника, которая чинит главную проблему RAG за 50 центов на тысячу чанков

Реализация метода Anthropic — добавление контекста к каждому чанку перед индексацией, снижающее ошибки ретрива на 49-67%. С кодом (generate_chunk_context(), ContextualRAGIndexer) и чек-листом внедрения из 7 шагов. Если RAG у вас промахивается мимо очевидного — это первое, что стоит попробовать.

#tech_inside

Почему масштабирование ИИ требует новой финансовой логики

Boston Consulting Group (BCG) выяснила: с ростом масштаба ИИ расходы на токены растут в геометрической прогрессии, а традиционный FinOps перестаёт работать. Вот что эксперты предлагают взамен:

1. Новая метрика — RoAI
Стоимость токена зависит от модели, длины контекста и циклов размышления агента. BCG предлагает оценивать реальную отдачу через коэффициент рентабельности ИИ:

RoAI = Экономическая отдача / (Стоимость токенов + Стоимость человеческого контроля)

Формула учитывает полную стоимость владения: время сотрудника на валидацию часто дороже самих токенов.

2. Объём токенов на один полезный результат растёт
На это влияют четыре фактора:

· Масштаб и глубина внедрения в бизнес-логику;
· Сложность и интенсивность задач;
· Контекст и итеративность циклов;
· Стоимость оркестрации моделей.

3. Токены требуют разной финансовой логики
· Инвестиции: токены на создание баз знаний и обучение;
· Операционные расходы: токены для внутренних процессов и задач;
· Себестоимость: токены в клиентских продуктах — напрямую влияют на валовую прибыль и требуют жёсткого контроля.

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

5. Управлять результатом, а не активностью
Что делать:

· Регулярно аудировать процессы с наибольшим потреблением токенов;
· Оценивать бизнес-результат через стоимость токенов + стоимость проверки;
· Принимать решения о расширении или остановке нерентабельных ИИ-сценариев.

6. Технические политики экономят бюджет
· До 5% — устранение излишних промптов;
· До 10% — перенаправление задач на дешёвые малые модели вместо флагманских;
· До 12% — кэширование типовых запросов;
· До 10% — программные механизмы контроля лимитов и циклов;
· Плюс — повышение грамотности в токен-эффективной разработке.

Подробнее — в исследовании BCG
https://www.bcg.com/publications/2026/how-ceos-can-optimize-ai-token-costs

#AIPDLC

DoorDash: когда модель заменяема, а преимущество в другом

DoorDash опубликовал трехчастный инженерный разбор Ask DoorDash — разговорного ассистента для выбора ресторанов и сборки продуктовых корзин.

Самое интересное в этом материале — не сам ассистент, а пропорции системы. Языковая модель занимает в архитектуре на удивление скромное место.

Архитектура: модель как один из слоев

Схема выглядит так ⬇️

Assistant Runtime координирует работу специализированных агентов, а вся бизнес-функциональность вынесена в общий MCP-слой:
▪ поиск по каталогу,
▪ рекомендации,
▪ корзина,
▪ checkout,
▪ история заказов,
▪ память о пользователе.

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

Детерминированные пути: часть операций — без LLM

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

Это решение закрывает сразу два вопроса — латентность и надежность — и честно фиксирует границу применимости.

Модель нужна там, где есть неопределенность, все остальное дешевле и стабильнее делать кодом.

Память: три контура, отделенные от инференса

Персонализация тоже вынесена из модели в отдельную подсистему. Три контура памяти:
1️⃣ долгосрочная — считается офлайн по истории поведения;
2️⃣ сессионная — держит контекст диалога;
3️⃣ агентная — хранит факты, которые пользователь сообщил явно.

Релевантные фрагменты достаются семантическим поиском, ранжируются и подставляются в промпт. Управление памятью отделено от инференса, то есть модель можно менять, не трогая слой знаний о пользователе.

Инфраструктура оценки: 2000 прогонов в день

Ключевой элемент конструкции — инфраструктура оценки. Фреймворк симулирует stateful-диалоги с LLM-генерированными пользователями на записанных tool fixtures и зеркалирует продакшн-рантайм, отдельно проверяя оркестрацию, guardrails и доменных агентов.

Более 2000 автоматических прогонов в день. Регрессионное тестирование сократилось с шести часов до двадцати минут

Именно эта система позволила провести миграцию на другую модель со снижением латентности на 35% при сохранении качества.

Продуктовые цифры

По данным самой компании за семидневное окно оценки:
▪ вычисляемая память дала плюс 24% к конверсии в checkout продуктовых заказов;
▪ плюс 17% к размеру корзины;
▪ ассистент в целом показал плюс 15% конверсии на открытых запросах в поиске ресторанов.

Источник заинтересованный — это инженерный блог DoorDash. Независимой проверки метрик нет.

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

Практический вывод

Из кейса следует практичный вывод.

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

Заменяемый компонент по определению не является конкурентным преимуществом. Преимуществом оказывается все, что вокруг:
➡ слой инструментов;
➡ подсистема памяти;
➡ детерминированные пути выполнения;
➡ система измерения качества;

Инвестировать имеет смысл именно туда.

#кейс