Какие чувства возникают у вас при прочтении такого предложения?
«ИИ-агенты — будущее разработки ПО. Нам больше не нужны разработчики, замедляющие прогресс бизнеса».
Если вы сеньор-разработчик и считаете, что оно верное, то у меня появляются подозрения о вашем опыте (ниже я объясню, почему).
Но если вы не сеньор-разработчик, то я считаю, что вы правы.
А? Что здесь происходит?
Суть копирайтинга заключается в соотнесении послания и его аудитории.
Поэтому для меня, копирайтера, в этом случае одно и то же послание означает разное для двух разных аудиторий.
Если вы сеньор-разработчик и уже поэкспериментировали со всеми этими агентами, скиллами, моделями и прочим, что потрясает воображение людей, и если ваша интуиция по-прежнему шепчет про ошибочность утверждений об устаревании вашей работы, то в этом посте я постараюсь вербализировать то, что говорит вам интуиция.
Но постойте! Многие опытные и известные разработчики тоже заявляют о том, что профессия разработчика умерла.
Как же так? Чья точка зрения верна? И в чём причина такого расхождения мнений?
Сеньор-разработчик — это профессиональный избегатель проблем
Когда я прихожу в команду, то встречаю там два типа сеньор-разработчиков.
Первый тип говорит:
«Я нашёл новый инструмент, он довольно неплох...»
«Компания <которая совершенна непохожа на нашу> делает так, поэтому…»
«Прочитай этот пост на HackerNews, в нём говорится, что это рекомендуемая практика, так что нам, вероятно, следует...»
Мне не нравится этот тип сеньоров. Они стремятся к собственной безопасности, уже много лет находятся в отрасли, вероятно, хорошо коммуницируют.
Но это не мой вайб.
А ещё есть такой тип сеньор-разработчиков:
«А нам действительно это нужно?»
«Что произойдёт, если мы не будем этого делать?»
«Можем мы обойтись тем, что у нас есть, а потом, возможно, вернуться к этому, если это станет более важным?»
Вот это мой тип. Избегатель, стремящийся к редуцированию и многократному использованию. Он хочет максимально избежать разработки.
Почему? Потому что в профессиональной разработке ПО он охотится на единственное чудовище: сложность.
Особые случаи, условия if, новые таблицы в базе данных, новые компоненты — всё это крайне неприятно. Сеньор-разработчик хочет, чтобы этого было как можно меньше, он тратит кучу времени на то, чтобы убедиться в абсолютной необходимости добавления нового кода.
Потому что, добавляя что-то в систему, рискуешь повысить её сложность.
Да, разумеется, это упрощённая картина. Есть сеньоры, превосходно справляющиеся с решением нерешённых задач и нахождением новых изобретательных архитектур.
Но в конечном итоге, если ты несёшь ответственность за работающую систему, тебя пугает сложность.
Но почему? В чём недостаток сложности? И почему этого больше никто не понимает?
Остальная часть бизнеса боится неопределённости
Упрощая, можно сказать, что бизнес использует два цикла.
Ниже показан первый цикл; маркетологи, продажники, продакт-менеджеры, CEO — все они находятся в нём:
Основная цель этого цикла — пробовать и учиться. Бизнес хочет выводить продукты на рынок, а затем получать отзывы о том, получилось ли у него что-то ценное.
Для людей в этом цикле чудовище — это неопределённость.
И неопределённость жестока, потому что она не даёт гарантий работы любой стратегии. Если учесть также время (оплату труда маркетологов/продажников, выплаты фаундерам, данные для продакт-менеджеров), то кажется, что единственный способ снижения степени неопределённости до дедлайна — это как можно более быстрый вывод продукта на рынок. Чем больше ты выведешь на рынок, тем больше обратной связи получишь и тем больше (потенциально) снизишь неопределённость.
Этот цикл, с которого начинают все компании, зависит только от сырой скорости.
Но что происходит, когда у бизнеса появляются клиенты?
Сеньор-разработчиков больше волнует стабильность
А теперь второй цикл. Люди платят за обслуживание.
В этом цикле находятся сеньор-разработчики. Главная цель этого цикла — непрерывность и гарантии обслуживания.
Всё должно продолжать работать, оставаться понятным, отлаживаемым, исправимым и стабильным.
Сеньор-разработчиков волнует стабильность, потому что они отвечают за то, чтобы бизнес продолжал обслуживать клиентов.
А что подвергает риску всё это?
Сложность.
Она делает систему менее понятной, отлаживаемой, исправимой и, в конечном итоге, менее стабильной.
Повышение сложности = понижение стабильности = невыполнение обязательств сеньор-разработчика = очень плохо, нехорошо, платежи прекращаются, все печальны.
Итак, если цель первого цикла — снижение неопределённости, то цель второго — управление сложностью.
Почему это приводит к недопониманию?
Потому что когда у бизнеса появляются клиенты, оба цикла начинают работать одновременно. Бизнесу одновременно нужно исследовать возможности и обслуживать клиентов.
Наверно, теперь вы можете понять мой ответ на вопрос из заголовка поста.
В зависимости от того, в каком цикле вы находитесь, и формулируется ваша задача (мне кажется, именно поэтому так разделились мнения разработчиков об ИИ; некоторые из них больше работают в одном цикле, чем в другом)
Вот история людей из первого цикла:
А вот история сеньор-разработчика из второго цикла:
Эти истории не согласуются.
Чем больше запросов о создании нового и добавлении в систему получает сеньор-разработчик, тем сильнее он хочет ответить: «а как же сложность... затраты на поддержку… понятность системы… скорость продолжения разработки... продуктивность в долгосрочной перспективе…».
Но это никак не отвечает на потребности остальной части бизнеса в снижении степени неопределённости.
Диагноз копирайтера: нельзя объяснить чужую проблему при помощи собственной.
Рецепт копирайтера: нужно описать ваше решение, как решение и их проблемы.
Сеньор-разработчик не может донести важность, потому что объясняет свои проблемы с точки зрения управления сложностью, а должен бы выражать свои решения с точки зрения снижения неопределённости.
Признав, что остальная часть компании стремится к снижению неопределённости, сеньор-разработчик может воспользоваться своими знаниями, чтобы помочь.
А какой самый полезный навык для сеньор-разработчика? Нежелание создавать то, что не необходимо; способность находить возможность повторного применения того, что уже создано.
Вам нужно собрать данные опросов? Для этого есть Google Forms.
Нужно собрать совершенно новую фичу, чтобы протестировать её? Пробовали добавить кнопку в уже существующий UI и проверить, нажимают ли на неё пользователи?
Нужен новый сервис аналитики? Какое самое важное решение, для которого нам нужна аналитика? Можем ли мы начать с одного решения, одного графика, одной метрики?
Хотите испечь мне целый торт на день рождения? Просто воткните свечку в мой сэндвич.
Именно этому учатся сеньор-разработчики: тому, как давать людям нужное, с умом используя уже имеющееся ПО.
Но как донести это без необходимости писать целые сочинения?
Копирайтеры любят сводить несколько сигналов в одиночные фразы. Вот волшебная фраза, которую должен выучить любой сеньор-разработчик: «Можем мы попробовать кое-что ещё более быстрое?»
«Более быстрое» — это именно то, что им нужно; «кое-что» подразумевает другой способ достижения цели; «попробовать» подразумевает несовершенство, но в то же время и возможность того, что решения будет вполне достаточно.
Это идеально соответствует потребностям остальной части компании: скорость для снижения неопределённости; при этом сеньор-разработчик может принести пользу своим опытом: редуцировать, использовать повторно, а если и невероятно повезёт, то полностью избежать.
Вот и всё. Это мой ответ на заголовок поста: сеньор-разработчики говорят о сложности, хотя всех остальных волнует неопределённость.
Однако здесь есть большое «но»!
После появления ИИ всё это как будто становится бессмысленным, правда? Зачем редуцировать, использовать повторно и избегать? ИИ может создать так много за короткий промежуток времени.
Вообще-то, он пока не может справиться с задачей, которую по-прежнему выполняют сеньоры: брать на себя ответственность.
Сеньор-разработчики как редакторы, а не писатели
Сеньор-разработчикам очень важно понимание системы, потому что понимание позволяет починить её, если что-то пойдёт не так. Оно позволяет осознанно дополнять её, когда системе нужно расти. И больше всего остального оно позволяет обеспечивать постоянное надёжное обслуживание платящих клиентов.
ИИ угрожает этой понимаемости. Он невероятно хорош в повышении скорости вывода продукта на рынок, но также он влияет и на второй цикл, за который ответственны сеньор-разработчики.
Если в систему добавляют код ИИ-агенты, джуны, менеджеры, инвесторы и их мамы, то скорость будет компенсироваться отказом от стабильности.
Бизнес в двух циклах выглядел так:
А вот, как влияет ИИ на эти два цикла:
Можно забыть о поддержании стабильности, ИИ — это откровенный дестабилизатор. Он снижает понимаемость, ремонтируемость, отлаживаемость и гарантированность.
И всё это он делает, не беря на себя ответственность.
Это плохо. В этом заключается основная тревога сеньор-разработчика, от которой отмахиваются.
К счастью, у сеньор-разработчика есть в запасе пара трюков, а именно разделение.
Очень долгое время разработчики ПО были единственными, кто мог создавать ПО. Они отвечали за оба цикла.
Это одна система для реализации двух целей.
Но что, если у нас было бы две системы, по одной на каждую цель?
Приведу аналогию: художественный автор стремится как можно быстрее завершить первый черновик, чтобы позже извлечь из него нужное и избавиться от ненужного. После первого быстрого процесса написания происходит редактирование. Задача редактора — взять из текста то, что работает, и оформить это в целостный результат.
Что, если бы у нас была одна система только для скорости? В ней могли бы работать те, кому важно реализовывать новое: ИИ-агенты, наш собственный сгенерированный и непроверенный код, джуны, маркетологи и так далее.
Можно назвать это «скоростной» версией системы. Она не должна быть понятной, её цель — реализовать всё достаточно хорошо, чтобы вывести на рынок для обратной связи.
А вторая система могла бы заняться стабильностью.
Можно назвать её «масштабной» версией. Она проектируется сеньор-разработчиками так, чтобы быть стабильной, понятной и масштабируемой.
Скоростная версия позволяет остальной части бизнеса продолжать учиться у рынка, пока сеньор-разработчики создают отстающую версию системы, тщательно проверенную и понятную.
Кроме того, на архитектуру «масштабной» версии будет влиять то, что сработало и не сработало в «скоростной» версии системы.
Фичи создаются в «скоростной» версии, а стабилизируются в «масштабной».
Возможно, непонятно, как это будет выглядеть на практике, но сам принцип заключается в том, чтобы реализовать разделение с качественной коммуникацией, объясняющей, что есть разница в стремлении к скорости и к стабильности.
Представьте, что вас попросили создать что-то амбициозное, а вы отвечаете:
«Хорошо, скоростная версия будет готова через три дня, а масштабная — примерно через шесть недель».
Они получают то, что им нужно: скорость и импульс. А вы получаете то, что нужно вам: наблюдения и архитектуру.
Возможно ли такое?
Что думаете, сеньор-разработчик ПО?
Или, может быть, скорее сеньор-редактор ПО?