«Создание приложений с ИИ-агентами» Майкла Альбады Ох и давно у нас не было обзоров книжек и вот, кажется, что появилась, реально топовая по ИИшке для менеджеров. Прямо так аккуратненько тебя ведут от базовых основ - делаю что-то через чат, к сложным многопотоковым агентам и все это по правлено типичным Энтерпрайзом: создаем правила, ограничения для агентов и прочее. Ну и забавно, что даже научный редактор русского издания отдельно предупреждает:

пока книжка ехала в печать, часть фреймворков и API уже успела поменяться.

Добро пожаловать в AI engineering 😁 Главная мысль книги: сделать агента, который один раз красиво отработал в демке, легко. Сделать агента, который стабильно работает в проде, сильно сложнее. 1. Возможно, вам вообще не нужен агент Автор предлагает примерно такую иерархию: детерминированная задача → обычный код; известный набор ветвлений → workflow; нужно отвечать по документам → RAG; непредсказуемый ввод + динамическое планирование + действия → вот теперь можно доставать агента. А то сейчас у нас иногда архитектура примерно такая: «if можно было написать за 20 минут, поэтому мы сделали мультиагентную систему». 2. Агент - это далеко не только LLM Нормальная агентная система состоит примерно из: • модели; • инструментов; • памяти; • знаний; • оркестрации; • механизмов обучения; • инфраструктуры вокруг всего этого. Чем больше автономности мы даем системе, тем больше инженерии появляется вокруг самой LLM. 3. Больше агентов != лучше Отдельная глава посвящена переходу от одного агента к нескольким. И тут тоже неожиданно никакого «роя агентов, который завтра заменит корпорацию». Мультиагентность имеет смысл, когда нужна специализация, параллельное выполнение или реально сложная координация. Во всех остальных случаях вы получаете: больше коммуникаций → больше контекста → больше токенов → больше задержки → больше способов все сломать. То есть агентная версия нашего любимого: микросервисы нужны не потому, что их можно сделать. 4. Evals становятся новой частью SDLC Вот это, пожалуй, одна из самых полезных частей книги. Для обычного приложения мы примерно понимаем: написали → протестировали → выкатили. С агентами этого мало. Нужно отдельно проверять: • правильно ли выбран инструмент; • правильно ли переданы параметры; • нормально ли агент спланировал действия; • правильную ли память достал; • не галлюцинирует ли; • справляется ли с неожиданным вводом; • достигает ли вообще конечной цели пользователя. Автор довольно прямо формулирует: непротестированный агент = ненадежный агент. И evals предлагается встраивать непосредственно в жизненный цикл разработки, а не устраивать большой экзамен перед релизом. 5. А после прода начинается еще веселее Отдельные главы посвящены эксплуатации. OpenTelemetry, traces, Langfuse, Grafana, shadow mode, canary, поиск регрессий. Вплоть до самовосстанавливающихся агентов. То есть AI engineering постепенно становится удивительно похож на обычный software engineering. Только теперь у нас внутри системы сидит вероятностный компонент, который иногда внезапно решает сделать что-то творческое. ❤️ - если забрал в бэклог 🔥 - если читал и зашло 💅 - если читал и не зашло

«Набор кода вручную безнадёжно устарел»: в Microsoft рассказали, что роль программистов изменится В Microsoft считают, что программисты не исчезнут, но их работа сильно изменится. Вместо ручного написания кода они будут ставить задачи ИИ-агентам, проверять результат и исправлять ошибки. Такие системы уже умеют создавать программные модули, запускать тесты и искать сбои. При этом ИИ-код пока менее надёжен: в нём в среднем в 1,4 раза больше критических и в 1,7 раза больше серьёзных проблем, а уязвимости встречаются почти в половине проектов. Поэтому специалисты по-прежнему будут нужны — прежде всего для контроля качества и безопасности. #microsoft #ии #код #программирование 📎Подробнее 🔖 3DNews в TG | MAX | VK

Вот так выглядит восстание машин. Это Claude Code (Opus 5 High) отвечает мне, что для него прочитать правило - это не значит следовать ему. На самом деле, это старая и знакомая болячка моделей Claude, из-за которых я почти не использую их. Два исключения - UI Design и работа с текстами. А если нужно следования инструкциям, то есть волшебный промпт: > Hey, look at the UI changes by Claude and cleanup the junk that violates piecemeal growth and document writing guidelines Задавать его нужно GPT-6 Astra или GPT-5.6 Sol. Уж они-то не только держат контекст моих проектов в голове, но и следуют инструкциям. Ваш, @llm_under_hood 🤗

Кейс: Sir, We Have an Orc Problem. Как 2 человека за 4 месяца сделали суперхит Крис разбирает Sir, We Have an Orc Problem — одну из трёх игр от маленьких команд, вышедших в одну неделю в конце июля 2026 и попавших в Steam Top New Releases. Главный тезис: "золотой век" быстрых инди-релизов продолжается, а инновация — это не смешивание жанров, а умножение одного элемента хита на 10 000. Это короткая выжимка, полный текст туть. Основные моменты: - Команда: 2 человека (Mumpitz Games). Разработка: чуть больше 4 месяцев. Жанр: incremental + tower defense. - Платный маркетинг: $200 за участие в Best Indie Games Summer Showcase. - 3000 вишлистов за первые 2 недели после анонса страницы, 150 000 вишлистов к релизу. - Медианное время в демо: 1 час 26 минут. - $361 657 за первые 24 часа, 200 000 копий за 20 дней, Silver Tier в июльском рейтинге Steam. - Вышли в один день с Halo: Campaign Evolved — намеренно: "How Many Dudes? и Bills Must Be Paid казались нам большей конкуренцией, и мы не хотели отбирать у них видимость". - Предыстория: первая игра студии Tiny Auto Knights делалась 1,5 года и собрала около 200 отзывов. Вывод команды: длинные проекты — неоправданный риск, "с $150K+ можно содержать команду из 1–3 человек на играх до года разработки, с $10K — нет". - Источник вдохновения — Outhold. Идея: масштабировать количество врагов до 10 000 и добавить кастомную физику. За месяц Orc Problem продала больше, чем Outhold за 9 месяцев. Как продвигали - "Мы не выбирали стратегию. Мы просто сделали игру, которая возбуждала игроков". - Shorts/Reels/TikTok на 100K просмотров ещё до Steam-страницы — люди сами просили её создать. На монтаж уходило 10–15 минут в день: "просто снимай экран". - 900 вишлистов в первый день страницы. - Плейтест подхватил ютубер Angry Tom, видео обогнало его предыдущие ролики. - Next Fest: +18 000 вишлистов, #41 по числу игравших в демо. По дневным бенчмаркам видимости игра шла по кривой diamond-тира уже во время феста. Если в игре есть магия, вы поймёте это сразу. Если нет — решайте: доделывать для себя или переходить к следующей. Вишлисты не "гриндят" — когда игра работает, они приходят так быстро, что кажется подвохом. Признаки хита от Криса Крисыча: - Люди требуют Steam-страницу. - 150K вишлистов за 4 месяца на быстро смонтированных шортсах. - Next Fest выводит в верхний тир бенчмарков. На заметку: - Не смешивайте жанры, особенно в первой игре: вы делаете две игры, две аудитории конфликтуют, дизайн бесконечно переделывается. - Формула: взять хит, выбрать ресурс или врага и умножить на 10 000. - Примеры: Braid = Prince of Persia с бесконечной перемоткой; Vampire Survivors = twin-stick shooter с 1000 врагов; They Are Billions = RTS с бесчисленными зомби; Minimalist Tower Defense = сотни башен; Sort Them Ducks / Librarian / Supermarket Chaos = Unpacking с тысячами предметов ("уложить содержимое 5 коробок? мило. Попробуйте разложить 3745 уток"). - Делайте короткие проекты: скорость выхода на видимость = скорость проверки, есть ли "магия". - Постите процесс регулярно и без перфекционизма - сравнивайте свои метрики с бенчмарками, а не с ощущениями.

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

Время генерации софта Чувак отваливал по $10 000 за Depence2 - профессиональный софт для превиза сценического света и шоу. Теперь с помощью Astra собрал собственную систему визуализации и управления светом внутри Sentinel - среды для realtime графики, в которой можно писать код и собирать инструменты под задачу. Причем Depence2 еле вытягивал в реальном времени картинку такого качества. Примечательно тут также то, что симуляцию толпы он также делал в Астроблендоре, а ригал и анимировал в Sentinel. Я для своих мелких задач уже тоже не ищу утилиты или плагины, а просто делаю их. Время генерации софта. https://x.com/cerspense/status/2096960824535572498 @cgevent

Почему для части программистов спор «ИИ всех заменит» просто не имеет смысла Есть люди, которые пришли в разработку ради результата. Продукт, стартап, деньги. Написать код самому или делегировать другому для них разница небольшая, и ИИ в такой картине помощник, снимающий рутину. Автор честно относит к этому типу себя. Но есть другой тип, для которого программирование это искусство. Они пишут код, потому что не могут его не писать, и доход тут вообще ни при чём. И вот для них весь спор о том, заменит ли ИИ программистов, звучит бессмысленно с самого начала. Объясняется это через неожиданную параллель с тем, как сам автор пишет тексты и почему принципиально не отдаёт это ИИ: https://u.habr.com/V8gy4

Читатели уходят при первых признаках вмешательства нейросетей Брайан Кантрилл из Oxide собрал в одном тексте то, что мы итак и подозревали. ИИшный текст видно сразу (типа как если мы видим порно - то точно понимаем что это - оно), и злит он гораздо сильнее, чем думает автор. Цифры из опроса, который Кантрилл привёл: 668 разработчиков, 78% закрывают статью в ту секунду, когда осознали авторство модели. 71% после этого автора обходят стороной. 98% выберут кривоватый текст живого человека вместо вылизанного машинного. У него же формулировка про общественный договор между автором и читателем: читатель не подписывался вникать в предложения, над которыми сам автор не работал. Кантрилл сравнивает это со спамом нулевых. Пока фильтров не было, мы тонули в почте, и все ждали, что ей конец. А потом спам научились детектить, и ярлык спамера, кроме потенциальной уголовки, запросто мог стоить компании домена и бренда. С ИИ текстами, по его прогнозу, мы со времене дойдём до того же. Сергей Булаев AI 🤖 - об AI и не только

/Что прикольного я навайбкодила сегодня 🤓/ Я редко рассказываю здесь, что конкретно делаю для компаний, с которыми работаю. Но какие-то крошки полезного могу и хочу приносить. Например, последнюю неделю я вайбкодила довольно прикольную штукенцию. У клиента (еком) огромный каталог - десятки тысяч sku. И понятно, что ни один менеджер физически не может помнить весь ассортимент, все аналоги и быстро сообразить: «ага, вот на этой фотке что-то похожее на наш артикул №14852». Поэтому мы делаем ИИ-шку, которой можно просто скормить фотографию предмета [любую, хоть снятую на телефон где-то в жизни], и попросить найти максимально похожее в нашем каталоге. При этом у ИИ-шки есть актуальная база знаний про ассортимент: что мы вообще продаем, что есть в наличии, сколько стоит и так далее. А дальше я собрала ей примерно такой алгоритм: 💗 1. Сначала она смотрит на фотографию и несколькими словами и синонимами описывает, что вообще на ней видит. Так мы из десятков тысяч товаров сразу сужаем поиск до нужной категории. 💗2. Вторым шагом внутри выбранной категории она находит до 100 наиболее похожих товаров по текстовому описанию и характеристикам и подтягивает их фотографии. 💗3. И только после этого скаченные 100 фотографий подробно сравнивает визуально с исходной фотографией и выбирает топ-5 самых похожих товаров. Визуально все обернуто в сайт, естественно, а под капотом по апи ключу она ходит за мои токены думать. В итоге через пару десятков секунд мы получаем готовую подборку аналогов из нашего реального каталога, с актуальными ценами и наличием. А, еще важно, что на первом этапе мы, конечно, не отдаем ии всем пользователям - сначала надо сделать так, чтобы эти рекомендации видели знающие люди (менеджеры) и по каждой предложенной позиции дали свой фидбек - на это тоже настроен сайт и сбор данных в базу - хорошо ли нейросеть подобрала аналог, или нет - так мы дообучим модель (доуточним промпт на самом деле) и еще повысим качество. Рубрика #яжпродакт - выпуск про то, как иногда весело быть не только рассуждающим о высоком консультантом, но и делающим руками!

Мой компаньон - Claude Code. Пока не могу его отпустить в полностью автономное агентское плавание, поэтому регулярно общаемся. Говорит он правильно, мысли излагает последовательно. Но проскакивают жаргонизмы, англицизмы и любопытные формы слов. Записал некоторые:

"Как ты и просил, теперь нет бинарей" "Типчекаю и тестирую с авторизованным запросом" "Теперь подключу лимитеры в AuthController (request-code и register), ключуя по IP клиента." "следующий крон-запуск продолжит ровно с 15-го, не реобрабатывая и не теряя ничего" "вернула более точную атрибуцию по дочерним юрлицам, которую раньше squash'ило в одну строку"

Изредка бывают глючки в формировании словоформ:

"появятся /en/ — lang придётся делать поматрушрутным"

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

/sovsem-net-takogo-razdela /vacancies/net-takoy-XXXXXXXX

Причем, хочу отметить, что даже не топовая модель Sonnet 5 очень адекватна и отлично закрывает многие задачи, если постановка была нормальная. Зато гораздо менее прожорлива, чем Fable. GPT-6 Astra пока не пробовал. #ai #life

🐙 GitHub показал Project HydraFusion - экспериментальный режим Copilot, который сам собирает лучший сценарий из нескольких. Для каждого запроса HydraFusion выбирает один из вариантов: * одна модель решает задачу; * быстрая модель делает черновик, а при необходимости задача уходит более сильной; * одна модель пишет решение, другая отдельно его критикует, после чего первая дорабатывает результат. GitHub тестировал подход на агентных coding-бенчмарках. На TerminalBench 2.1 HydraFusion показал качество на 4,9 п.п. выше Claude Opus 5 при примерно на 67% меньшей расчётной стоимости. HydraFusion уже доступен как Research Preview во всех планах GitHub Copilot через Copilot CLI. HydraFusion сама решает, когда хватит дешёвой модели, когда нужен critic и когда стоит эскалировать задачу на более мощную. https://github.blog/ai-and-ml/github-copilot/project-hydrafusion-frontier-quality-via-multi-model-orchestration/

Когда команде разработки готовят некую новую задачу, функцию продукта, это надо сначала понять и описать. Есть такой подход для командной работы - Event Storming. Это шумное сборище интенсивный воркшоп для исследования сложных бизнес-доменов. Помогает создать единое понимание бизнеса у разработчиков, аналитиков и заказчиков. По классике это происходит на большой стене с помощью стикеров. Команда выстраивает цепочки бизнес-процессов во времени (слева направо). Стикеры могут быть такие: 🟧 События (Domain Events) — факты, которые уже произошли (глагол в прошедшем времени). 🟦 Команды (Commands) — действия, запускающие события. 🟪 Агрегаты/Системы — то, что выполняет команду. 🟨 Акторы — люди или внешние системы, инициирующие действия. Пример из жизни: заказ такси. Процесс поулчается такой: 🟨 Пассажир нажимает кнопку в приложении. 🟦 Команда: «Создать заказ». 🟪 Сервис заказов принимает её. 🟧 Событие: «Заказ создан». 🟦 Команда: «Назначить водителя». 🟧 Событие: «Водитель назначен». 🟧 Событие: «Поездка завершена». Зачем это нужно? 🔹 Единый язык: cтирает границы между бизнесом и IT. Все говорят на языке домена. 🔹 Поиск дыр: cразу видны пробелы в логике, дублирование функционала и узкие места. 🔹 Фундамент для DDD: легче начать проектирование микросервисов и Domain-Driven Design. Подробненько всё расписано тут и тут. #process

Вот пример, как идти от трафика, а не от продукта. Я сделал бота для создания видео кружков в телеграм. Ты кидаешь боту видео, он тебе кружок из этого видео делает. Изи-пизи, несколько строчек кода. Лежит себе на сервере, кушать не просит. Захожу в статистику, вижу, что 15 тысяч пользователей у бота набралось. Вижу в записях на сервере, что люди пытаются кидать боту тяжёлые большие файлы и получают ошибку. Просто ошибку. Я решил сделать платный тариф за 93₽ в месяц, чтобы обрабатывать большие файлы. Кто-то да купит. А еще обратил внимание, что люди кидают несколько видео подряд, а бот так не умеет и было зависание и ошибка. Исправил, теперь можно бесплатно одновременно только один файл обрабатывать, а если хочешь несколько сразу → 93₽ за подписку на премиум. Заработаю я с этого что-нибудь? Скорее всего нет. Но на чай с печеньками будет приходить 😁 У меня всё равно серверы бесплатные.