Я изучаю литовский. Приложений и контента для изучения, которые мне нравятся, нет. Можно, конечно, быстро сгенерировать очередное низкокачественное приложение, но зачем мне писать ещё одно приложение для изучения языка в 2026 году? Куда интереснее пойти агентским путём: посадить Hermes работать с моими заметками, словами и грамматикой, а самому дизайнить для него инструменты вместо того, чтобы пилить очередной интерфейс.
Это не пост про лучший способ учить литовский. И не туториал по Hermes. Скорее заметка о маленьком сдвиге в дизайне софта: приложение перестаёт быть просто экраном для человека и становится рабочей средой для пары «человек + агент».
Итерация 1. Obsidian + агент поверх
Самый простой старт занял буквально несколько минут: Obsidian-vault со словами и правилами грамматики, сверху Hermes как чат-учитель.
Работает плохо. Но забавно: я даю ему фидбек прямо в чате, и он доучивается. Добавляет карточки, перелинковывает их с грамматикой, сохраняет важные вещи в долгосрочную память. Взаимодействие уже ощущается не как «я пишу скрипт», а как «я менторю стажёра».
Проблемы быстро становятся очевидными:
- около 20 секунд ожидания на каждое слово, для тренировки это смерть;
- токенов сжигается прилично;
- модель «один вопрос, один ответ в чате» плохо масштабируется;
- контекст урока живёт слишком близко к переписке, а не к устойчивому продукту.
Первый вывод: агент как учитель возможен, но чат это плохая поверхность для ежедневной тренировки.
Итерация 2. Ретро с агентом
Тут случился любопытный ход. Я не стал сам придумывать следующую архитектуру. Устроил ретро и спросил у агента, что он сам предложит поменять.
Он предложил: «давай я буду генерировать тебе HTML-урок, ты проходишь его локально и отправляешь результат обратно мне на разбор».
Звучит сомнительно, но прикольно. Попробуем.
Мне нравится в этом моменте не сама HTML-идея, а способ работы. Я не просто промпчу модель на очередной ответ. Я даю ей опыт, фидбек и право предложить следующий шаг.
Итерация 3. HTML-уроки
Получилось вполне рабочее. Hermes собирает мини-урок на 5-10 минут под мой уровень и отдаёт HTML-файлом. Я прохожу его в браузере, в конце копирую JSON с ответами и комментариями, скидываю в чат, агент разбирает результат и обновляет SRS.
На первый взгляд кайф. Уже не чат, а маленький персональный урок: задания, прогресс, ответы, комментарии, разбор ошибок.
На второй взгляд всё ещё бесполезная поделка:
- HTML генерится долго, на каждый урок уходит много токенов;
- обмен данными неудобный, копировать JSON туда-сюда быстро надоедает;
- нет постоянства: каждый урок немного другой UI, немного другая структура;
- агент каждый раз заново изобретает поверхность вместо того, чтобы работать через стабильный контракт.
И тут стало понятно: проблема не в том, что HTML плохой. Проблема в том, что агенту нужен не красивый экран. Агенту нужны устойчивые команды, понятные файлы, схема данных, состояние уроков, история ошибок и возможность создавать задачи.
То есть ему нужен CLI.
Итерация 4. CLI и продукт для двух пользователей
Следующий шаг: сделать CLI, через который агент эффективно управляет контентом и уроками.
Я пошёл дальше и сделал то, что хочется называть agent-first продуктом. Не уверен, что мне нравится этот термин, но пока он неплохо обозначает идею: продукт, где агент не прикрученная AI-фича, а один из основных пользователей системы.
В моём случае это выглядит так:
- агент через CLI управляет контентом: карточками, грамматикой, расписанием SRS, генерацией уроков;
- я как человек прохожу уроки в нормальном маленьком интерфейсе и оставляю комментарии;
- у меня нет отдельной админки для ручного редактирования содержимого, и это нарочно;
- если появляется баг или хорошая идея, агент может сам открыть issue в GitHub-репозитории CLI.
Сейчас у меня там порядка ста слов и около десятка кастомных уроков, собранных под мои запросы. Цифры маленькие, но в этом и смысл: это всё ещё личный эксперимент, а не продукт «для всех».
Тут логичный вопрос: можно же было взять Anki или Quizlet и подключить к ним агента?
Можно, конечно. Но любая интеграция с готовым продуктом это полумера и набор ограничений поверх чужой ментальной модели. Для эксперимента мне нужна полная гибкость: менять схему карточек, формат уроков, поведение SRS и процесс обратной связи под то, как со мной работает агент, а не наоборот.
В обычном приложении я бы думал: какой экран нужен пользователю? Здесь вопрос стал другим: какой интерфейс нужен агенту, чтобы он мог быть хорошим учителем?
Ему не нужны кнопки. Ему нужны стабильные команды, понятные файлы, состояние уроков, история ошибок и возможность создавать задачи. А мне, человеку, наоборот, нужен простой экран на 5 минут без ожидания чата.
Получается странная, но полезная конструкция: один продукт, два разных интерфейса, два разных пользователя.
Агент как учитель и продакт-менеджер
Самое интересное оказалось не в самом CLI, а в том, как я начал работать с агентом.
Я назначил своему Hermes сразу две роли: учитель и продакт-менеджер. Он ведёт меня по урокам, а параллельно анализирует мои фидбеки и логи. Если ловит баг или хорошую идею, сам открывает issue в GitHub-репозитории. А оттуда задача уходит уже другому агенту, на имплементацию. Я в этой цепочке прихожу разбирать бэклог, который появился по результатам моих же уроков, но был сформулирован агентом.
Это смешной, но важный сдвиг: агент перестаёт быть помощником внутри продукта и становится участником продуктового цикла. Видит использование, собирает фидбек, формулирует задачи, меняет систему, в которой сам потом работает. Думаю, про это ещё напишу отдельно.
Что я понял
Главное, что вылезло из эксперимента:
Agent-first продукты, похоже, отдельный класс маленьких продуктов. Не «AI внутри приложения», а система, где агент полноценный второй пользователь и всё специально спроектировано под совместную работу человека и агента. Приложение это вообще не конечная форма инструмента: need остался тем же (выучить язык), а форма поменялась с «приложение для человека» на «пространство и инструменты, где агент работает вместе с человеком».
Дальше три ощущения, которые из этого вытаскиваются.
1. Менторишь коллегу, а не пишешь скрипт.
С агентом работаешь как со стажёром-коллегой: даёшь фидбек, объясняешь контекст, поправляешь поведение, иногда хвалишь. Главная единица не промпт, а обратная связь и долгосрочная память. Без памяти всё быстро рассыпается, и ты каждый раз начинаешь с нуля.
2. Дизайнишь не приложение, а инструменты.
CLI, файлы, форматы, состояния, схемы данных. Всё ради того, чтобы агент мог быть эффективным. Это менее эффектно, чем красивый UI, но часто важнее: хороший набор инструментов даёт агенту рычаги, которых у него иначе не было бы.
3. У продукта появляется второй пользователь, и местами он становится основным.
Первый пользователь это я, человек, которому надо быстро и приятно повторять литовский. Второй это агент, которому надо читать состояние, менять карточки, видеть ошибки, планировать уроки и создавать задачи. По объёму операций агент уже сейчас работает с системой больше, чем я. Я скорее тот, для кого агент эту систему ведёт.
Магически из коробки это не работает: чтобы довести такой процесс до нормального ежедневного использования, нужно ещё много возиться. Но сам опыт радикально другой.
Что дальше
В следующий раз планирую разобрать сам CLI и agent-first приложение для литовского: команды, SRS, как агент генерирует уроки и как задачи попадают в GitHub.