Какие чувства возникают у вас при прочтении такого предложения?

«ИИ-агенты — будущее разработки ПО. Нам больше не нужны разработчики, замедляющие прогресс бизнеса».

Если вы сеньор-разработчик и считаете, что оно верное, то у меня появляются подозрения о вашем опыте (ниже я объясню, почему).

Но если вы не сеньор-разработчик, то я считаю, что вы правы.

А? Что здесь происходит?

Суть копирайтинга заключается в соотнесении послания и его аудитории.

Поэтому для меня, копирайтера, в этом случае одно и то же послание означает разное для двух разных аудиторий.

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

Но постойте! Многие опытные и известные разработчики тоже заявляют о том, что профессия разработчика умерла.

Как же так? Чья точка зрения верна? И в чём причина такого расхождения мнений?

Сеньор-разработчик — это профессиональный избегатель проблем

Когда я прихожу в команду, то встречаю там два типа сеньор-разработчиков.

Первый тип говорит:

«Я нашёл новый инструмент, он довольно неплох...»

«Компания <которая совершенна непохожа на нашу> делает так, поэтому…»

«Прочитай этот пост на HackerNews, в нём говорится, что это рекомендуемая практика, так что нам, вероятно, следует...»

Мне не нравится этот тип сеньоров. Они стремятся к собственной безопасности, уже много лет находятся в отрасли, вероятно, хорошо коммуницируют.

Но это не мой вайб.

А ещё есть такой тип сеньор-разработчиков:

«А нам действительно это нужно?»

«Что произойдёт, если мы не будем этого делать?»

«Можем мы обойтись тем, что у нас есть, а потом, возможно, вернуться к этому, если это станет более важным?»

Вот это мой тип. Избегатель, стремящийся к редуцированию и многократному использованию. Он хочет максимально избежать разработки.

Почему? Потому что в профессиональной разработке ПО он охотится на единственное чудовище: сложность.

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

Потому что, добавляя что-то в систему, рискуешь повысить её сложность.

Да, разумеется, это упрощённая картина. Есть сеньоры, превосходно справляющиеся с решением нерешённых задач и нахождением новых изобретательных архитектур.

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

Но почему? В чём недостаток сложности? И почему этого больше никто не понимает?

Остальная часть бизнеса боится неопределённости

Упрощая, можно сказать, что бизнес использует два цикла.

Ниже показан первый цикл; маркетологи, продажники, продакт-менеджеры, CEO — все они находятся в нём:

Основная цель этого цикла — пробовать и учиться. Бизнес хочет выводить продукты на рынок, а затем получать отзывы о том, получилось ли у него что-то ценное.

Для людей в этом цикле чудовище — это неопределённость.

И неопределённость жестока, потому что она не даёт гарантий работы любой стратегии. Если учесть также время (оплату труда маркетологов/продажников, выплаты фаундерам, данные для продакт-менеджеров), то кажется, что единственный способ снижения степени неопределённости до дедлайна — это как можно более быстрый вывод продукта на рынок. Чем больше ты выведешь на рынок, тем больше обратной связи получишь и тем больше (потенциально) снизишь неопределённость.

Этот цикл, с которого начинают все компании, зависит только от сырой скорости.

Но что происходит, когда у бизнеса появляются клиенты?

Сеньор-разработчиков больше волнует стабильность

А теперь второй цикл. Люди платят за обслуживание.

В этом цикле находятся сеньор-разработчики. Главная цель этого цикла — непрерывность и гарантии обслуживания.

Всё должно продолжать работать, оставаться понятным, отлаживаемым, исправимым и стабильным.

Сеньор-разработчиков волнует стабильность, потому что они отвечают за то, чтобы бизнес продолжал обслуживать клиентов.

А что подвергает риску всё это?

Сложность.

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

Повышение сложности = понижение стабильности = невыполнение обязательств сеньор-разработчика = очень плохо, нехорошо, платежи прекращаются, все печальны.

Итак, если цель первого цикла — снижение неопределённости, то цель второго — управление сложностью.

Почему это приводит к недопониманию?

Потому что когда у бизнеса появляются клиенты, оба цикла начинают работать одновременно. Бизнесу одновременно нужно исследовать возможности и обслуживать клиентов.

Наверно, теперь вы можете понять мой ответ на вопрос из заголовка поста.

В зависимости от того, в каком цикле вы находитесь, и формулируется ваша задача (мне кажется, именно поэтому так разделились мнения разработчиков об ИИ; некоторые из них больше работают в одном цикле, чем в другом)

Вот история людей из первого цикла:

А вот история сеньор-разработчика из второго цикла:

Эти истории не согласуются.

Чем больше запросов о создании нового и добавлении в систему получает сеньор-разработчик, тем сильнее он хочет ответить: «а как же сложность... затраты на поддержку… понятность системы… скорость продолжения разработки... продуктивность в долгосрочной перспективе…».

Но это никак не отвечает на потребности остальной части бизнеса в снижении степени неопределённости.

Диагноз копирайтера: нельзя объяснить чужую проблему при помощи собственной.

Рецепт копирайтера: нужно описать ваше решение, как решение и их проблемы.

Сеньор-разработчик не может донести важность, потому что объясняет свои проблемы с точки зрения управления сложностью, а должен бы выражать свои решения с точки зрения снижения неопределённости.

Признав, что остальная часть компании стремится к снижению неопределённости, сеньор-разработчик может воспользоваться своими знаниями, чтобы помочь.

А какой самый полезный навык для сеньор-разработчика? Нежелание создавать то, что не необходимо; способность находить возможность повторного применения того, что уже создано.

Вам нужно собрать данные опросов? Для этого есть Google Forms.

Нужно собрать совершенно новую фичу, чтобы протестировать её? Пробовали добавить кнопку в уже существующий UI и проверить, нажимают ли на неё пользователи?

Нужен новый сервис аналитики? Какое самое важное решение, для которого нам нужна аналитика? Можем ли мы начать с одного решения, одного графика, одной метрики?

Хотите испечь мне целый торт на день рождения? Просто воткните свечку в мой сэндвич.

Именно этому учатся сеньор-разработчики: тому, как давать людям нужное, с умом используя уже имеющееся ПО.

Но как донести это без необходимости писать целые сочинения?

Копирайтеры любят сводить несколько сигналов в одиночные фразы. Вот волшебная фраза, которую должен выучить любой сеньор-разработчик: «Можем мы попробовать кое-что ещё более быстрое?»

«Более быстрое» — это именно то, что им нужно; «кое-что» подразумевает другой способ достижения цели; «попробовать» подразумевает несовершенство, но в то же время и возможность того, что решения будет вполне достаточно.

Это идеально соответствует потребностям остальной части компании: скорость для снижения неопределённости; при этом сеньор-разработчик может принести пользу своим опытом: редуцировать, использовать повторно, а если и невероятно повезёт, то полностью избежать.

Вот и всё. Это мой ответ на заголовок поста: сеньор-разработчики говорят о сложности, хотя всех остальных волнует неопределённость.

Однако здесь есть большое «но»!

После появления ИИ всё это как будто становится бессмысленным, правда? Зачем редуцировать, использовать повторно и избегать? ИИ может создать так много за короткий промежуток времени.

Вообще-то, он пока не может справиться с задачей, которую по-прежнему выполняют сеньоры: брать на себя ответственность.

Сеньор-разработчики как редакторы, а не писатели

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

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

Если в систему добавляют код ИИ-агенты, джуны, менеджеры, инвесторы и их мамы, то скорость будет компенсироваться отказом от стабильности.

Бизнес в двух циклах выглядел так:

А вот, как влияет ИИ на эти два цикла:

Можно забыть о поддержании стабильности, ИИ — это откровенный дестабилизатор. Он снижает понимаемость, ремонтируемость, отлаживаемость и гарантированность.

И всё это он делает, не беря на себя ответственность.

Это плохо. В этом заключается основная тревога сеньор-разработчика, от которой отмахиваются.

К счастью, у сеньор-разработчика есть в запасе пара трюков, а именно разделение.

Очень долгое время разработчики ПО были единственными, кто мог создавать ПО. Они отвечали за оба цикла.

Это одна система для реализации двух целей.

Но что, если у нас было бы две системы, по одной на каждую цель?

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

Что, если бы у нас была одна система только для скорости? В ней могли бы работать те, кому важно реализовывать новое: ИИ-агенты, наш собственный сгенерированный и непроверенный код, джуны, маркетологи и так далее.

Можно назвать это «скоростной» версией системы. Она не должна быть понятной, её цель — реализовать всё достаточно хорошо, чтобы вывести на рынок для обратной связи.

А вторая система могла бы заняться стабильностью.

Можно назвать её «масштабной» версией. Она проектируется сеньор-разработчиками так, чтобы быть стабильной, понятной и масштабируемой.

Скоростная версия позволяет остальной части бизнеса продолжать учиться у рынка, пока сеньор-разработчики создают отстающую версию системы, тщательно проверенную и понятную.

Кроме того, на архитектуру «масштабной» версии будет влиять то, что сработало и не сработало в «скоростной» версии системы.

Фичи создаются в «скоростной» версии, а стабилизируются в «масштабной».

Возможно, непонятно, как это будет выглядеть на практике, но сам принцип заключается в том, чтобы реализовать разделение с качественной коммуникацией, объясняющей, что есть разница в стремлении к скорости и к стабильности.

Представьте, что вас попросили создать что-то амбициозное, а вы отвечаете:

«Хорошо, скоростная версия будет готова через три дня, а масштабная — примерно через шесть недель».

Они получают то, что им нужно: скорость и импульс. А вы получаете то, что нужно вам: наблюдения и архитектуру.

Возможно ли такое?

Что думаете, сеньор-разработчик ПО?

Или, может быть, скорее сеньор-редактор ПО?