AI-native инженер – это не тот, кто умеет пользоваться агентом.
Задумайтесь об истоках роли инженера. На заре любой индустрии, до разработки типовых шаблонов, инженеры брали задачу целиком. Например: построить мост или сделать автомобиль. Потом с ростом объёмов рынка и спроса появилась потребность в масштабе. Появились проектировщики, технологи, экологи, контролёры качества и т.д. Каждый отвечал за свой этап.
В разработке произошло то же самое. Инженер превратился в одно звено конвейера. Работа многих разработчиков выглядит как: взял задачу из бэклога → написал код → отдал на ревью → подождал QA → исправил замечания → взял следующую задачу.
AI начал разворачивать процесс обратно.
Когда он может написать код, покрыть его тестами, сгенерировать документацию, то ценность специалиста начала меняться. В данном случае она смещается в понимании истинной задачи и цели, декомпозиции, создания верного контекста, проверки результата и доведения продукта до работы в production.
Вот так на наших глазах меняется рынок найма. Компании, которые идут к тому, чтобы быть AI-native, уже поменяли критерии. Всё ещё нужно знать стек, конечно. Ведь нужно контролировать то, что делает агент. Но теперь основной вопрос нанимающего менеджера всё чаще звучит так: «Можете ли вы владеть результатом в системе, где часть исполнения делает AI?».
А вы уже задаёте этот вопрос своим кандидатам, или всё ещё нанимаете под конвейер?
· 19.05
Я бы уже задавал.
Но не как вопрос "умеете ли пользоваться агентом", а как разбор кейса: кандидат получил AI-generated diff, зеленые тесты и уверенное summary, как он докажет, что решена именно исходная задача?
Иначе мы правда продолжаем нанимать под конвейер, просто конвейер стал быстрее.
Вы бы проверяли это live-кейсом на интервью или разговором о прошлых решениях?
ответить
коммент удалён
· 19.05
Вы привели очень хороший пример вопроса, благодарю!
Думаю, работать с кейсом, либо с разговорами о прошлом – личное предпочтение интервьюера. Я начинал о прошлом. Если там были кейсы, то обсуждал их
ответить
ответ удалён