Рассуждаю, что важно учесть при разработке сложного софтверного продукта сейчас, чтобы он остался актуальным через год или два

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

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

• будет актуальным в среде агентов, а не людей,
• сам будет таким, что в нем агент станет полноценным пользователем и субъектом наряду с человеком

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

Хочется сейчас угадать и сделать что-то, что за год-два не потеряет своей актуальности.

Для контекста: почти год назад, в конце февраля, вышел Сонет 3.7. Сонетом 3.7 уже можно было пользоваться, он мог уверенно написать работающий файл. Ну может несколько файлов. Но он не был настолько автономным как Опус 4.6 или ГПТ 5.4.

Для контекста: стоимость решения одной и той же задачи с помощью ЛЛМ падает в 10 раз каждый год.

Вот что мне приходит в голову ↓

1. Не оптимизировать human-only-сценарии

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

• Хорошо: сделать графический редактор сценариев в стиле н8, но быстро.
• Не стал бы: тратить 500 человеко-часов на конструктор сценариев, хотя за 100 часов можно было бы сделать написание тех же сценариев из войса в телеграме.

2. Удобный, ии-нативный интерфейс

Я бы в целом ожидал возврата к основам линукосовой концепции «всё — это файл» и концепции компонуемости из юникс-утилит — программы как атомарные небольшим программам, результаты которых можно цеплять друг к другу через пайп и с унифицируемым интерфейсом ввода (текст) и вывода (текст).

Я не говорю именно про терминал и текст, но идея компонуемости, как мне кажется, станет более актуальной.

Интерфейс программ должен быть стандартный и максимально дружелюбный для агентов: rest api, терминальные команды, стандартный протокол.

• Хорошо: консольный cdk для прогона тестов
• Не стал бы: gui-программа для прогона тестов, которая еще работает только для Виндоуза.

Я говорю про достаточно общие протоколы, не обязательно про МПЦ. Я не удивлюсь, если через год агенты научатся работать с любыми апи по опенапи-спеке и мы забудем врапперы типа МПЦ, как тупиковую ветвь эволюции.

3. Агент должен уметь разобраться по доке

Если доки недостаточно, чтобы агент разобрался — дока не очень. Если для интеграции продукта с телеграмом недостаточно дать доку агенту и отправить делать, значит дока не очень понятная или подробная. Если агент не может запустить дев-стенд вашего продукта по доке за один промт — у вас что-то не так.

Сама дока должна быть доступна в агент-френдли формате: сервер-сайд-рендеринг, llm.txt или agents.md, доступность из курла. Никаких реакт-сайтов, которые требуют браузера. Да, агенты уже умеют читать и такое, но зачем усложнять им жизнь.

4. Стандартные форматы хранения, языки и протоколы

Я бы до последнего откладывал придумывание своих кастомных DSL, а попытался бы найти распространенный язык для задачи. Даже если бы он подходил всего лишь на 50%. Я понимаю, что ллм выучит и чужой незнакомый DSL. Но я не специалист и кажется, что лучше бы, чтобы не учила. Наша выучит, другая не станет.

5. Собирать из всего, что можно собрать, датасеты

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

Контекст менеджмент — 50% самого важного в контексте именно написания продукта (вторые 50% — харнес). И поэтому не удивительно, что Ноушен и Линеар сделали своих агентов, у них внутри столько контекста по компании, что зашатаешься.

6. Не замыкаться в текущих ограничениях

Стоит рассчитывать, что через 2-3 года контекстное окно вырастет так, что можно будет отправлять туда 5 миллионов токенов (давайте представим, что я — футурист). Т. е. в окно контекста целиком влезут те данные, для которых сейчас нужно делать сложные система РАГ.

7. Агенты — first class citizens

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

Если функция доступна человеку, но недоступна агенту — мы сделали что-то не так.

8. Безопасность всего этого

Придется подумать, как не сделать с агентским продуктом с невероятно широким контектом хуже, чем без него вообще. В какой-то момент в защите инфраструктуры возник zero trust (когда пропал периметр и всё стало периметром), так же и тут нужно будет делать zero trust 2.0.

Как минимум нужны будут:

• границы применимости: разделение на задачи, где норм принять решение агенту и на те, где обязателен человек;
• трассировка источников: откуда агент взял вывод и как к нему пришел,
• аудит: что он сделал и почему;
• replayability: можно ли воспроизвести решение агента потом при разборе инцидента.

9. Как встроить ии в feedback loop работы продукта

Хочется как-то перенести ответственность за контекст с человека на агента. Не оператор должен думать какие данные передать агенту, а агент должен у себя иметь инструменты self discovery и data retrival, пусть сам подумает, что ему надо.

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

10. Самим заставлять себя решать задачи ллмками и агентами

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

Случайно вышло 10 пунктов, ну и хорошо.

Если вдруг у кого есть, прости господи, подкаст, можем поговорить про это.