Я всё меньше смотрю на ИИ как на историю про замену человека. Честно говоря, такая постановка мне вообще не очень близка. Я люблю историю людей. Мне интересно, как люди договариваются, спорят, объединяются, ошибаются, переучиваются и вместе делают что-то большее, чем могли бы сделать поодиночке.
Поэтому в ИИ меня сейчас больше всего вдохновляет не возможность «убрать людей из процесса» и не мечта про сокращение фонда оплаты труда. Мне интереснее другое: как ИИ может усилить команду, снять лишнюю нагрузку с человеческого общения и помочь людям лучше понимать друг друга.
Потому что в реальной работе проблема часто не в том, что люди недостаточно умные или недостаточно стараются. Проблема в том, что команда постоянно теряет контекст: один человек говорит языком пользовательской боли, другой — языком архитектурных ограничений, третий — языком сроков и рисков, четвёртый — языком API, состояний и ошибок. В итоге значительная часть работы уходит не на саму задачу, а на перевод между этими языками.
Именно здесь для меня началась самая интересная часть работы с агентами. Не «агент вместо человека», а агент как усилитель человека и переводчик между людьми.
Человеческий разговор должен оставаться человеческим
Когда в рабочий чат попадает всё подряд — мотивация, эмоции, ссылки, идентификаторы, куски технического задания, решения, дефекты, статусы, уточнения и промежуточные выводы — разговор быстро становится тяжёлым. Вроде бы все нужные данные есть, но их слишком много. Человеческая мысль начинает тонуть в служебных деталях.
Я всё чаще ловил себя на том, что в чатах с людьми мы обсуждаем важные вещи: зачем нужна фича, что болит у пользователя, почему решение кажется неудобным, где есть риск, что именно мы считаем хорошим результатом. Но рядом постоянно лежит технический шум: ссылки, ID, версии контрактов, уточнения для разработчиков, результаты проверок, замечания по реализации.
Формально всё это нужно, но психологически оно забивает канал. Сейчас я стараюсь делать иначе: всё, что несёт техническую составляющую, постепенно убираю из человеческих чатов в слой агентской памяти.
В человеческом общении остаётся смысл: мотивация, эмоции, сомнения, договорённости, ответственность и управленческий импульс. А технический след — требования, решения, ссылки, контракты, результаты проверок, дефекты и передача контекста следующему исполнителю — уходит в структурированную память, с которой могут работать агенты.
Это оказалось очень удобно. Не потому, что люди перестают видеть технические детали, а потому что им больше не нужно постоянно носить их в голове. Контекст не исчезает. Он просто переезжает туда, где его лучше хранить, искать, проверять и передавать дальше.
У каждого человека свой язык
В гибридной команде важен ещё один эффект: агенты постепенно учатся разговаривать с людьми на их языке. Продакт может описывать задачу через боль пользователя и ценность, архитектор — через границы системы и последствия решений, разработчик — через реализацию, зависимости и состояния, руководитель — через сроки, риски и ответственность.
Они могут говорить об одном и том же, но разными словами. Например, человек говорит:
Я хочу управлять связями прямо в вашей Excel-табличке.
Для пользователя это простая и понятная фраза. Он не хочет думать про модель данных, типы связей, ограничения, поиск кандидатов и сохранение результата. Он говорит на языке своего опыта: «я работаю в таблице, дайте мне управлять связями прямо там».
Но для команды за этой фразой сразу появляется много смыслов: какие связи допустимы, какие объекты можно выбирать, где искать кандидатов, как показывать результат, как не сломать модель, что делать с ошибками, какие изменения нужны на фронте и бэке.
Раньше такой перевод держался на людях. Кто-то должен был услышать пользовательскую формулировку, разложить её на требования, объяснить разработчикам, уточнить ограничения, вернуть вопросы продукту, потом снова собрать всё обратно.
В гибридной команде появляется дополнительный слой. Человек говорит со своим агентом в своём словаре. Другой человек говорит со своим агентом в своём словаре. Агенты между собой могут уже «причесать» семантику: выделить объекты, связи, ограничения, решения и перевести слова одного человека так, чтобы они стали понятнее другому.
Это не отменяет человеческое общение. Наоборот, оно делает его чище. Люди продолжают говорить живым языком, а агентный слой помогает не потерять смысл между ролями.
Где здесь Онто
Онто в этой схеме для нас работает не как «чат с ИИ» и не как ещё один таск-трекер. Мы используем его как общее хранилище производственного контекста. Не в виде случайной переписки, а в виде связанной модели знания.
Важный кусок контекста привязывается не к чату, а к объекту предметной области: фиче, узлу диаграммы, API, дефекту, решению, задаче реализации. Это и есть ключевой сдвиг.
Знание не остаётся в переписке с конкретным агентом. Оно фиксируется в координатах Онто и становится доступно следующему агенту. Агент не просто «ответил в чат». Он оставил след: что было понято, какие решения приняты, какие ограничения важны, на что ссылаться дальше, что уже согласовано, а что ещё нет.
Простой цикл передачи знания
На практике цикл выглядит так. Сначала человек выбирает или создаёт объект в Онто. Например, узел, связанный с конкретной частью фичи. Потом первый агент помогает структурировать смысл: что нужно сделать, какие есть ограничения, какие части системы затрагиваются, где возможны риски, какие вопросы нужно уточнить.
После этого результат записывается не в человеческий чат, а в агентскую память этого объекта. У записи появляются понятные координаты: пространство, объект, артефакт памяти, путь и статус.
Дальше важный момент: память проходит жизненный цикл. Черновик сам по себе ещё не является знанием системы. Он может быть полезен, но его нельзя передавать дальше как принятую истину.
Условно есть три состояния:
черновик -> предложено -> принято
Только принятое знание можно нормально передавать другому агенту. Следующему агенту больше не нужно пересказывать всю историю. Ему можно дать координаты принятой памяти: работай с этим объектом, вот принятый артефакт, в нём лежит актуальный контекст.
Агент читает память, восстанавливает картину и продолжает работу. Он не начинает с вопроса «а что вообще происходит?». Он сразу видит согласованный контракт, ограничения, решения и ссылки.
После своей части он тоже оставляет след: результат реализации, найденный дефект, итог проверки, ссылку на изменение, новое решение или уточнение. Так знание переходит от человека к агенту, от агента к агенту, от этапа к этапу — и не растворяется в переписке.
Почему нельзя всё сразу считать знанием
Это оказалось очень важным правилом: не всё, что агент написал, является знанием системы. Агент может ошибиться. Человек может думать вслух. Формулировка может быть промежуточной. Черновик может быть полезным, но ещё не проверенным.
Если всё автоматически пускать в общий контекст, очень быстро получится не коллективная память, а коллективная свалка из догадок, устаревших решений и случайных формулировок.
Поэтому нам понадобился контур допуска знания. Пока память в черновике, она может существовать, но не должна быть основанием для работы других агентов. Когда память принята, она становится частью общего производственного контекста.
Это похоже на простое инженерное правило: черновик — не контракт. Только принятая память может быть передана дальше.
Пример из разработки: связи в табличном редакторе
Один из наших живых примеров — фича управления шаблонными связями в табличном редакторе. Пользовательская формулировка была очень простой: «Хочу управлять связями прямо в вашей Excel-табличке».
На человеческом языке всё понятно. Есть таблица, есть объекты, есть связи. Пользователь не хочет уходить в отдельный сложный интерфейс. Он хочет работать там, где уже находится его внимание.
Но внутри продукта это не «просто добавить ячейку». Нужно понять, какие связи допустимы, какие объекты можно выбрать, как искать кандидатов, как группировать результат, какие ограничения учитывать, как сохранять связь и как показывать ошибки.
Мы завели в Онто объект, связанный с этой частью фичи. В его агентской памяти был зафиксирован принятый контракт: какие данные нужны для поиска кандидатов, как должен выглядеть запрос, какой результат возвращается, как группируются варианты, какие ограничения нельзя потерять.
После этого backend-агент читал уже не переписку, а принятый артефакт памяти. Он видел не хаотичный набор сообщений, а структурированный контекст, привязанный к конкретному объекту.
Потом появились новые знания: реализация, проверка, блокер на QA, дефект сохранения связи, вопрос по поведению API. Они не переписывали старый контракт хаотично, а добавлялись отдельными записями: как результат реализации, как итог проверки, как дефект или как новое уточнение.
Для меня это хороший пример передачи знания в гибридной команде. Один агент помог сформулировать контракт, другой использовал его в реализации, третий зафиксировал результат проверки, четвёртый добавил дефект в очередь. А человек при этом не исчез из процесса — он удерживал смысл, пользовательскую ценность и принимал решения.
Два способа обновлять память
Постепенно стало понятно, что не всю память нужно обновлять одинаково. Иногда знание накапливается слоями: был контракт, потом появилась реализация, потом проверка, потом дефект, потом исправление. В этом случае лучше добавлять новые записи поверх старых, чтобы сохранялась история.
А иногда нужен канонический документ: например, актуальная версия API-контракта или финальное описание поведения. Тогда можно обновлять принятую версию, но важно не делать это молча. Следующий агент должен понимать, почему контекст изменился и какое решение считается актуальным.
Общее правило простое: память должна помогать продолжать работу, а не запутывать следующего участника.
Машинный интерфейс важен, но не он главный
Технически агентам нужен нормальный способ читать и писать такую память. Они не должны копировать руками куски текста между чатами.
У нас эту роль выполняет машинный интерфейс: агент может найти объект, прочитать принятую память, добавить новую запись, оставить координаты результата, связать изменение с фичей или дефектом.
Но сама техника здесь не главное. Главное — что появляется общий слой производственного контекста. Не личная память одного агента. Не чат-лог. Не отдельный документ, который быстро устаревает. А связанная память команды, привязанная к объектам работы.
Что мы для себя сформулировали как правила
В процессе работы появились несколько практических правил. Не надо размазывать требования по случайным местам, если они относятся к конкретному объекту. Лучше хранить детализацию рядом с этим объектом.
Другим агентам можно передавать только принятую память, а не черновики. Если черновик оказался ошибочным и не был принят, его лучше считать рабочим мусором, а не частью знания системы.
Если принятое знание изменилось, не нужно молча переписывать историю. Новое решение лучше зафиксировать отдельной записью или явно обновить каноническую версию.
Человек должен задавать пространство работы и идентичность ключевых объектов. Агент не должен сам угадывать, где лежит «правильная документация».
Агент должен оставлять не только результат, но и координаты: где он работал, что изменил, на что ссылается, какой артефакт можно читать следующему участнику.
Все эти правила на первый взгляд технические. Но на самом деле они про доверие. Команде важно понимать, какое знание принято, где оно лежит, кто его использовал и можно ли на него опираться.
Что об этом говорят исследования
В исследованиях по совместной работе людей и ИИ всё чаще появляется похожая мысль: эффект возникает не от самого факта наличия модели, а от правильного распределения ролей.
В исследовании Brynjolfsson, Li и Raymond про генеративный ИИ в службе поддержки доступ к AI-ассистенту повысил производительность сотрудников, особенно у менее опытных специалистов. Один из важных выводов: модель помогала быстрее распространять рабочие практики более сильных сотрудников внутри команды [1].
Исследование HBS и BCG про “jagged technological frontier” показывает другую сторону: ИИ может резко усиливать человека в одних задачах и ухудшать результат в других, если использовать его за пределами применимости [2]. То есть важен не просто доступ к ИИ, а понимание, где человек должен вести процесс, а где можно делегировать машине.
Работы про human-AI hybrids описывают такие системы как совместные рабочие контуры людей и AI-агентов, где критичны роли, правила взаимодействия и архитектура процесса [3].
Мой практический опыт хорошо ложится в эту рамку. Гибридная команда не появляется от того, что мы открыли чат с моделью. Её нужно проектировать: с памятью, ролями, статусами, правилами передачи знания и понятными границами ответственности.
Ещё один канал для человека
В этой схеме важно не спрятать всё от людей в агентскую память. Наоборот, человеку тоже нужен понятный видимый след: что произошло с объектом, какие этапы пройдены, что принято, где возникла проблема, куда смотреть дальше.
Поэтому рядом с агентской памятью полезен короткий человеческий канал объекта. Не для больших отчётов и не для технических простыней, а для того, чтобы человек мог быстро увидеть итог движения: создан контракт, принято решение, завершена реализация, найден дефект, результат проверки добавлен в память.
И при необходимости сам дополнить этот след человеческим комментарием: подтвердить решение, уточнить смысл, зафиксировать управленческую договорённость.
Мне нравится именно это разделение. Большие технические артефакты живут в памяти, где с ними удобно работать агентам. А человек видит короткий, понятный след жизни объекта и может вмешаться там, где нужен человеческий смысл.
Что в итоге меняется
Для меня главный вывод не в том, что агенты начинают быстрее писать код или собирать контекст. Хотя это тоже важно.
Главный вывод в другом: гибридная команда снижает потери смысла между людьми. Люди могут продолжать говорить человеческим языком — через боль, мотивацию, сомнение, ответственность и цель. Агенты помогают переводить этот язык в структуру, решения и действия. Онто удерживает контекст между ними, чтобы он не распался обратно на чаты, документы, ссылки и личные интерпретации.
Это не история про то, как убрать людей. Это история про то, как усилить команды: сделать так, чтобы человек меньше держал в голове технический шум и больше занимался тем, что действительно остаётся человеческим — смыслом, выбором, ответственностью, вкусом и доверием.
Именно поэтому мне сейчас так интересны гибридные команды. Не потому, что работы становится меньше, а потому, что людям становится проще работать вместе.
Источники
[1] Brynjolfsson, Li, Raymond — “Generative AI at Work”. Исследование внедрения AI-ассистента в службе поддержки: https://www.nber.org/papers/w31161
[2] Dell’Acqua et al. — “Navigating the Jagged Technological Frontier”. Исследование HBS/BCG о границе применимости ИИ: https://www.hbs.edu/faculty/Pages/item.aspx?num=64700
[3] Mayer et al. — “Designing Human-AI Hybrids”. Работа о гибридных системах людей и AI-агентов: https://www.fim-rc.de/Paperbibliothek/Veroeffentlicht/4961/id-4961.pdf
ссылка на оригинал статьи https://habr.com/ru/articles/1056644/