Как изменились требования к разработчикам в эпоху AI: опыт техлида

Всем привет! Меня зовут Александр, я техлид в продуктовой компании.

Недавно один хороший знакомый набирал команду в стартап. Он приверженец подхода AI first и попросил меня помочь с наймом.

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

Сейчас мы переходим к новому уровню абстракции, и требования к сотрудникам меняются соответственно. В своей работе и pet-проектах я активно использую Cursor. За последние полгода у меня появилось понимание, как правильно использовать этот инструмент. Делюсь инсайтами.

Инсайт 1. Нет оправдания не использовать TDD и BDD

Если раньше такой подход требовал серьёзной дисциплины и усилий от команды, то теперь ИИ снимает боль с написания тестов. Не нужно вручную писать boilerplate, и TDD перестаёт быть утопией — тесты пишутся легко и быстро.

Важное уточнение: отдавая генерацию тестов нейросети, мы не получаем TDD автоматически. Дисциплина «тест до кода» остаётся за человеком. Но ИИ позволяет не бросить эту практику на полпути.

Как результат — низкие риски регресса. Как следствие, высокая стабильность.

Важный вывод: разработчик обязан разбираться в тестировании, понимать, что нейросеть предлагает качественные тесты, и избегает антипаттернов (например, «оракул», тестирование фикстур).

Инсайт 2. Чем проще, тем надежнее

Слабые модели (типа GPT-3.5 без настроенных правил) достаточно ленивы и стараются вносить исправления локально. Эта особенность приводит к тому, что ответственность быстро размазывается по коду. При многослойной архитектуре агенты теряются в контексте.

По моему опыту, количество слоёв не должно превышать 3-4. Нужно стремиться к максимально шаблонному коду на уровне архитектуры, что делает систему предсказуемой для ИИ. А вот на уровне реализации уже включается следующий инсайт.

Инсайт 3. Нужно хорошо знать алгоритмы

Вайбкодинг славен тем, что все решения отдаются на откуп ИИ. Как известно, любую инженерную задачу можно решить минимум тремя способами, и не все будут оптимальными. Понимание алгоритмов позволяет отбросить неэффективные варианты.

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

Инсайт 4. Самый опасный навык — не доверять красивому коду

Этот инсайт родился из практики. ИИ генерирует код, который компилируется, проходит тесты и выглядит идеально. Но он может делать (и часто делает) не то, что нужно, или содержать тонкую логическую ошибку.

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

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

Синьор

Должен обладать сильными Software Architect скиллами: знание шаблонов проектирования и архитектур, понимание отличий и trade-offs. Иначе код быстро превратится в неподдерживаемое макаронное изделие.

Прокачанные навыки код-ревью. Я использую субагентов для оценки архитектуры, регрессов и corner cases, но спорные решения всё равно остаются. Синьор должен иметь чёткие критерии хорошего кода и требовать их от нейросети.

Уверенное знание тестирования. Следить, чтобы сгенерированные тесты были точными, не тестировали сами себя и покрывали бизнес-сценарии.

Мидл

Нет необходимости требовать глубоких знаний конкретного фреймворка. Нужны инженерные навыки:

• знание шаблонов проектирования;

• знание принципов тестирования, понимание регрессов и corner cases;

• умение детально описать алгоритм;

• навык критического недоверия к коду, который сгенерировал ИИ;

• способность заметить, когда ИИ галлюцинирует или предлагает логически неверное решение.

Джун

С ИИ джуну не легче, а сложнее. Раньше он писал свой код и знал, за что отвечает. Теперь он проверяет чужой (сгенерированный) код и должен замечать ошибки, которых сам не совершил бы.

Требования:

• умение формулировать свои мысли (чтобы давать чёткие промпты);

• усидчивость — много времени тратится на ручную перепроверку сгенерированного кода;

• отсутствие слепого доверия к красиво выглядящему решению.

Что в итоге?

По этим критериям мы отобрали двух синьоров и двух мидлов. За первый месяц проект не развалился, а кодовая база осталась в состоянии, которое не стыдно показать другим людям. Главный урок, который я вынес: ИИ не снижает требования к разработчикам — он их смещает. Знание алгоритмов, тестирования и архитектуры стало важнее, чем знание конкретного фреймворка. А разработка вернулась к истокам — решению инженерных задач, а не борьбе с фреймворками.