По данным hh.ru за второй квартал 2025 года, медианная зарплата специалистов, умеющих работать с ИИ, на 34% выше, чем у коллег без этих навыков. При этом российский рынок корпоративного ПО с AI-функциональностью вырастет с 48 млрд рублей в 2024 году до 286 млрд к
О том, как именно меняется роль технического директора и что с этим делать, рассказывает Томас Хельстром, бывший CTO FlightPass с опытом в авиационных и кризисных цифровых продуктах.
Что AI забирает у CTO — и что оставляет только ему
Раньше технический директор тратил большую часть времени на то, чтобы ускорить работу команды: как наладить выпуск продукта, масштабировать разработку, снизить стоимость создания программного обеспечения. Сегодня значительную часть этой рутины берет на себя машина.
Нейросети хорошо генерируют черновую документацию, пишут шаблонный код, покрывают тесты, делают первичную аналитику. Так, например, в процессе работы над приложением для отслеживания COVID-контактов в сжатые сроки, именно эти задачи отнимали больше всего времени у моей команды.
Если бы мы делали тот проект сейчас, я бы в первую очередь отдал на генерацию черновую документацию, приемочные тесты и часть рутинной реализации. Мы бы написали гораздо больше тестов и гораздо подробнее описывали бы поведение системы.
Но вместе с ускорением появилась новая проблема: системы начали расти быстрее, чем люди успевают их понять. ИИ инструменты хорошо решают локальные задачи, но почти не выявляют долгосрочных архитектурных последствий. Типичная реакция модели на сложность — добавить ещё один слой абстракции или усложнить логику там, где правильным решением было бы перепроектирование кода или пересмотр границ модулей.
Это смещает и ответственность CTO. Раньше она была сосредоточена вокруг контроля за написанием кода. Сегодня — вокруг управления эволюцией системы и инженерной устойчивостью команд.
Почему CTO, который плохо понимает AI, рискует потерять контроль над инженерной культурой
Технический директор не обязан уметь обучать модели или разбираться в математике больших языковых моделей. Но обязан понимать, как такие системы работают на высоком уровне, где проходят границы их надежности и почему они принимают те или иные решения.
Дело в том, что больших языковых моделей сильно зависят от данных, на которых они обучались. В профессиональном сообществе появился термин «trendslop» — поверхностные советы по важным стратегическим вопросам, которые отражают скорее популярность подхода в обучающих данных, чем реальные особенности контекста конкретной задачи. Модель может настойчиво предлагать определенный язык, фреймворк или архитектурный паттерн просто потому, что он чаще встречался при обучении.
Если CTO не понимает системных искажений AI, возникает опасная ситуация: формально решения принимает человек, но фактически инженерную культуру начинает определять тот, кто умеет работать с моделью лучше других — или сама модель через статистические паттерны.
Это можно сравнить с тем, как раньше технический директор был обязан понимать распределенные системы или облачную инфраструктуру. Не на уровне исследователя, а на уровне человека, способного видеть компромиссы, ограничения и риски технологии. Сегодня такое же понимание требуется применительно к искусственному интеллекту.
Почему архитектурное мышление важнее навыков программирования
CTO должен хорошо представлять модель своего технологического стека, понимать его ограничения, типичные точки отказа и компромиссы. Его задача — повышать производительность и устойчивость работы всех инженерных команд одновременно.
Неудачно выбранные границы между сервисами или чрезмерная связность модулей могут годами замедлять разработку и усложнять релизы, даже если сам код написан быстро и выглядит качественно. CTO отвечает за то, чтобы система оставалась понятной для команды, безопасной для изменений и предсказуемой в поведении.
На собеседованиях стоит использовать простой способ проверки, как человек мыслит: спросить не как бы он реализовал задачу, а что в этой системе станет проблемой через два года. Инженеры, которые думают только на уровне кода, сразу говорят про технологии и реализацию конкретной задачи. А специалисты с системным мышлением говорят про границы между компонентами, сложность будущих изменений, ответственность за части системы и точки отказа.
Где заканчивается CTO и начинается CPO
AI заметно сближает позиции технического и продуктового директора. Они все чаще принимают решения совместно, в том числе в крупных компаниях, где раньше эти роли были четко разграничены.
Причина простая: архитектурные решения напрямую влияют на пользовательский опыт, а продуктовые решения — на сложность системы, надежность и долгосрочную стоимость изменений. Когда скорость разработки выросла благодаря инструментам, многие решения стало легче реализовывать, но гораздо сложнее поддерживать и безопасно развивать.
Так, к примеру, было в работе над FlightPass. В сложном интеграционном продукте технические ограничения внешних авиационных систем постоянно превращались в продуктовые решения. Где поменять интерфейс, где упростить сценарий, а где ограничить функциональность для пользователя — эти вопросы мы с продуктовым директором решали вместе.
Архитектура не существует отдельно от пользовательского опыта и бизнес-контекста. Технический директор, который упускает это, либо усложняет решения в расчете на будущее, либо оптимизирует технические показатели, не понимая, как продукт реально используется.
Как управлять неопределенностью — и почему это навык
Одно из распространенных заблуждений о роли CTO, что она требует особого психологического склада, врожденной устойчивости к хаосу. Однако терпимость к неопределенности — это навык, который развивается.
Может многое измениться, когда вы перестанете воспринимать ситуации без правильного ответа как признак собственной некомпетентности. К сложным проблемам можно относиться как к исследованию системы, где ты шаг за шагом уменьшаешь область неизвестного. В какой-то момент это начинает ощущаться как часть удовольствия от профессии.
Роль CTO во многом именно об этом: тебе редко дают задачу с готовым правильным ответом. Чаще нужно двигаться через ограничения, неполную информацию, постепенно превращая хаос в более понятную и управляемую систему.
Для инженера, который хочет стать техническим директором важно научиться принимать обратимые решения, замечать ранние сигналы проблем и корректировать курс по ходу.
Вывод
Период активного внедрения искусственного интеллекта создает для технического директора ложное ощущение контроля: инструменты работают быстро, команда продуктивна, задачи закрываются. В этот момент важно не потерять из виду архитектурную целостность системы и долгосрочные последствия решений.
Следите за тем, чтобы любой инженер в команде мог объяснить, как работает система целиком. Если это невозможно, значит система уже растёт быстрее, чем команда успевает её понимать. И никакие инструменты эту проблему не решат.
Источник: Томас Хельстром, бывший CTO FlightPass


















