Что Грегори Орош увидел в OpenAI, Anthropic, Ramp и Uber, и как руководителю применить это, не платя за AI-театр.
Грегори Орош, автор The Pragmatic Engineer, выступил с кейноутом на конференции LDX3 в Нью-Йорке перед 2000+ инженерными руководителями, CTO и staff-инженерами. Он собрал снимок индустрии из трёх
ов: AI-лаборатории, стартапы с венчурными деньгами и Big Tech.
Разбор доклада опубликован в рассылке автора. Для доклада
Орош поговорил с людьми из OpenAI и Anthropic, изучил, как работают Ramp и Uber, и получил неопубликованные данные от GitHub, Factory AI и Linear.
Источники разного рода: внутренняя кухня лабораторий, практика компаний, которые строят продукт вокруг AI, и телеметрия инструментов, через которые проходит работа тысяч команд.
Такая выборка полезнее мнений со сцены.
Лаборатория видит, как её инженеры пишут код с помощью собственных моделей.
Трекер задач и платформа хостинга кода видят, что дошло до релиза.
Эти картины расходятся, и в расхождении виден реальный выигрыш от AI-разработки.
Главная мысль для руководителя компании: три мира движутся с разной скоростью, и если копировать чужой темп без собственной метрики результата, вы платите за театр.
В AI-лабораториях инструмент и его пользователь сидят в одном здании.
Модель улучшилась, и в тот же день инженеры перестраивают процесс под неё. Между «появилась возможность»
и «встроили в работу» почти нет задержки.
Венчурные стартапы покупают скорость на деньги инвесторов.
Их метрика роста допускает ставки на практики, которые окупятся через год или не окупятся вовсе. У Big Tech и обычного бизнеса есть legacy, регламенты, требования безопасности, аудит и люди, которые отвечают за простой.
Практики первых двух миров доходят сюда с потерями: код сгенерировали за час, а ревью, тесты и выкатка заняли столько же времени, сколько раньше.
Наша гипотеза, выведенная из этого расклада: скорость написания кода перестала быть узким местом.
Допустим, ассистент пишет вдвое больше кода, а число ревьюеров и пропускная способность пайплайна прежние. Очередь на ревью тогда растёт.
Метрика «строк в день» улучшается, а «время от идеи до работающей функции» остаётся прежним.
Поэтому ключевой показатель для нас называется TTU, time to use: сколько времени проходит, пока инструмент даёт результат у пользователя.
Эффектная демонстрация на этот показатель не влияет.
Руководителю, который отвечает за бюджет и срок, из этого следуют три практических вывода. ###
Выберите метрику до выбора инструмента
Метрика должна измерять результат: время от задачи до продакшена, доля релизов с откатом, стоимость поддержки.
Такие цифры доступны любой команде с историей задач и коммитов.
На них же строятся данные трекеров, которые приводит Орош. ###
Переведите чужой режим на свои условия
Практика стартапа со свободным выбором стека не заработает в банке или на промышленном предприятии. Спросите, какая её часть выдержит ваши требования безопасности и ваши интеграции, и берите только эту часть. ### Посчитайте стоимость контекста
С доступом ответы становятся полезными, но тогда нужно решить, какие данные и какие действия вы ей разрешаете.
Мы строим AI-native development так, чтобы ускорение кода не упиралось в остальной контур. Генерация, проверка, выкатка и наблюдение за продом образуют одну цепочку, и мы измеряем её целиком.
Доступ модели к корпоративным системам идёт через MCP: сервер описывает, какие инструменты и данные доступны, и модель вызывает только их.
Для ответов по внутренним документам работает RAG: модель опирается на найденные фрагменты ваших данных и указывает, откуда они взяты.
Между пользователями, приложениями и моделями стоит LLM & Security Gateway.
Модели могут быть любыми: Anthropic Claude, OpenAI, локальные Llama и Qwen.
Шлюз фиксирует запросы, вырезает утечки персональных данных и позволяет сменить поставщика модели без переписывания приложений.
Со стороны пользователя всё выглядит просто: сотрудник задаёт вопрос и получает ответ.
За этой простотой стоит тяжёлая инженерия: права доступа, журналирование, оценка качества и откат.
Лидеры индустрии двигаются быстро, и выигрывает тот, кто привязал скорость к результату. Руководитель, который через год назовёт цифру, на которую изменился его бизнес, окажется в лучшей позиции, чем тот, кто купил самый заметный инструмент. AI, который не двигает метрику, остаётся расходом, а расходы пересматривают первыми.
Gergely Orosz, «The state of the tech industry in 2026», The Pragmatic Engineer: https://newsletter.pragmaticengineer.com/p/the-state-of-the-tech-industry-in
