Почему нанимать инхаус AI-программистов - плохая идея, даже если вы IT-компания

Вокруг AI-разработки до сих пор живет старая кадровая логика.

Она звучит так:

• наймем AI-разработчиков в штат;
• дадим им доступ к лучшим моделям;
• поставим менеджера;
• построим процесс;
• и получим предсказуемую, быструю и дешевую разработку.

На практике все чаще происходит обратное.

Вы получаете:

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

Главный тезис этой статьи жесткий, но, на мой взгляд, уже вполне практический:

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

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

Внутри почти всегда нужны:

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

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

И причина не в том, что люди плохие. Причина в том, что экономика инструмента и мотивация исполнителя перестали совпадать.

Почему AI-разработка ломает старую модель найма

В классической разработке компания более-менее понимала, за что платит.

Да, там тоже было много неэффективности, но картина была знакомой:

• junior пишет меньше;
• middle пишет больше;
• senior пишет еще больше и лучше;
• рядом есть тестировщики;
• бизнес-аналитики;
• проджект-менеджер;
• тимлид;
• архитектор;
• product owner.

Это была тяжелая, дорогая и медленная схема. Но она была хотя бы интуитивно понятна.

Сегодня эта схема стремительно распадается.

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

• архитектор или очень сильный инженер;
• AI как рабочий ускоритель;
• при необходимости бизнес-аналитик;
• тестирование на стороне заказчика или в конце приемки.

Все.

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

Именно здесь многие делают опасный вывод:

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

Но в этот момент они не замечают главного.

AI - это не просто ускорение. AI - это дорогой и трудно контролируемый производственный ресурс.

AI - это не бесплатный помощник, а дорогое топливо

Когда инженер работает в режиме Professional AI Coding, он постоянно расходует платный вычислительный ресурс.

Это не абстрактная “подписка на чатик”. Это поток затрат.

На практике картина часто выглядит так:

• простая рабочая задача может стоить 1-2 доллара AI-расхода;
• средняя задача может стоить заметно больше;
• сложная задача легко доходит до 20-30 долларов только на взаимодействие с моделями, переработку контекста, повторные прогоны, рефакторинг и проверки.

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

И это важно понять очень честно:

в AI-разработке вы оплачиваете не только человека. Вы оплачиваете человека плюс его личный канал потребления дорогого вычислительного ресурса.

Именно поэтому старая логика “зарплата плюс ноутбук плюс менеджер” перестает описывать реальную экономику производства.

Главная проблема инхаус-модели: у исполнителя нет мотивации экономить ваш AI-бюджет

Вот здесь и находится самый неприятный управленческий факт.

Инхаус AI-программист почти никогда не мотивирован экономить ваш AI-бюджет по-настоящему.

Не потому, что он плохой человек. А потому, что система стимулов устроена иначе.

Для него:

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

То есть работодатель хочет:

• быстро;
• качественно;
• и при этом экономно.

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

• быстро для себя;
• удобно для себя;
• без личной боли от перерасхода AI-ресурса.

Это фундаментальный конфликт.

Три сценария, в которые почти всегда упирается инхаус AI-команда

1. Честный сотрудник просто разбазаривает ваш бюджет

Это не обязательно злоупотребление. Чаще это обычная рабочая инерция.

Человек:

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

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

2. На вашем AI-ресурсе начинают делаться чужие задачи

Это еще менее приятный сценарий.

Если у сотрудника открыт дорогой AI-контур и нет почти идеальной прозрачности, вы очень быстро входите в серую зону:

• мелкие личные проекты;
• эксперименты “для себя”;
• помощь знакомым;
• параллельные подработки;
• обучение на вашем ресурсе;
• расход токенов вне ваших прямых задач.

И да, можно сказать: “мы это запретим”.

Но запрет и фактическая прозрачность - не одно и то же.

3. Вы строите тяжелую систему контроля, которая все равно не делает картину прозрачной

Это любимая корпоративная реакция.

Если ресурс утекает и непонятно, как он тратится, компания начинает строить контрольный контур:

• логи;
• лимиты;
• регламенты;
• согласования;
• метрики;
• внутренний аудит.

Проблема в том, что в AI-разработке сам навык работы с моделями очень плохо сводится к простой метрике.

Вам мало знать:

• сколько запросов человек отправил;
• сколько денег он потратил;
• сколько строк кода он получил;
• сколько часов был онлайн.

Нужно понимать гораздо более тонкие вещи:

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

А это почти не трекается линейно.

В результате компания приходит к абсурдной конструкции:

на каждого человека с AI вы фактически начинаете ставить еще одного человека с AI для контроля его эффективности.

То есть вместо оптимизации вы просто наращиваете управленческий и денежный слой поверх и без того дорогой модели производства.

Почему старые метрики производительности больше не работают

Раньше, грубо говоря, рынок мыслил примерно так:

• начинающий разработчик пишет 150 строк кода в день;
• middle пишет 350;
• senior пишет 550;
• дальше это обрастает тестировщиками, аналитиками, менеджерами и контрольными ролями.

Эта модель и раньше была грубой, но сейчас она стала почти бесполезной.

Потому что в AI-разработке ценность давно ушла не в количество строк и даже не в количество человек.

Ценность теперь в другом:

• кто умеет правильно поставить задачу;
• кто умеет удержать архитектурную рамку;
• кто умеет быстро проверить результат;
• кто умеет не утонуть в стоимости AI-итераций;
• кто умеет выдать систему за недели, а не за кварталы.

Сегодня один сильный архитектор с AI нередко замещает значительную часть старой продуктовой цепочки.

Именно поэтому линейный найм “еще пяти разработчиков” больше не означает линейный рост результата. Зато почти всегда означает рост бюджета.

Почему почасовая и командная модель тоже начинает ломаться

Если AI действительно ускоряет работу в 5-20 раз, а в хороших кейсах еще и снижает стоимость разработки в 5-10 раз, возникает очень неудобный вопрос:

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

И отсюда следует второй, еще более неудобный вопрос:

зачем исполнителю в инхаус-модели работать настолько быстро, если его система мотивации не привязана к конечному экономическому результату?

Никто в здравом уме внутри штатной модели не будет добровольно:

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

Это не вопрос морали. Это вопрос структуры стимулов.

Аналогия, которую бизнес давно понял в строительстве и проектировании

В строительстве, промышленном проектировании и ряде других капиталоемких отраслей эту логику поняли давно.

Даже очень крупные компании часто не держат у себя внутри полный производственный контур на все случаи жизни.

Они обычно оставляют внутри:

• эксплуатацию;
• мелкие ремонты;
• внутренний технический надзор;
• управление подрядчиками.

А все крупные проектные и строительные задачи отдают наружу.

Почему?

Потому что подрядчику платят:

• за результат;
• за срок;
• за соблюдение условий;
• и за его собственную способность оптимизировать внутренние издержки.

Заказчик не обязан оплачивать чужую неэффективность по часам, если на рынке уже есть формат оплаты за результат.

В AI-разработке начинается очень похожий сдвиг.

Почему подрядчик в AI-разработке часто экономически разумнее

Когда вы работаете с сильным внешним исполнителем, модель стимулов становится другой.

Подрядчик понимает:

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

Именно поэтому подрядчик гораздо сильнее мотивирован:

• оптимизировать использование моделей;
• не держать лишние контексты;
• стандартизировать процессы;
• переиспользовать удачные инженерные схемы;
• сокращать число дорогих итераций;
• собирать результат быстрее.

В этом и заключается главный экономический перелом.

Раньше подрядчик казался “дорогим”, а штат - “понятным”. Теперь во многих случаях подрядчик оказывается дешевле в реальной полной стоимости результата, потому что его мотивация совпадает с задачей экономить дорогой AI-ресурс.

Как теперь выглядит рациональная модель

На мой взгляд, все больше компаний будут приходить к следующей конфигурации:

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

Это особенно логично там, где бизнесу нужен не “отдел присутствия”, а:

• конкретный продукт;
• понятный срок;
• понятный объем результата;
• понятный бюджет;
• и ответственность за эффективность самого производственного процесса на стороне исполнителя.

Именно поэтому в AI-разработке все чаще правильной единицей покупки становится не человеко-час и не размер команды, а результат в установленный срок.

Возражение: “Но мы же IT-компания”

Это самое интересное возражение.

Многие IT-компании до сих пор думают, что именно им-то уж точно надо держать все AI-компетенции внутри.

Но реальность уже сложнее.

Если вы IT-компания, это еще не означает автоматически, что вам выгодно:

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

Даже для IT-компании рациональным часто оказывается другой подход:

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

То есть вопрос уже не в статусе компании. Вопрос в том, где у вас лучше совпадают стимулы, скорость и ответственность за дорогой AI-ресурс.

Где инхаус все еще нужен

Чтобы не впадать в крайность, скажу прямо: инхаус не исчезает совсем.

Он остается разумным там, где нужны:

• эксплуатация;
• поддержка уже работающих систем;
• мелкие изменения;
• внутренняя техническая приемка;
• безопасность;
• знание домена и продукта на стороне заказчика.

Но это не отменяет главного тезиса:

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

Практический вывод

AI действительно делает разработку:

• быстрее в 5-20 раз;
• дешевле в 5-10 раз;
• короче по числу ролей;
• сильнее по плотности результата на одного человека.

Но это работает только при двух условиях:

• человек действительно умеет профессионально работать с AI;
• и он лично мотивирован экономить дорогой AI-ресурс.

Именно второго условия почти никогда не существует в инхаус-модели.

Поэтому главный вывод для бизнеса звучит так:

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

Максим Жадобин, основатель THINKING•OS AI Laboratory и Lead AI Architect Tao Platform, рассматривает AI-разработку не как “расширение штата программистов”, а как смену всей производственной экономики цифровых продуктов.

THINKING•OS развивает production AI как инженерную дисциплину, где важны не часы присутствия, а управляемый результат, архитектурная зрелость и реальная стоимость исполнения.

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