ИИ нужны молодые разработчики и опытные разработчики
Искусственный интеллект не даст главный эффект, если просто прикрутить агентов к старым рабочим процессам. Он появится, когда люди, не связанные этими процессами, будут работать вместе с теми, кто понимает, зачем они вообще существуют.
Предприятия всё чаще вкладывают в ИИ огромные суммы, но почти ничего не получают взамен. Отчасти это может быть связано с тем, что изменения ведут не те люди.
Как я уже писал раньше, ИИ вряд ли уничтожит разработчиков; скорее он изменит то, что мы от них ждём. Например, мы снова и снова спрашиваем, нужны ли junior-разработчики в мире, где large language models могут писать код быстрее и дешевле. Но при этом упускаем из виду, что именно эти более молодые разработчики и их относительная неопытность могут оказаться тем, что нужно, чтобы переписать правила разработки ПО.
Эта мысль пришла ко мне, когда я читал размышления James Governor о том, что Ben Griffiths написал о нашей привычке путать возраст с авторитетом. Griffiths вспоминал доклад на конференции, где спикер пытался пристыдить молодую аудиторию за то, что она не узнаёт некоторых старших мужчин, сформировавших вычислительную отрасль. Ирония, как заметил Ben, в том, что многие из этих «старых мужчин» сделали свою эпохальную работу, когда были моложе тех, кого они поучали. Bill Joy написал vi в 22 года, John Carmack создал Doom в 23, Linus Torvalds выпустил Linux в 22 и так далее. Многие титаны отрасли внесли свои главные вклады задолго до того, как у них появился десятилетний опыт.
Смысл не в том, что молодые умнее. Это не так. И не в том, что ради успеха в ИИ нужно игнорировать более опытных разработчиков. Это глупо. Скорее, мысль Griffiths в более широком смысле верна: в начале больших сдвигов опыт может быть палкой о двух концах. Он помогает видеть риски, но может и сделать слишком уверенным в старых подходах. Самые успешные компании найдут способ сочетать молодую изобретательность с опытными ограничителями.
Фабрика сама себя не перестроит
Недавно Zara Zhang сослалась на классическую работу Paul David 1990 года «The Dynamo and the Computer» как на способ понять, почему столько компаний «внедрили» ИИ, но почти ничего не показали в ответ. Упрощённо аргумент David таков: электричество не преобразило фабрики сразу. Долгое время фабрики просто заменяли центральную паровую машину электродвигателем, сохраняя ту же планировку, те же рабочие процессы и те же допущения.
Электричество было новым, но мы в значительной степени подавили его потенциал, втиснув его в старые фабричные системы.
Крупные выигрыши в производительности появились позже, когда фабрики перестали воспринимать электричество как более чистую паровую машину и начали проектировать работу вокруг небольших двигателей, распределённых по всему предприятию. Как только у каждой машины мог быть свой двигатель, фабрике больше не нужно было организовываться вокруг одного приводного вала. Работу можно было перестроить вокруг потока производства.
Это неплохое описание того, где сейчас многие компании находятся с ИИ. Сегодня предприятия покупают тысячи лицензий на copilot, встраивают agents в существующие приложения и затем удивляются, почему результаты такие неровные, как я уже писал. Это всё равно что заменить паровую машину электрической и объявить, что работа по модернизации ИИ завершена. Нет. Даже близко нет.
Реальная отдача придёт не от того, что ИИ будет чуть быстрее писать те же задачи. Она придёт от изменения того, как команды определяют работу и как именно разработчики строят продукты. «Фабрика» должна измениться.
И вот неудобный вопрос: кто с наибольшей вероятностью построит новую фабрику?
Опыт работает в обе стороны
Здесь-то опытные разработчики и становятся особенно важны. Очень.
Как я недавно отмечал, в эпоху agents инженерное суждение важнее, чем когда-либо. В конце концов, ИИ упрощает генерацию кода, но более простая генерация кода может обернуться более простым генератором технического долга. Значит, ограничивающим фактором становится уже не столько вопрос «можем ли мы что-то создать?», сколько «можем ли мы создать правильную вещь, в правильном месте, с правильными ограничениями?». Иными словами, нужен вкус.
Старшие инженеры часто лучше видят такие ограничения, потому что опыт даёт им этот самый «вкус». Они знают, зачем существует странное правило валидации, и помнят клиента, который зависел от недокументированного поведения. Они понимают, почему простое изменение schema может превратиться в миграцию на несколько недель.
Но у опыта есть и теневая сторона: он может заставлять текущий процесс казаться неизбежным. Senior-инженер может видеть в AI assistant лишь более быстрый autocomplete, потому что так проще встроить ИИ в уже существующую ментальную модель. Junior-разработчик, менее привязанный к старому workflow, может задать более интересные вопросы: зачем вообще мы делаем эту задачу? Почему spec не является исполняемым? Почему agent не может сначала сгенерировать test harness?
Дело не в том, что более опытные разработчики не знают этих вопросов. Скорее, у них может просто не хватать энергии, чтобы, образно говоря, rage against the machine.
Ценность неопытности
Худший способ использовать junior-разработчиков в эпоху ИИ — считать их более дешёвой версией senior-разработчиков. Это и раньше было плохой идеей, но ИИ делает её ещё хуже. Если задача звучит так: «возьми эту задачу, сгенерируй немного кода и отправь senior на ревью», junior-разработчик превращается в человеческую обёртку вокруг coding assistant. Это не помогает никому. Junior почти ничему не учится, senior тонет в ревью, а предприятие получает больше кода, а это, как я уже говорил, едва ли хорошо.
Вместо этого junior-разработчикам нужно дать пространство для изучения новых workflow, при этом сохранив ровно столько контроля со стороны опытных коллег, сколько нужно. Это может означать, что таким более молодым разработчикам дают интересные вопросы, на которые нужно ответить, например:
- Как бы мы перестроили onboarding, если бы у каждого internal API был AI-readable contract и действительно работающие примеры?
- Как бы мы изменили code review, если бы agent при каждом pull request создавал сводку изменений, evidence тестов, риск зависимости и план rollback?
- Как бы мы строили функции, если бы product requirements писались как executable acceptance tests, а не как расплывчатый текст?
- Как бы мы уменьшили toil, если бы agents могли безопасно выполнять рутинные миграции, обновления зависимостей или incident triage в чётко определённых границах?
Это не игрушечные задачи. Это не «junior work». Это как раз тот самый redesign процессов, который предприятиям нужен, но которого они обычно избегают, потому что все слишком заняты бегом по существующему колесу.
Найти баланс
Так что же должны делать руководители инженерных команд? Во-первых, перестать воспринимать внедрение ИИ как индивидуальное соревнование по продуктивности. Похоже, мы быстро уходим от идеи, что «много tokens» означает «отличный инженер», но сам факт, что мы вообще флиртовали с этой идеей, уже показателен. Мне нравится, как Santiago Valdarrama расправляется с этой vanity metric: «Измерять продуктивность ИИ количеством написанных строк — глупая ошибка. Однажды все будут утверждать, что всегда были против этого». Вместо этого нужно спрашивать: «Какая часть нашего software delivery process больше не имеет смысла?» Самые большие выгоды от ИИ появятся тогда, когда мы изменим то, как мы описываем, тестируем, ревьюим и отправляем software.
Во-вторых, смешивайте команды AI workflow. Нет, не комитеты и не центры excellence, производящие PowerPoint. Я говорю о том, чтобы объединять двух-трёх более молодых разработчиков, уже свободно работающих с AI-native tools, с двумя-тремя senior-инженерами, которые понимают production, security, architecture и организационные ограничения. А затем давать им реальный workflow на переработку, например обновление зависимостей или создание тестов.
В-третьих, сделайте роль senior-инженера меньше про то, чтобы говорить «нет», и больше про определение guardrails, внутри которых другие смогут говорить «да». Я уже писал, что golden paths — ключ к эффективному использованию ИИ. Хорошие senior-инженеры должны определять paved roads: одобренные паттерны, требования к тестам, стандарты observability и так далее. А затем пусть junior-разработчики и agents быстро двигаются внутри этих границ.
В-четвёртых, поощряйте удаление. Возможно, это самый важный пункт. Возвращаясь к метафоре с электричеством на фабрике: мы провалимся в AI modernization, если просто добавим ИИ, не убрав устаревшие процессы.
Приведите всех к столу
Будущее разработки ПО не достанется только молодым. И не достанется только старым. Оно достанется командам, которые объединят сильные стороны и тех и других.
Более молодые разработчики часто приносят нетерпение. Им труднее принимать существующий workflow как священный. Они охотнее пробуют необычные инструменты, комбинируют их неожиданными способами и задаются вопросом, почему enterprise-разработка ПО больше похожа на ритуализированное ожидание разрешения.
Опытные разработчики приносят judgment. Они знают, что у software есть пользователи, аудиторы, атакующие, бюджеты, latency, история и последствия. Они знают, что правильный ответ часто скучен, а скучное — это хорошо.
Предприятиям нужны и те и другие. Им нужен разработчик, который спрашивает, почему фабрика всё ещё организована вокруг старого drive shaft, и им нужен разработчик, который знает, какие машины убьют человека, если сдвинуть их неосторожно. Иными словами, каждой команде разработки нужны люди, которые знают, зачем существует старая система, а также те, кто этого не знает.
Материал — перевод статьи с английского.