Это гостевой пост от Кенни Элиасона — CEO и сооснователя Quilia, клиентской платформы, созданной для юридических фирм, специализирующихся на делах о причинении личного вреда.
На данный момент я единственный штатный разработчик в Quilia. Мы создаем приложение для клиентов юридических фирм, занимающихся делами о травмах. Фирма оформляет подписку, передает приложение своим клиентам, а те используют его, чтобы следить за ходом своего дела. Приложением пользуются около 50 000 человек в почти 60 фирмах по всей территории США.
Сейчас захватывающее время для разработки. ИИ изменил почти все, что я знал об этой работе за последние 20 лет, и я в восторге от этого. Я выпускаю больше кода, чем когда-либо, а ошибки исправляются быстрее, чем их успел бы найти второй человек. В загруженный день я могу выпустить пять OTA-обновлений.
Стек намеренно выбран стандартный: Expo для сборок, обновлений и доставки в магазины приложений, Supabase для базы данных, TypeScript, PostHog для аналитики, Linear для отслеживания задач и Sentry для ошибок. В моем терминале всегда выполнен вход в Claude, также я использую Codex и пару ботов Grok. Агенты работают поверх этого стека и используют его так же, как и я.
Это работает, потому что базовые инструменты справляются с нагрузкой. Я полагаюсь на Expo и не заинтересован в том, чтобы переписывать его функционал с помощью кастомного кода. Мне нравится иметь сильных партнеров, которые берут часть работы на себя и закрывают пробелы, которые мне иначе пришлось бы заполнять самому. Благодаря этому я и мои агенты можем тратить время на сам продукт.
Цикл агентов, выпускающий исправления ошибок
Большинство наших исправлений ошибок теперь автоматизированы. Вот как выглядит этот цикл:
- Sentry собирает всю возможную информацию об ошибке.
- Агент сортировки (triage agent) берет контекст из Sentry, анализирует текущий код, при необходимости обращается к базе данных и находит проблему.
- В случае очевидных регрессий (например, форма перестала отправляться из-за лишней запятой), он исправляет баг, открывает PR, выполняет слияние, выпускает OTA-обновление через Expo Update и делает обратное слияние в ветку разработки.
- Если уровень уверенности падает ниже установленной планки (у нас это около 95%), процесс останавливается. Ничего не идет в продакшн. Задача попадает в Linear для человека.
Linear — это основа. Sentry передает данные в Linear. Другой агент берет задачу из Linear, выполняет фоновую отладку и продвигает ее по тому же пути. Самая медленная часть — это стопка задач, требующих участия человека. Часто агент был близок к решению, но ему не хватало «последнего взгляда». Чтобы предоставить ему скриншот, мне приходится скачивать ветку, разворачивать окружение, запускать приложение и вручную передавать данные. Это самое узкое место, которое у меня осталось.
Вот почему я нахожусь в списке ожидания Expo Simulators — облачного сервиса симуляторов от Expo. Сейчас он находится в режиме превью. Если агент сможет видеть работу приложения, меньше задач будет зависать на мне. Мой подход заключается в том, что чем больше данных я даю своим агентам, тем лучше они работают. Зрение — это тоже данные.
Агенты также взаимодействуют с Expo напрямую через сервер Expo MCP и API Expo. Они выбирают то, что лучше подходит для задачи. Я больше не копирую данные из панели управления вручную.
OTA-обновления задают темп
Обновления с исправлениями ошибок выходят постоянно. В дополнение к ним в процессе разработки я обычно выпускаю около двух релизов в день: публикую, когда результат достаточно хорош, продолжаю разработку и снова публикую до конца дня.
Под OTA-обновлением здесь понимается обновление JavaScript через Expo Update. Нативные изменения проходят через полную сборку и проверку в магазинах приложений. Когда мы добавляем метку деплоя к PR, рабочий процесс GitHub Actions проверяет, требует ли изменение полной нативной сборки или обновления. Сейчас это реализовано через обнаружение изменений в пакетах. Если пакет изменился — выполняется полная сборка. Если нет — OTA-обновление. Expo Fingerprint выполняет ту же проверку более строго, и я планирую изучить его в ближайшее время.
Каждое обновление по-прежнему проходит через наш цикл релизов, поэтому теги, версионность и GitHub остаются актуальными. Когда мы выпускаем официальный релиз для магазинов, специальный навык (skill) собирает обновления с момента последнего релиза и пишет примечания. Expo задействован на всех критических этапах: Expo Build для сборок, prebuild и наша локальная сборка для разработки, а также Expo Submit для отправки в магазины.
OTA-обновления — это именно то звено, которое делает весь цикл эффективным. Агент исправляет ошибку, выпускает обновление, и следующий пользователь приложения даже не сталкивается с проблемой.
Supabase — это вторая половина успеха
До Supabase мы пробовали разные варианты. В самом начале мы работали на базе данных Notion, затем перешли на обычный Postgres. Я занимаюсь этим достаточно давно и годами использовал phpMyAdmin, поэтому переход на Supabase стал для меня глотком свежего воздуха. И сервис становится только лучше. Каждый раз, когда я захожу в систему, они запускают какой-то более простой способ решения задач, и с ними очень приятно работать. Мы уже делали совместный материал с Supabase в самом начале нашего пути, так что написание этой статьи кажется логичным завершением круга.
Для скорости итераций важнее всего две вещи. Первая — это branching. Мы создаем ветки базы данных, запускаем тесты на текущей структуре и не поддерживаем второй экземпляр, который вечно рассинхронизирован. Я создаю файлы миграций, добавляю столбцы и таблицы, а CI проверяет, что миграции корректно применяются к текущей схеме. Я проверяю, объединяю изменения и выхожу в продакшн, зная, что все будет работать.
Вторая — это MCP. У меня настроены две конфигурации Supabase MCP. Продакшн доступен только для чтения, поэтому агенты могут проводить диагностику на реальных данных, ничего не ломая. Среда разработки доступна для чтения и записи. Во время диагностики агент быстро обращается к продакшну, выясняет, что произошло, а затем исправляет ошибку в безопасной среде.
Supabase всегда казался мне удобным для агентов, потому что к нему очень легко получить доступ. В основном мне просто нужно «общаться» со своими данными, и Supabase делает это простым. Насколько Expo упростил выпуск сборок, настолько же Supabase упростил работу с базой данных.
Навыки, избавляющие от копипаста
Я поддерживаю множество навыков (skills). Тот, который я бы выделил, — это наш Координатор релизов (Release Coordinator). Он просматривает каждый коммит с момента последнего релиза и обобщает их в список изменений (changelog). Он инициирует PR, который запускает сборки. Когда сборки готовы, он пишет тексты для магазинов, переводит их (мы выпускаем приложение примерно на 20 языках) и использует API Apple и Google для заполнения карточек приложений. У Google и Apple разные требования к полям, поэтому он готовит данные для обоих. К моменту завершения его работы оба магазина готовы к моей проверке и отправке.
Каждая заявка подается полностью укомплектованной: теги, рекламный текст, примечания к релизу и переводы заполнены, и с тех пор у меня не было ни одного отклонения. Создание этого процесса потребовало много усилий, даже с помощью агентов, поэтому я не ожидаю, что каждая команда будет самостоятельно реализовывать весь путь через API магазинов. Однако сама идея универсальна: один раз научите агента вашей процедуре релиза, и пусть он выполняет ее каждый раз.
Я также создаю навыки, в которых заложена миссия компании. Каждый раз, когда агент приступает к проверке, он знает цель: улучшить клиентский опыт для каждого, кто столкнулся с делом о травмах. Это заставляет агентов ориентироваться на пользовательский опыт, а не просто на закрытие тикетов. И каждый раз, когда я ловлю себя на том, что даю один и тот же фидбек дважды, я превращаю его в навык. Я не хочу просить об одном и том же десять раз.
Я знаю, это звучит так, будто я лишаю себя работы. Это не так. Теперь моя работа — это оркестровка. Я воспринимаю себя как дирижера, и чем больше я могу дирижировать вместо того, чтобы играть на каждом инструменте, тем быстрее и качественнее мы можем строить. Около 15 лет назад я помог одному парню переключить мышь с двойного клика на одинарный. Когда я закончил, он пошутил: «Чувак, ты только что сэкономил мне секунды жизни». Он шутил, но этот менталитет остался со мной. Каждый раз, когда агент мог бы сделать что-то чуть быстрее меня, я встраиваю это.
Что чувствуют пользователи
Чего мы не могли делать раньше, так это детально анализировать, что работает, а что нет. Агенты смотрят, какие факторы влияют на завершение пользователем процесса и почему некоторые этого не делают, а затем мы итерируем. Мы видим, где кто-то запутался, выпускаем исправление в тот же день и гарантируем, что у следующего пользователя опыт будет лучше, чем у предыдущего.
Дело не в том, что пользователи стали говорить больше. Они говорят меньше. Проблема, которая раньше кого-то раздражала, исправляется до того, как человек успеет на нее пожаловаться. Мы не гонимся за каждым отдельным запросом. Мы берем то, с чем сталкиваются люди, и превращаем это в лучший опыт для всех. Наше внутреннее отслеживание показывает, что около 82% клиентов готовы рекомендовать наш продукт, а показатели внедрения и использования продолжают расти. Мы слышим меньше жалоб, и, надеюсь, это хороший знак. Обычно так и есть.
Если вы небольшая команда и думаете об этом
Вам не нужна большая команда, чтобы запустить такой цикл. Вам нужен стек, который агенты могут видеть и на который могут воздействовать: трекер ошибок, передающий контекст, база данных с безопасным путем только для чтения в продакшн и способ выпустить JavaScript-исправление за минуты, а не за дни. Для нас это Sentry, Supabase и Expo Update. Что бы вы ни выбрали, полагайтесь на надежных партнеров в вопросах инфраструктуры и тратьте свое время на продукт.
Если вы уже используете Expo и Supabase, самым простым решением будет ветка базы данных для CI и Supabase MCP в режиме чтения для продакшна. Руководство Expo по Supabase описывает настройку. Если вы еще не выпускаете OTA-обновления, начните с документации Expo Update. Весь этот цикл зависит от них. И если ваши агенты застревают на этапе «требуется человек», как и мои, записывайтесь в список ожидания Expo Simulators. Увидимся там.
