AI Platform Engineer

Должность: AI Platform Engineer Компания: Supabase Местоположение: Удаленно, Глобально

О SUPABASE

Supabase — это платформа для разработки на базе Postgres, созданная разработчиками для разработчиков. Мы предоставляем полное бэкэнд-решение, включая базу данных, аутентификацию, хранилище, Edge Functions, Realtime и Vector Search. Все сервисы глубоко интегрированы и спроектированы с учетом роста.

О РОЛИ

Мы нанимаем инженера платформы искусственного интеллекта (AI Platform Engineer) для создания слоя выполнения внутренних систем искусственного интеллекта Supabase.

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

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

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

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

ЧТО ВХОДИТ В ВАШИ ОБЯЗАННОСТИ

В этой роли вы будете:

• Выпускать платформу агентов в продакшн. Очередь с триггером событий, не зависящая от модели среда выполнения (выбор среды выполнения — открытое решение, которое вы закроете), устойчивое состояние, переживающее неудачный запуск, ворота для человеческой проверки, атомарный откат и полное логирование запусков в хранилище данных.
• Владеть слоем оценки и включать ворота, зависящие от него. Эталонные наборы с поведенческими утверждениями, а не интуицией, критерии оценки с письменной таблицей, случаи безопасности, которые должны проходить при каждом запуске, и CI-ворота, блокирующие слияние регрессии. Это предварительное условие для любого агента, который делает что-то, кроме чтения внутренних данных.
• Создавать и регистрировать портфель агентов. Агенты для отчетности, составления черновиков, линтинга, триажа и ответов на вопросы на уровнях руководства, тимлидов и индивидуальных контрибьюторов, плюс мета-уровень, который наблюдает за платформой и улучшает ее.
• Обеспечивать управление в коде. Конвейер, фактически реализующий уровни риска, учетные данные с наименьшими привилегиями для каждого агента, ворота разрешений инструментов, журнал аудита решений и классы автономности, где опасный класс не имеет пути выполнения кода, а просто предупредительную метку. Ничто не запускается без зарегистрированного владельца, уровня, разрешения инструмента и человеческих ворот.
• Проектировать, как система контактирует с людьми. Жесткий бюджет прерываний на человека, группировка сообщений вместо потока уведомлений и структура, которая предоставляет что-то полезное, прежде чем что-либо просить. Успех зависит от этого больше, чем от любого другого отдельного дизайнерского решения.
• Владеть инструментами платформы. Компилятор и валидатор, целостность инвентаря и пути, которые распределяют контекст и возможности в репозитории и чат-поверхности, где происходит работа.
• Рассчитывать операционные показатели на основе производственных данных. Конвейер от необработанной активности системы до вычисленной степени зрелости для каждой команды, достаточно обоснованный, чтобы команда могла оспорить результат и получить ответ в виде запроса, а не мнения.
• Инструментировать собственную отдачу платформы. Реестр, который регистрирует работу, поглощаемую каждым агентом, и рассчитывает ежемесячную сумму, чтобы ценность системы была измерением, а не заявлением.

КАК ВЫ БУДЕТЕ МЫСЛИТЬ

РЕКУРСИВНОЕ МЫШЛЕНИЕ

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

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

ИНВЕРСНОЕ МЫШЛЕНИЕ

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

То же самое касается оценки. Перед написанием набора вы перечисляете, как агент может ошибиться: обновление, которое выдумывает прогресс, которого не было; обновление, которое цитирует закрытый канал в публичном дайджесте; обновление, которое точно, но звучит как обвинение; обновление, которое приписывает заслугу не тому человеку. Затем набор — это этот список, каждый случай пойман до выпуска агента, а не после того, как он кого-то опозорит.

ВЫПОЛНЕНИЕ НА ОСНОВЕ ИИ

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

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

ВЫ МОЖЕТЕ ПОДОЙТИ, ЕСЛИ ВЫ

ОБЯЗАТЕЛЬНО

• Выпускали производственные системы LLM-агентов, от которых зависели другие люди. Не демо, не внутренние демонстрации. Системы с операционной историей, реальными пользователями и как минимум одним инцидентом, о котором вы можете рассказать. Само по себе управление запросами (prompt engineering) не соответствует этому требованию.
• Проектируете оценки, а не выборочные проверки. Вы создаете эталонные наборы, пишете поведенческие утверждения, определяете критерии оценки, устанавливаете пороговые значения прохождения и ставите CI-ворота в зависимости от результата. Вы можете объяснить, почему "мы просмотрели кучу результатов, и они выглядели хорошо" — это не оценка.
• Выполняли глубокую работу с API систем, в которых реально находится работа, и создавали MCP-серверы. Вы знаете конкретные сценарии отказа этих API, а не просто то, что они существуют.
• Полностью владеете инфраструктурой на Python в GCP, с облачным хранилищем данных и инфраструктурой как кодом. Вы подготавливаете, развертываете, отслеживаете и откатываете свои собственные системы, и вы закрываете архитектурные решения, а не перенаправляете их дальше.
• У вас есть вкус к тому, как программное обеспечение контактирует с людьми. Вы относитесь к каждому уведомлению как к трате ограниченного доверия.

СИЛЬНЫЙ СИГНАЛ

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

КАК ВЫГЛЯДИТ УСПЕХ

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

ЧТО МЫ ПРЕДЛАГАЕМ

• Полностью удаленная работа Мы нанимаем по всему миру. Мы верим, что вы можете делать свою лучшую работу из любого места. Офисов Supabase нет, но мы предоставляем членство в WeWork или пособие на коворкинг, которым вы можете воспользоваться в любой точке мира.
• ESOP (Опционы на акции) Каждый член команды получает ESOP (долевое участие в собственности) в компании. Мы хотим, чтобы все разделяли потенциальный рост того, что мы строим вместе.
• Технический бюджет Используйте этот бюджет для создания идеальной рабочей среды — ноутбук, монитор, наушники или что-либо еще, что поможет вам делать свою лучшую работу.
• Медицинское страхование Supabase покрывает 100% медицинского страхования для сотрудников и 80% для иждивенцев, где бы вы ни находились. Ваше благополучие и здоровье вашей семьи важны для нас.
• Ежегодные выездные мероприятия Один раз в год вся компания собирается в новом городе на неделю общения, сотрудничества и развлечений. Это важная часть нашего года.
• Гибкий график работы Мы работаем асинхронно и доверяем вам управление своим временем. Вы знаете, что нужно сделать и когда.
• Профессиональное развитие Каждый член команды получает ежегодный образовательный бюджет на обучение — курсы, книги, конференции или все, что поддерживает ваш рост.

О КОМАНДЕ

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

• ~400 членов команды
• 60+ стран
• 20+ языков
• Привлечено более 1 миллиарда долларов (включая наш раунд Серии F на 500 миллионов долларов)
• Более 540 000 членов сообщества

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