Neuronews Reposted LLM

Сколько времени ваши сотрудники тратят на ботситтинг?

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

ИИ обещает экономить время, но во многих компаниях создаёт новый вид скрытой работы — необходимость постоянно контролировать, исправлять и «докармливать» системы контекстом. Авторы называют это botsitting — невидимым, неучитываемым и обычно невознаграждаемым человеческим трудом, необходимым для того, чтобы ИИ действительно приносил пользу.

В исследовании Glean Work AI Institute опросили 6 000 сотрудников из США, Великобритании и Австралии, чья работа в основном связана с компьютером и цифровыми инструментами. 75% сказали, что с ИИ стали продуктивнее, а в среднем он автоматизировал 11 часов их работы в неделю. Но только 13% сообщили, что благодаря этому результаты их организаций заметно улучшились.

Одна из причин разрыва - botsitting. В среднем сотрудники тратят на него 6,4 часа в неделю, почти полный рабочий день и 37% всего времени, связанного с ИИ. На непосредственное выполнение работы с помощью ИИ приходится 36%. В botsitting входят передача системе недостающего контекста — 2,3 часа в неделю, поиск и исправление ошибок и неожиданного поведения — 2,2 часа, а также проверка результатов перед использованием — 1,7 часа. Цена здесь не только во времени: постоянная проверка и корректировка создаёт дополнительную ментальную нагрузку.
Авторы выделяют три системные ошибки руководителей:

1. Недооценка объёма управления, который требует ИИ. Сотрудники вынуждены вручную давать контекст, проверять точность, исправлять полуправильные ответы и разруливать последствия ошибок. Поэтому компаниям нужно отдельно измерять время на botsitting, понимать, создаёт ли этот контроль ценность, и по возможности встраивать ИИ прямо в существующие рабочие процессы, а не плодить отдельные инструменты.

2. Путать доступ к данным с наличием контекста. ИИ может видеть документы и системы, но не знать, какая версия презентации актуальна, кто реально принимает решение, где официальный процесс расходится с практикой и что именно означает «хорошо» в конкретной компании. 53% опрошенных сказали, что критически важная информация недоступна через их ИИ-системы. В компаниях с бедным контекстом сотрудники почти втрое чаще чувствуют усталость от ИИ: 50% против 18%. Поэтому контекст нужно рассматривать как инфраструктуру и фиксировать не только формальные данные, но и метазнание о том, как работа действительно делается.

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

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

Всем хороших выходных 🤗

⚙️ Меня немного запарило, что все кодинг агенты не умеют из коробки делать актуальных на сегодня агентов, потому что внутри – модели еще не обучены всем современным агентским трюкам – поэтому я прошелся по исходникам Codex, Claude Code и других популярных уроков по созданию агентов, работу с кешами, авто-сжатием контекста и тп, и собрал скилл agents-best-practices который чинит эту проблему – причем, там отдельно прописано, что эти знания для всех видов агентов, не только для кодинга:

Там нет кода, есть текстовые справочники на темы – мне помогло:

Архитектура агентного harness
Как устроить runtime вокруг модели: контекст, инструменты, permissions, память, наблюдаемость и остановочные условия.

Agentic loop
Базовый цикл: модель → tool call → валидация → permission check → выполнение → observation → следующий шаг или финальный ответ.

System prompts и инструкции
Как проектировать слои промптов: global, workspace, domain-specific, task-level и runtime reminders.

Tools и permissions
Как делать инструменты узкими, типизированными, безопасными, проверяемыми и разделёнными по risk class.

Planning mode
Как отделять планирование от исполнения: read-only exploration, план-артефакт, approval и потом мутации.

Goal-like loop
Как задавать долгоживущие цели с budget, checkpoints, validation criteria и stop condition. Это вместо Ralph Loop.

Context, memory и auto-compaction
Как управлять контекстом, делать retrieval, сохранять рабочее состояние и сжимать историю без потери критичных данных.

Prompt caching и cost-aware context
Как строить стабильные prompt-prefixes, deterministic tool ordering и cache-friendly agent runtime.

Skills и progressive disclosure
Как подключать reusable workflows: короткий skill index сначала, полные инструкции только при необходимости.

MCP и external connectors
Как подключать внешние системы через governed connectors: namespacing, auth, permissions, audit logs и least privilege.

Security, approvals и sandboxing
Prompt injection, secrets, approval flows, draft-vs-commit, sandbox для open-world tools.

Observability и evals
Как логировать agent runs, tool calls, approvals, compactions, failures и тестировать harness на реальные failure modes.

Provider API patterns
Практики для OpenAI, Anthropic и OpenAI-compatible API без привязки к одному провайдеру.

Checklists и coverage audit
Готовые списки для проверки: перед запуском, перед добавлением tools, перед подключением skills/connectors и перед продом.

Прощай vibe coding, да здравствует agent engineering😜

Андрей Карпати провел очередной разговор, на этот раз с партнёром Стефани Чжан. Что символично, год спустя после того, как он придумал термин "vibe coding".

Основные тезисы.
1. Эра Software 3.0, теперь LLM это вычислительная среда, где естественный язык как код, а агенты как runtime.
LLM - это новая операционная система. Сразу вспоминаю MemoryOS.

2. Почему Карпати и ты чувствуете себя ламером даже после 20+ лет в коде. Карпаты раньше читал любой репозиторий и понимал, что происходит. Сейчас LLM генерирует код, который он не писал и не полностью контролирует. Теперь, человек управляет не логикой, а намерением через естественный язык. Парадокс - чем лучше модели, тем меньше традиционное программирование гарантирует понимание системы.

3. Таким образом, теперь классическое обучение кодеров должно измениться, нужно не только учить человека писать код самому, но и работать с агентами. Глубина понимания + инструмент МАС.

4. Vibe Coding vs Agentic Engineering. Vibe coding - хаотичные промпты, выглядит ок, но нет архитектуры.
Agentic engineering - процесс работы с памятью и инструментами, формальные проверки, многоагентные системы, оркестрация, безопасность и мониторинг. В целом появляется сопутствующее понятие AgentOps.

5. Вопросы доверия, безопасности и контроля.
Агенты уже нуждаются в жёстких рамках, к примеру, меню доступных действий, а не свободный диалог. Проблема верифицируемости встаёт на важное место.
В классике, если код компилируется и проходит тесты - скорее всего правильно. В Software 3.0 LLM прошла тесты, но логика непрозрачная, дырки в безопасности и тп. Крч без работы не останемся. 👍

Итого в 2026 и далее:
1. Агенты повсюду, но не как умные ассистенты, а как спец юниты.
2. Инструменты для агентов станут важнее самих промптов.
3. Верификация через симуляцию/среду - запуск агента в песочнице станет стандартном.
4. Человеческое суждение станет ключевым навыком, заменяя знания синтаксиса ЯП.