Найм CTO для AI API: что проверить до того, как вы примете решение

Почему этот найм быстро становится рискованным

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

Именно поэтому основателям, которые хотят нанять CTO для AI API, нужен не просто человек, умеющий подключить модель и показать демо. Риск начинается не на первой интеграции. Он начинается после запуска, когда поставщик меняет поведение, ужесточает rate limits или функция, на которую вы опирались, перестаёт работать так же.

Ещё одна проблема — сбои. Если один API падает, пользователям всё равно, кто виноват. Они видят только, что продукт не работает. Слабый CTO воспринимает модель как чёрный ящик и надеется, что uptime и дальше будет достаточным. Сильный задаёт более жёсткие вопросы заранее: что сломается первым, как мы это обнаружим и что будет работать, если основная модель откажет?

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

Менталитет чёрного ящика всё ухудшает. Если CTO не может объяснить, почему продукт выбрал именно эту модель, какие проверки качества есть и откуда на самом деле берутся token spend, вы ставите компанию на догадки. В питч-демо это ещё может пройти. В продакшене — нет.

Представьте инструмент поддержки клиентов, который пишет черновики ответов. В понедельник он выдаёт понятные ответы за две секунды. В четверг, после изменения у поставщика, он начинает отклонять обычные запросы и отвечает уже восемь секунд. Если никто не настроил alerts, не отслеживал качество вывода и не продумал запасной путь, команда мечется, а пользователи получают ущерб.

Чем CTO должен владеть с первого дня

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

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

У каждого AI-потока должна быть понятная цель. Помощник при регистрации может требовать ответа за 2 секунды. Ночной отчёт может подождать 2 минуты. Некоторые функции выдерживают короткие простои. Другие — нет. CTO должен задать целевые показатели по времени ответа и uptime для каждого потока, чтобы команда перестала относиться ко всем API-вызовам одинаково.

Хороший CTO также решает, где нужен fallback design. Это решение должно опираться на бизнес-эффект, а не на догадки.

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

Контроль затрат тоже начинается с первого дня. AI API cost control гораздо проще, если CTO добавляет трекинг до того, как нагрузка вырастет. Это значит следить за расходами по функциям, ошибками, медленными ответами и качеством вывода в одном месте. Если один промпт после обновления продукта начинает стоить в 4 раза дороже, команда должна увидеть это в тот же день, а не в конце месяца.

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

Какие вопросы задавать на интервью

Хорошие кандидаты не отвечают абстрактно. Они превращают ваш реальный продуктовый сценарий в решения о поставщиках, лимитах, тестировании и деньгах.

Если вы хотите нанять CTO для AI API, не тратьте время на общую архитектурную теорию — вынесите на стол реальный рабочий процесс. Возьмите одну функцию, которая уже важна для пользователей, например черновики ответов поддержки, извлечение данных из документов или квалификацию лидов.

Потом задайте такие вопросы:

• «Если эту задачу могут выполнить два поставщика моделей, как бы вы их сравнили?» Сильный кандидат говорит о качестве ответа, latency, error rate, rate limits, цене за input и output tokens и о том, насколько трудно будет сменить провайдера позже. Если он говорит только о benchmark scores, это слабый ответ.

• «Что произойдёт, если наш провайдер ограничит нас по rate limits в час пик?» Вам нужен конкретный fallback design, а не расплывчатое обещание. Хорошие ответы включают очереди, повторные попытки с ограничениями, резервную модель для менее рискованных задач и понятные правила, когда приложение должно ждать, деградировать или останавливаться.

• «Как бы вы ограничили расходы для одной функции, одной команды или одного клиента?» Слушайте про бюджеты, квоты, alerts и трекинг на уровне функций. Серьёзный CTO думает об AI API cost control до того, как придёт счёт, а не после.

• «Как вы тестируете промпты и ответы перед релизом?» Хорошие кандидаты описывают тестовые наборы, ожидаемые результаты, сценарии отказов и ручную проверку для чувствительных функций. Лучшие говорят о версионировании промптов и измерении изменений вместо того, чтобы полагаться на интуицию.

• «Как бы вы объяснили компромиссы не техническому основателю?» Этот ответ многое показывает. Хороший CTO может простыми словами объяснить, почему один вариант дешевле, но менее стабилен, или почему другой безопаснее, но медленнее в запуске.

Слушайте конкретику из прошлого опыта. Человек, который работал с бережливыми системами с высокой доступностью, как это делал Oleg Sotnikov в AI-first operations, обычно отвечает цифрами, лимитами и запасными планами, а не модными словами.

Это важно, потому что AI vendor risk редко выглядит драматично в начале. Обычно он проявляется как мелкие сбои: растущие расходы, задержки в ответах, сломанные промпты и тикеты в поддержку, которых команда не ожидала.

Проведите живой тест на реальном сценарии

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

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

Используйте реальный поток

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

Потом попросите кандидата описать полный путь запроса. Вам нужно больше, чем «frontend вызывает модель». Сильный ответ обычно включает:

• что приложение отправляет на backend
• как backend собирает запрос к модели
• где проходит проверка до и после вызова модели
• что логируется для отладки и учёта затрат
• где стоят повторные попытки, тайм-ауты и rate limits

Это важно, потому что слабые кандидаты остаются на уровне промпта. Сильные думают о всём пути целиком, включая то, что ваша команда сможет поддерживать через шесть месяцев.

Смотрите, как они думают при сбоях

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

Затем попросите назвать примерную стоимость одного действия пользователя. Держите всё просто. Если один запрос использует примерно 8 000 input tokens и 1 500 output tokens, сколько это стоит при текущем объёме? Что будет, если использование удвоится? Сумеют ли они увидеть, где можно уменьшить размер промпта или избежать повторных вызовов?

Когда вы нанимаете CTO для AI API, этот тест скажет о человеке больше, чем любое интервью. Вы увидите, может ли он превратить один живой сценарий в систему, которая переживёт сбой и останется доступной по цене.

Как оценить fallback design

Хороший CTO планирует сбои до запуска. AI API может не отвечать вовремя, упираться в rate limits, возвращать битый JSON или менять поведение без предупреждения. Если вы хотите нанять CTO для AI API, попросите его объяснить, что произойдёт, если модель не ответит как ожидается.

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

На интервью попросите его взять один реальный рабочий процесс и пройтись по таким решениям:

• Когда приложение должно повторить попытку сразу, а когда — остановиться?
• Какие запросы можно поставить в очередь и завершить позже?
• Когда стоит переключиться на вторую модель или другого провайдера?
• Что делать, если модель возвращает плохой JSON или только половину ответа?
• Как именно пользователь видит сообщение во время сбоя?

Слушайте простые и конкретные ответы. «Мы просто повторим запрос» — слабый вариант. Бесконечные повторы могут увеличить расходы и создать ощущение, что приложение сломалось. Лучший ответ задаёт пределы. Например: один повтор при короткой сетевой ошибке, очередь для длинных задач вроде генерации отчётов и остановка, если вторая попытка может привести к дублирующим действиям.

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

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

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

Как оценить контроль затрат

Хороший кандидат на CTO может превратить расходы на AI в unit costs, которые можно отслеживать. Если он говорит только о месячном бюджете, этого недостаточно. Вам нужно понимать, сколько стоит один запрос, одна полная задача и один активный пользователь по мере роста использования.

Попросите его разобрать реальный рабочий процесс. Например, если продукт берёт обращение в поддержку, проверяет прошлые тикеты, пишет черновик ответа и запускает moderation, он должен оценить каждый API-вызов, число токенов, частоту повторов и процент попадания в кэш. Это покажет, думает ли он как оператор или только как разработчик.

Сильный ответ обычно включает несколько привычек:

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

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

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

Управление бюджетом требует чётких правил. Ежедневные alerts полезны, но жёсткие лимиты важнее. Хорошие ответы звучат так: ограничить расходы на клиента, приостановить необязательные задачи, переключиться на более дешёвую модель или поставить фоновые задачи в очередь до следующего бюджетного окна.

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

Если вы хотите нанять CTO для AI API, выбирайте человека, который говорит цифрами, компромиссами и лимитами. Разговоры в духе «потом оптимизируем» обычно заканчиваются большим счётом.

Простой сценарий найма

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

Потом наступает загруженная неделя. Объём тикетов резко растёт, основная модель начинает тормозить, и одновременно увеличивается счёт. Именно такой небольшой, но реальный пример показывает, может ли CTO справляться с AI vendor risk или только говорить о нём.

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

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

Если вы хотите нанять CTO для AI API, дайте ему именно этот кейс и спросите, как бы он запустил его в первую неделю. Хорошие ответы обычно включают:

• понятные правила, что считать простым тикетом
• тайм-аут, который переводит работу с медленной модели
• путь для ручной проверки рискованных случаев
• учёт стоимости по каждому тикету, а не только месячный счёт

Последний пункт важнее, чем многие основатели ожидают. Если один черновик ответа стоит 3 цента, а другой — 30 центов, продукт может выглядеть дешёвым на тестах и стать дорогим при росте объёма. Спросите кандидата, какой cost per ticket он бы считал приемлемым перед тем, как выкатывать инструмент на всю поддержку.

Ошибки, которые делают основатели

Если вы хотите нанять CTO для AI API, самая частая ошибка проста: вы выбираете человека, который сделал лучшее демо. Эффектный прототип может скрывать слабое суждение. Работа не в том, чтобы десять минут делать модель умной на вид. Работа в том, чтобы продукт оставался полезным, когда растут расходы, падает качество ответов или API начинает сбоить в самый неудобный момент.

Основатели ещё и слишком легко принимают мягкие ответы про деньги. Если кандидат говорит: «потом оптимизируем», воспринимайте это как предупреждение. Расходы на AI не остаются маленькими только потому, что первый тест был дешёвым. Хороший CTO должен говорить о token budgets, caching, routing простых задач на более дешёвые модели и о лимитах до того, как вырастет использование.

Риск поставщика слишком часто игнорируют. Многие команды ведут себя так, будто один провайдер всегда будет доступен, стабилен и с той же ценой. Это самообман. Модели меняются, rate limits срабатывают, правила безопасности ужесточаются, а сбои случаются. Если у кандидата нет чёткого плана на случай отказа, вы нанимаете надежду, а не суждение.

Слабый ответ часто звучит так:

• «Возьмём лучшую модель и посмотрим, как пойдёт»
• «Если сломается, потом сможем поменять провайдера»
• «Настройка промптов должна решить большую часть проблем»
• «На старте нам не нужно много логирования»

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

Ещё одна ловушка: один человек отвечает за промпты, а за производственный риск никто не отвечает. Такое разделение быстро проваливается. Изменения в промптах влияют на стоимость, latency, тон и error rates. Человек, который их вносит, должен так же заботиться о доступности и марже.

Небольшой пример это показывает. Стартап строит AI-ответы для поддержки на одной топовой модели. Демо выглядит отлично. Через два месяца использование удваивается, расходы растут, а у поставщика в часы пик замедляются ответы. Без логов, тестов и запасного пути команда не может понять, виноват ли промпт, модель или провайдер. Сильный CTO думает об этом до запуска, а не после того, как очередь поддержки переполнится.

Быстрые проверки перед решением

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

Именно здесь слабые кандидаты уходят в модные слова. Сильные говорят простым языком. Они могут объяснить, почему выбрали бы одну модель вместо другой, что вы получаете, чем жертвуете и когда более простая схема — лучший выбор. Если вам нужно нанять CTO для AI API, ясность важнее красивых формулировок.

Используйте короткую scorecard во время разговора:

• Попросите его прямо на месте нарисовать путь fallback. Если основная модель тормозит, падает или возвращает мусор, что происходит дальше?
• Дайте грубую цифру объёма и попросите оценить стоимость на основе вашего реального сценария. Это не должно быть идеально, но должно опираться на реальность.
• Спросите, что он измерил бы первым в первую неделю. Хорошие ответы обычно включают latency, error rate, cost per task, retry rate и проверки качества вывода.
• Проверьте, умеет ли он говорить «нет». Умный CTO часто убивает яркую идею до того, как она сожжёт ваш бюджет.
• Слушайте простой английский или простой русский. Если человек не может объяснить компромиссы не техническому основателю, ежедневная работа быстро станет болезненной.

Помогает простой пример. Допустим, ваше приложение суммирует звонки клиентов. Сильный кандидат может сказать: «Мы начнём с одной основной модели, будем версионировать промпты, логировать cost per summary и переключимся на более дешёвую резервную модель, если основная сломается или станет слишком дорогой для задач низкого приоритета». Такой ответ показывает суждение, а не просто технический диапазон.

Если нужна дополнительная уверенность, спросите, что он построит в первые 30 дней и что пока откажется строить. Второй ответ часто полезнее первого.

Что делать дальше

Если вам нужно нанять CTO для AI API, принимайте финальное решение по качеству суждения. Быстрые ответы могут впечатлить на интервью, но скорость мало значит, если человек игнорирует vendor lock-in, слабые fallback paths или рост token costs.

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

Хороший следующий шаг — попросить каждого кандидата подготовить 30-дневный план, основанный на вашем реальном продукте. Он должен быть конкретным. Вам нужно увидеть, что он запустит в первую неделю, какой риск устранит первым и как будет отслеживать API cost control до того, как счёт начнёт расти.

Сильный план обычно включает несколько конкретных действий:

• описать самые дорогие и самые хрупкие API-вызовы
• добавить fallback design на случай сбоев, медленных ответов или плохого вывода
• настроить простые alerts по расходам и лимитам использования
• проверить промпты, caching и model routing на лишние траты
• определить, кто получит уведомление, когда API упадёт

Следите за отполированными ответами, которые остаются расплывчатыми. Некоторые кандидаты хорошо говорят про AI vendor risk, но так и не называют реальный fallback path, правило повторной попытки или бюджетный guardrail. Если это происходит, возьмите второе мнение до того, как примете решение. Одна внешняя проверка может сэкономить месяцы переделок.

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

Если нужна внешняя помощь, oleg.is предлагает Fractional CTO advice и профессиональные консультации по решениям для AI-продуктов и инфраструктуры. Это может помочь, когда два кандидата выглядят одинаково сильными на бумаге, но только у одного есть план, который выдержит продакшен.