Armin Ronacher разработал библиотеку Absurd — решение для создания надежных рабочих процессов, использующее только Postgres без дополнительных сервисов. В ответ на растущий спрос на устойчивое выполнение (durable execution) в эпоху AI-агентов, он создал минималистичную систему на основе единственного SQL-файла. Библиотека решает проблему сохранения состояния при сбоях, используя возможности Postgres для управления очередями и хранения чекпоинтов. Ключевая особенность — деление задач на шаги, которые автоматически восстанавливаются после перезапуска, избегая дублирования работы.

Для AI-агентов Absurd предлагает элегантный подход с автоматической нумерацией повторяющихся шагов. Пример кода демонстрирует задачу с единственным шагом "iteration", которая при повторении превращается в "iteration#2", "iteration#3" и т.д., сохраняя только новые сообщения. Система поддерживает приостановку задач, ожидание событий и автоматическую загрузку состояния из чекпоинтов. Запуск осуществляется через простую функцию absurd.spawn(), а обработка ошибок включает механизм повторов с ограничением попыток.

• Обсуждение в основном вращается вокруг двух тем: длительное выполнение задач (durable execution) и инструментов для этого, таких как Absurd SQL и Temporal, а также их сравнение с другими решениями, включая DBOS и Cadence.
• Участники обсуждают, что такие инструменты как Absurd SQL и Temporal предоставляют простоту и надежность, но могут быть сложны в использовании и требуют дополнительной настройки.
• Также обсуждается, что такие инструменты как Absurd SQL и Temporal могут быть полезны для обеспечения надежности и простоты в работе с агентами и их непредсказуемым поведением.
• Участники также обсуждают, что такие инструменты как Absurd SQL и Temporal могут быть полезны для обеспечения надежности и простоты в работе с агентами и их непредсказуемым поведением.
• В конце обсуждение сосредотачивается на том, что такие инструменты как Absurd SQL и Temporal могут быть полезны для обеспечения надежности и простоты в работе с агентами и их непредсказуемым поведением.

Microsoft представила Agent Lightning, инструмент для разработки AI-агентов. Проект находится на GitHub в репозитории microsoft/agent-lightning, но подробное описание функционала в предоставленном тексте отсутствует. Судя по названию проекта, он позиционируется как "абсолютный тренер" для создания и обучения AI-агентов. В репозитории пока нет подробной документации или примеров использования. Microsoft продолжает расширять свое присутствие в области ИИ, добавляя инструменты для разработчиков в экосистему GitHub.

• Обсуждение в основном крутится вокруг того, что проект не имеет ясной цели, документации и примеров, а также использует LLM для генерации README, что вызывает скепсис.
• Участники также критикуют отсутствие бенчмарков для задач с разреженной наградой или частичной наблюдаемостью, что является критически важным для утверждений о "обучении любого агента".
• Сомнения вызывает и то, что проект позиционирует себя как "фреймворк для оптимизации LLM агентов", но при этом не предоставляет никаких примеров или документации, а также использует LLM для генерации README.
• Некоторые участники также указывают на то, что проект не предоставляет никаких бенчмарков для задач с разреженной наградой или частичной наблюдаемостью, что является критически важным для утверждений о "обучении любого агента".
• В целом, обсуждение показывает, что проект вызывает много вопросов из-за отсутствия ясной цели, документации и примеров, а также использует LLM для генерации README.

Андрей Карпати из OpenAI объясняет, почему до общего искусственного интеллекта (AGI) остаётся ещё около десятилетия. Хотя современные ИИ-агенты вроде Claude и Codex впечатляют, они пока неспособны автономно выполнять комплексные задачи, как человек-ассистент. Основные ограничения включают недостаточную многомодальность (неспособность работать с разными типами данных), неумение взаимодействовать с компьютерными системами и отсутствие непрерывного обучения на основе опыта.

Эти проблемы решаемы, но сложны — требуется масштабирование вычислительных мощностей, улучшение алгоритмов (особенно обучения с подкреплением, которое сейчас "ужасно"), и создание более сложных архитектур для обработки контекста и планирования. Как и с беспилотными автомобилями, прогресс будет постепенным, а не взрывным.

Когда AGI finalmente появится, оно, вероятно, интегрируется в экономику так же плавно, как и предыдущие технологические прорывы, поддерживая ~2% рост ВВП без резких скачков. Даже AGI не приведёт к немедленному преобразованию общества; изменения будут постепенными и управляемыми.

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

• Обсуждение в основном вращается вокруг того, что AGI/AGI-образные системы всё ещё далеки, и что «десятилетие» стало универсальным эвфемизмом для «мы не знаем, когда это будет».
• Участники спора подчеркнули, что текущие модели не решают фундаментальные проблемы, такие как постоянное обучение, причинность и планирование, и что мы по-прежнему полагаемся на эвристики, которые не масштабируются.
• Были выдвинуты предположения, что AGI может потребовать качественно иной архитектуры, и что текущий путь может быть тупиковым.
• Некоторые комментаторы выразили обеспокоенность тем, что гипер-оптимизм может вести к недооценке рисков и переоценке способностей текущих систем.
• В целом, обсуждение подчеркнуло, что прогресс в ИИ-технологии не линеен и что прогнозы о сроках AGI часто оказываются неверными.

Большинство ИИ-агентов (95%) терпят неудачу в продакшене не из-за недостатка интеллекта моделей, а из-за проблем с контекстной инженерией, управлением памятью и безопасностью. Ключевая идея: базовые модели — это почва, а контекст — семя. Успешные команды избегают тонкой настройки, вместо этого фокусируясь на продвинутом RAG с селективным отбором контекста, валидацией и гибридными архитектурами (семантический слой + метаданные).

Они применяют подход, схожий с feature engineering: версионирование, аудит и тестирование контекста, а не работа с ним как с неструктурированным текстом. Например, text-to-SQL системы редко работают из-за неоднозначности естественного языка и специфичности бизнес-терминологии. Решение — встраивание доменных онтологий и строгих схем, превращающих контекст в управляемый актив, а не в случайный набор данных.

• Обсуждается разрыв между завышенными ожиданиями от AI (восприятие как "магии") и реальностью, где 95% развертываний AI-агентов терпят неудачу из-за проблем с инфраструктурой, а не с моделями.
• Подчеркивается важность контекстного инжиниринга, проверенных бизнес-логик и шаблонов, а не прямого генеративного подхода (например, text-to-SQL).
• Многие решения на основе LLM сводятся к детерминированным системам (деревьям решений), что ставит под вопрос их необходимость вместо более простых и надежных альтернатив.
• Отмечается, что успех зависит от инженерии ("строительных лесов") — валидации, безопасности, слоев памяти — а не от интеллекта модели.
• Высказывается критика в адрес маркетинга AI как "волшебства" и генерации контента с помощью AI, который часто оказывается многословным и бессодержательным.

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

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

• Пользователи делятся положительным опытом использования Sculptor для разработки, отмечая удобство параллельной работы и локального выполнения кода в изолированных контейнерах.
• Обсуждаются технические детали работы инструмента: использование контейнеров, поддержка различных моделей ИИ (Claude Code, GPT, Gemini), интеграция с devcontainer и выполнение тестов.
• Высказываются пожелания по расширению функционала: поддержка других языковых моделей и агентов, веб-версия, тёмная тема, настройка переменных окружения.
• Команда разработчиков поясняет план развития: открытие исходного кода, бесплатность для личного использования и возможные платные тарифы для бизнеса в будущем.
• Участники проводят сравнение с аналогичными инструментами (Terragon, Conductor, VibeKit), отмечая различия в подходе к коллаборации и интеграции.

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

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

• Сомнения в эффективности использования ИИ для генерации кода из-за высокого процента ошибок и необходимости тщательного ревью, которое может быть более трудоемким, чем написание кода с нуля.
• Озабоченность качеством и надежностью ИИ-сгенерированного кода, особенно в зрелых проектах и open source, где отсутствие публичного ревью может подорвать доверие.
• Увеличение нагрузки на разработчиков из-за необходимости ревью большего объема кода, который часто требует повышенного внимания из-за непредсказуемости ИИ.
• Потеря преимуществ человеческого взаимодействия в процессе ревью, поскольку ИИ не может участвовать в обсуждении или доработке кода.
• Необходимость разработки новых процессов и инструментов для эффективного ревью ИИ-сгенерированного кода, включая возможность комментирования и взаимодействия с агентами.

Как переписывание промта повысило эффективность GPT-5-mini на 22%

Мы представляем результаты тестирования модели GPT-5-mini в рамках бенчмарка Tau², предназначенного для оценки языковых моделей. Оказалось, что простое переписывание промта повысило успешность небольшой модели более чем на 20%.

Тестирование LLM с Tau²

На летнем обновлении OpenAI заявили, что GPT-5 значительно улучшила агентские задачи. Для проверки использовали бенчмарк Tau², симулирующий реальные взаимодействия в телекоме, ритейле и авиалиниях. Однако улучшения GPT-5 были заметны только в телекоме, поэтому мы сосредоточились на этой области.

GPT-5-mini предлагает преимущества: вдвое меньше задержка, выше пропускная способность и в пять раз дешевле при 85–95% производительности полной GPT-5. Мы провели эксперимент, чтобы оценить, насколько хорошо GPT-5-mini справляется с бенчмарком и можно ли улучшить её результаты, изменяя политики агентов или описания задач.

Базовые результаты: 45% провалов

Мы запустили подмножество из 20 тестовых сценариев телекома. Результаты показали успешность всего 55%. GPT-5-mini с её ограниченными возможностями reasoning не приблизилась к флагманской GPT-5.

Бенчмарк также ввёл метрику pass^k, измеряющую надёжность агента при k попытках выполнения задачи, и выделил задачи, с которыми агент не справляется совсем.

Решение: переписывание промтов с помощью Claude

Мы поставили три цели: повысить общую успешность, "разблокировать" больше задач и улучшить надёжность агента. Используя генеративный ИИ, мы поручили Claude проанализировать политики агентов в телекоме и переписать их для упрощения понимания моделью GPT-5-mini.

Ключевые улучшения включали:

• Чёткие деревья решений и последовательные шаги
• Ясные условия и обработку ошибок
• Снижение когнитивной нагрузки через таблицы и шаблоны
• Действенные команды вместо описаний

После переписывания промтов успешность GPT-5-mini выросла до 77%, что на 22% выше исходного показателя. Это демонстрирует, что тонкая настройка промтов может значительно повысить эффективность небольших моделей без изменения их архитектуры.

• Оптимизация структуры промптов (деревья решений, нумерованные шаги, проверки зависимостей) значительно улучшает работу ИИ-агентов.
• Использование Claude для перезаписи промпта повысило эффективность GPT-5-mini в телеком-бенчмарке, но методология вызывает вопросы о возможной утечке данных.
• Подход перезаписи промптов затратен по времени и ресурсам, не универсален для разных доменов и может нивелировать преимущества небольших моделей.
• Сообщество выражает скептицизм относительно долгосрочной стабильности и воспроизводимости результатов, полученных с помощью подобных техник.
• Многие отмечают, что описанные практики уже представлены в более продвинутых фреймворках, таких как DSPy.
• Обсуждается этический аспект: оптимизация промпта под конкретный бенчмарк может искажать оценку истинных агентских способностей модели.
• Отсутствие исходных промптов и деталей перезаписи затрудняет независимую верификацию и воспроизведение результатов.

Краткий гид PM по архитектуре AI-агентов

Проблема
Агент показывает 89 % точность, но пользователи уходят после первого сложного запроса. Причина — не «ум», а архитектура доверия.

Сценарий
Пользователь: «Не могу войти и подписка странная».

• Вариант А: агент сразу чинит всё.
• Вариант Б: задаёт уточняющие вопросы и переводит к человеку.
  Один и тот же запрос — два разных продукта.

4 слоя архитектуры

1. Память и контекст

   • Сессионная (разговор)
   • Клиентская (история обращений)
   • Поведенческая (привычки)
   • Контекстная (актуальное состояние аккаунта)
     Чем больше помнит — тем дороже, но «живее» выглядит.

2. Интеграция данных
   Определяет, насколько глубоко агент лезет в CRM, биллинг, билеты. Глубже = сложнее уйти к конкуренту.

3. Оркестрация

   • Цепочка (последовательные вызовы)
   • Параллель (одновременные проверки)
   • Иерархия (менеджер → специалисты)
   • Аукцион (несколько моделей голосуют)
     Выбор влияет на скорость, цену и надёжность.

4. Доверие и управление риском
   Не в том, чтобы быть правым чаще, а в том, чтобы:

   • Показывать уверенность (progress bar, «я проверяю биллинг…»)
   • Давать «обратный ход» (отменить последнее действие)
   • Чётко объяснять, что делает и почему
   • Быстро эскалировать, если не уверен

Практический чек-лист PM

• Начните с минимальной памяти (сессия + аккаунт)
• Подключите только 1–2 критичных API (биллинг, тикеты)
• Используйте простую цепочку вызовов, добавьте fallback к человеку
• Добавьте индикатор уверенности и кнопку «Поговорить с человеком»
• Метрика: не точность, а % случаев, когда пользователь доволен и не требует эскалации

Итог
Пользователь не оценит 95 % точности, если при первой же ошибке потеряет контроль. Архитектируйте доверие, а не интеллект.

• Участники сходятся, что «AI-first» поддержка клиентов пока чаще ухудшает UX, чем улучшает.
• Основные риски: незрелые MCP/A2A-протоколы, проблемы безопасности, отсутствие калибровки уверенности LLM и разрыв между демо и реальностью.
• Инженеры и security-специалисты предупреждают: давать LLM доступ к боевым данным и инструментам пока «безумие».
• Предлагаемая альтернатива — не заменять людей, а усиливать их: AI подсказывает контекст и talking-points, пока человек общается с клиентом.
• PM-ы же, по мнению технарей, часто не осознают техническую сложность и требуют невозможного, что ведёт к спешным патчам или легаси на MCP v0.