На собеседованиях кандидата на техническое руководство его резюме обсуждали около 20 минут, а затем разговор надолго уходил в созданные им инструменты для разработки с ИИ. Этот эпизод хорошо показывает, как меняется ценность технической экспертизы: код и прототипы становятся доступнее, а способность выстроить воспроизводимую инженерную систему — заметнее и дороже для работодателя.
Об этом размышляет автор материала Habr / Карьера, который последние восемь лет работал руководителем разработки, а почти год назад вышел из найма, чтобы проверить ИИ-инструменты на собственных инженерных задачах. В двух недавних разговорах речь шла о руководящих ролях: позиции технического директора в крупной компании и запуске финтех-проекта с уже собранными разработчиками. В обоих случаях от кандидата ждали не человека, который просто распределит задачи, а того, кто создаст рабочую среду, вырастит команду и настроит процессы без постоянного ручного управления.
Резюме отвечает на базовые вопросы: где человек работал, какими технологиями пользовался, какими проектами руководил. Но оно плохо показывает логику решений в ситуации, когда готового рецепта нет. Для новой команды важнее понять, как руководитель разложит неопределённую задачу на части, оценит объём работ, распределит ответственность и заметит, что процесс начал давать сбой. Ещё важнее — сможет ли он сделать так, чтобы команда принимала качественные решения без обязательного участия руководителя в каждой мелочи.
Поэтому личный софт оказался на собеседованиях убедительнее списка навыков. Автор показывал не «домашние пет-проекты» ради строчки в портфолио, а инструменты, которыми пользовался сам. Один из примеров — система оценки сложности продукта на основе COSMIC, метода функционального измерения ПО через движения данных. Такой подход не обещает магически назвать дату релиза: функциональный размер не равен срокам, а будущие архитектурные решения всё равно могут изменить оценку. Но он позволяет обсуждать сложность на более прочной основе, чем число, случайно появившееся на планировании.
В практической работе это переводит разговор из плоскости «сколько человеко-часов поставим в таблицу» к более полезным вопросам. Какие требования уже определены? Какие функции создают основной объём работы? Какие решения ещё не приняты? Хватит ли текущей команды, чтобы справиться с этим объёмом? Для CTO или руководителя направления это не упражнение в выборе методологии. Это способ связать продуктовые ожидания, возможности команды и технические риски до того, как они превратятся в просроченный релиз.
Второй пример — SpecaFlow, инструмент, который автор создавал из-за ограничений вайбкоддинга и привычного Spec-Driven Development. Задача была не в очередной генерации кода по текстовому описанию, а в последовательном процессе: формализованные требования, планирование, проверка результата и контроль изменений. По ходу работы в инструменте появились подходы к предпроектному обследованию, дорожным картам, разработке по слоям, принципу tests first, фиксации отклонений и «паспортам» этапов. Логика проста: если исходное требование оказалось невыполнимым в прежнем виде, ИИ не должен тихо переписать план и двинуться дальше. Изменение нужно согласовать, зафиксировать и отразить в связанных документах, иначе код, документация и исходная идея разъедутся за несколько итераций.
Это знакомая проблема для больших систем, только с ИИ она возникает быстрее. Модель способна стремительно сгенерировать результат, но не несёт сама по себе ответственности за согласованность требований, решений и последствий. Здесь и проявляется ценность технической экспертизы руководителя: не в умении запретить нейросеть или лично проверить каждую строку, а в умении задать границы процесса. Где нужна проверка, кто принимает решение об отклонении, какие артефакты считаются источником правды и как команда извлекает уроки из неудачной фичи.
Для разработчиков вывод тоже довольно приземлённый. Техническая глубина не исчезает, но её всё труднее демонстрировать перечнем фреймворков. Работодателю полезнее увидеть работающий след мышления: внутренний инструмент, шаблон процесса, способ декомпозиции, систему проверок или модель оценки. Такой артефакт можно обсуждать предметно: почему выбран именно этот компромисс, где он сломается, как его адаптировать под другую команду. Для бизнеса это шанс нанимать не только исполнителей с правильными ключевыми словами, а людей, способных превращать неопределённость в управляемую работу.
ИИ сделал создание первого варианта продукта дешевле, но не сделал дешевле ответственность за то, что этот вариант будет поддерживаемым, проверяемым и полезным бизнесу. Следующий вопрос для рынка — научатся ли компании оценивать таких руководителей по качеству выстроенных ими систем, а не по громкости названий в резюме. Именно в этой зоне ценность технической экспертизы может расти быстрее всего.