Создание создателя: масштабирование разработки ИИ-навыков, когда каждый — разработчик

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

Однако, как и в случае с большинством вещей, связанных с ИИ, далеко не все то золото, что блестит. Поток концептуальных прототипов (PoC), в которых нужно досконально разобраться, чтобы довести их до ума и обеспечить безопасность, превращается в рутинную и, главное, чрезвычайно сложную с когнитивной точки зрения задачу. Инженеры, пытающиеся работать с бизнес-командами, сталкиваются с пересечением содержимого навыков, их бесконтрольным разрастанием, а также с необходимостью управлять командой, где уровень подготовки к созданию агентов часто варьируется. В результате агенты не подчиняются инструкциям и выдают неточные или искаженные результаты.

Но давайте начнем с самого начала. Концептуально агенты в экосистеме Claude могут быть определены предельно просто — с помощью синтаксиса Markdown в файле SKILL.md. Некоторые бизнес-пользователи стали все лучше определять свои собственные рабочие процессы с помощью этого инструмента. Работа инженеров в новом мире сводится к компромиссу: либо потратить больше сил заранее на создание безопасной среды для написания навыков, чтобы нетехнические специалисты могли вносить свой вклад, либо садиться вместе с экспертами, чтобы разобраться в процессе и создать его самостоятельно. Я обнаружил, что использование простоты создания навыков перед тем, как переносить их во что-то более поддерживаемое, например, на реализацию с помощью Agent SDK, действительно помогает отделить информационный шум от полезных данных. Именно это мы и рассмотрим в данной статье.

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

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

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

Для меня такое мышление вылилось в создание легкого и простого процесса в виде рабочих процессов для создания навыков. Это способ объединить лучшее из обоих миров — глубокие предметные знания и лучшие технические практики, — который позволяет быстро создавать прототипы (PoC) для таких агентов.

Думайте об этом как об установке защитных механизмов вокруг реализации логики бизнес-пользователями. Это гарантия того, что навыки не создаются раз и навсегда без учета стандартов качества, а итеративно улучшаются перед выпуском продакшн-версии. Отслеживание этого прогресса в рамках пилотного проекта позволяет мне быть уверенным, что усилия по переносу этих рабочих процессов в продакшн с использованием более надежного фреймворка, такого как Claude Agent SDK, действительно имеют смысл. Это означает, что в эти рабочие процессы постоянно вкладываются усилия и что они демонстрируют улучшения результатов процессов, которые бизнес-пользователи могут четко сформулировать.

Речь идет о процессе, который, с одной стороны, заложен в самом способе создания навыков, так что система пресекает возможные ошибки в описании навыка еще на этапе его создания. С другой стороны, это легкий механизм отслеживания, который помогает демонстрировать прогресс по мере перехода навыков от стадии альфа (#badversion) к бета (улучшенная версия, готовая к использованию другими товарищами по команде) и продакшну (повторное использование показало конкретную пользу этой версии по сравнению с текущим методом работы). Такой путь также заставляет бизнес-пользователей аргументировать, почему их версия лучше потенциально уже существующей продакшн-версии, что иногда случается в крупных организациях. И это избавляет инженера от необходимости делать за них эту работу, когда исходная бизнес-логика исходит от человека с гораздо более глубокой экспертной подготовкой в предметной области.

Создавать для всех может означать не создавать ни для кого

В нашей команде после первой попытки использования широко разрекламированной команды /skill-creator стало очевидно, что существует несколько типичных сценариев сбоев, с которыми система справляется плохо. Это напоминает о том, что хотя компании-разработчики базовых моделей хорошо выполняют свою работу, они не всегда понимают бизнес-контекст вашей компании. Кроме того, создавать продукт для массовой аудитории сложно, поэтому проектирование с учетом специфики вашей собственной среды по-прежнему имеет значение (и, скорее всего, будет иметь всегда). По мере того как навыки становились длиннее, шаги пропускались, так как состояние не поддерживалось — вероятно, из-за нехватки управления контекстом и отслеживания состояния, заложенных в этот процесс создания навыков. Поскольку концепция инженерии контекста отсутствовала, входные данные быстро засорялись, сводя на нет смысл автоматизации. Поскольку извлечение контекста через MCP было лишь одним из многих шагов в процессе, в лучшем случае некоторый контекст просто отсутствовал; в худшем случае полностью пропавший контекст мог приводить к полной галлюцинации без какого-либо осознания этого факта, что затрудняло отладку для инженеров и делало ошибки незаметными для бизнес-пользователей.

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

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

Использование проверенных инженерных практик

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

• Создание каркаса навыков (scaffolding) путем кодирования того, что сама Anthropic продвигает как лучшие практики в самом процессе разработки навыков, чтобы эксперты в предметной области (SME) могли сосредоточиться на бизнес-логике. Это направлено на то, чтобы качество навыков в меньшей степени зависело от индивидуальных базовых знаний SME, а также позволяет одновременно решать второзадачную задачу кодирования принятых в команде методов работы.
• Рефакторинг навыков как инженерная практика на базе агентов, оформленная в виде рабочих процессов. Это помогает в таких сценариях использования, как борьба с расползанием навыков, когда репозиторий навыков со временем начинает содержать множество функций для одной и той же задачи. Кроме того, это механизм импорта навыков, созданных бизнес-пользователями, которые не соответствуют лучшим практикам, в правильный формат.
• Инженерия окружения (harness engineering), например, посредством создания повторно используемых утилит безопасности, которые решают повторяющиеся проблемы вроде валидации путей. Средства защиты (guardrails), которые помогают гарантировать отсутствие непреднамеренной утечки корпоративных данных, и все более активное использование концепции «код как окружение» (code-as-harness), благодаря которой в случае необходимости можно упростить перенос системы в продакшн с отказом от экосистемы Claude.

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

Создание каркаса: прокладываем «асфальтированную дорогу»

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

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

Допустим, команда создает артефакты, относящиеся к различным клиентам, которые должны храниться в клиентских папках. Сам процесс создания навыка может включать шаг с участием человека (human-in-the-loop), на котором у пользователя запрашивается имя клиента, чтобы функция хранения могла впоследствии загрузить файл в правильную папку клиента, вместо того чтобы выводить ее из какого-то содержимого в результатах. Это минимизирует количество ошибок, которые агент может допустить на каждом атомарном шаге. Кроме того, каждый навык будет содержать определенную структуру файлов и папок для хранения справочных материалов, результатов и конфигураций, создавая упорядоченное представление о том, где что находится, а не пряча эти данные в описательном тексте навыка. Общая структура облегчает поиск. Например, скрипты, используемые для записи файлов в места вывода. Это вносит ясность в то, где искать любые конфигурации в различных навыках, делая работу инженеров по очистке более эффективной, а со временем также упрощает для SME работу с устареванием справочных данных.

Управление контекстом — важнейший элемент обеспечения точности результатов работы навыка. С одной стороны, каркас навыка может кодировать шаг, который разветвляет контекст с помощью конструкции «context: fork» в шапке (frontmatter) навыка, чтобы предоставить независимое окно контекста, не наследуемое от текущей беседы. С другой стороны, грамотный процесс создания навыков обеспечит вызов субагентов для не зависящих от контекста шагов. Это может быть реализовано путем внедрения механизма определения шагов, не зависящих от контекста. Запись промежуточного контекста в файл делает промежуточные результаты обозримыми. По сути, это также разгружает оперативную память агента, снижая вероятность потери информации из-за сжатия. Сжатие может происходить на уровне инструкций или самого контекста, что приводит к низкому качеству результатов. Предварительным условием для более простой отладки агентов являются, как минимум, доступные промежуточные результаты.

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

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

Цикл качества

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

Идея здесь заключается в том, что агентный цикл на этапе выполнения будет использовать извлеченные определения для проверки наличия проблем, пока необходимая информация все еще находится в оперативной памяти. Обратная связь может инициировать извлечение недостающей информации, исправление сигнала или ошибок форматирования в выводе. Концептуально это заимствовано из «циклической инженерии» (loop engineering), где цель в данном случае определяется предварительно извлеченными спецификациями качества.

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

Определение качества может быть как угодно полным или неполным, и это главный рычаг для того, чтобы вывод соответствовал желаемым стандартам. В процессе создания навыка автору будет предложено просмотреть и отредактировать критерии качества. Подобно тому, как оценки (evals) становятся новым PRD в разработке продуктов, где PM теперь создают оценки, здесь SME отвечают за определение критериев качества в соответствии со своими потребностями.

Рефакторинг: поддерживайте экосистему в актуальном состоянии

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

Техническим стандартом также является ограничение определений навыков до 500 строк. В противном случае возрастает риск ухудшения работы с длинным контекстом, поэтому целью любого инженера должно быть соблюдение этого ограничения по строкам. Я добился этого как с помощью хука перед коммитом (pre-commit hook), заимствованного из передовых практик разработки ПО, так и помогая экспертам в предметной области (SME) придерживаться стандарта, предлагая им варианты его соблюдения во время рефакторинга с помощью соответствующего рабочего процесса. Я считаю это одним из идеальных рабочих процессов для агентов, поскольку он включает в себя сложные решения, которые невозможно линейно представить в виде простого конвейера обработки, как это часто бывает с рабочими процессами многих других агентов.

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

• Встроенный контент, который можно вынести в справочные файлы, предлагается к перемещению в определенное место, после чего на него делается ссылка в теле навыка.
• Навык сканирования возможностей (capability-sweep) обнаруживает существующие «молекулярные навыки» — небольшие, узкоспециализированные, многоразовые навыки. Эти возможности могут заменить встроенный шаг вызовом параметризованного субагента, сокращая дублирование логики там, где настроенная версия могла бы сделать то же самое. Например, вспомните случаи, когда к серверам MCP обращаются за контекстом в ходе множества навыков, выполняющих различные исследовательские задачи; настроенная версия возможности извлечения контекста — это лаконичный способ как сократить количество строк и упростить управление контекстом, так и упростить настройку улучшенного запроса или промпта для извлечения контекста.

Важный момент здесь заключается в том, что сканирование возможностей решает проблему разрастания навыков двумя способами. Во-первых, при вызове в режиме «extraction-candidates» оно просматривает реестр текущих навыков и находит кандидатов для извлечения и управления. Во-вторых, любые извлеченные возможности будут предложены при рефакторинге, как описано выше, при вызове в режиме `existing`.

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

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

Инженерия защитных механизмов: удержание пользователей в безопасных границах

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

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

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

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

Отчасти это можно решить с помощью файла CLAUDE.md, например, который загружается в процессе создания навыка и задает стандарты качества для кода, реализуемого при создании навыка. Кроме того, соблюдение стандартов помогает наиболее лаконичным образом решать повторяющиеся проблемы; в частности, ограничение языка снижает сложность реализации необходимой валидации путей или средств защиты от SQL-инъекций до одного языка вместо нескольких. Затем их можно реализовать в виде повторно используемых и протестированных утилит безопасности.

Это относится ко всем скриптам и многоразовым функциональным возможностям, реализованным в коде. Одно из главных преимуществ использования CI/CD при работе с бизнес-пользователями заключается в том, что в многоразовые утилиты не могут быть внесены непреднамеренные изменения, когда бизнес-пользователи вносят свой вклад, за исключением изменений в самих хуках pre-commit, которые сразу видны в системах контроля версий во время код-ревью.

Помимо уже упомянутых компонентов защитной оболочки, связанных со вспомогательными структурами, такими как планирование и отслеживание состояния, я считаю, что лучший способ взглянуть на защитную оболочку — попытаться реализовать как можно больше в детерминированной логике кода, как описано в этой недавней статье. Например, везде, где навык делает что-то проверяемое, например вычисляет значение защитного барьера, повторно используемый барьер, реализованный на Python, должен возвращать булево значение (пройден ли он), и логика должна основываться на этом возвращаемом значении скрипта. Если оно ложное, можно использовать шаг с участием человека (human-in-the-loop) для проверки и, если возможно, перезаписи контента таким образом, чтобы защитный барьер был пройден.

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

Пробиваясь сквозь шум: вездесущая проблема хайпа вокруг ИИ

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

Теперь каждый — создатель. Это означает, что эксперты в предметной области знакомятся с кодом и средами разработки так, как раньше было невозможно. Это требует непрерывного обучения прямо во время работы, что для некоторых может быть источником стресса. Работа инженера также расширяется за счет того, как, например, преодолевать страхи, связанные с терминалом. Из опыта следует, что со стороны инженеров это может сработать лишь до определенного предела, стараясь максимально снизить порог входа. В этой рабочей среде каждый лично должен сделать шаги к тому, чтобы стать универсальным специалистом (T-shaped), и это сопровождается неизбежными первоначальными трудностями роста. Я вижу, что те, кто решается на этот шаг, получают от него огромную пользу, и это также формирует их представление о том, что ИИ может сделать для их повседневной работы, а что лучше оставить в руках людей как ручной труд.

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