Три навыка, которые важны, когда AI пишет код

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

Написание кода всегда было самой трудоемкой по времени и ресурсам задачей в разработке ПО. AI меняет это быстрее, чем большинство инженерных команд успевает перестроиться. Инструменты вроде Claude Code и Cursor уже берут на себя значительную часть создания кода, освобождая разработчиков для работы с требованиями, архитектурой и дизайном.

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

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

Больше, чем код: как овладеть искусством запроса

Инструменты трансляции ПО, такие как компиляторы и ассемблеры, сопоставляют высокоуровневое описание кода с более низкоуровневым представлением, пригодным для выполнения. Появление таких слоев стало первым серьезным скачком в продуктивности программирования. AI prompt engineering — это следующее поколение многоуровневого программного обеспечения для трансляции, которое располагается над компилятором и ассемблером. С AI-генерацией кода акцент сместится с написания хорошего кода на написание хороших запросов.

Что делает запрос хорошим? Правильный контекст. А что обеспечивает лучший контекст? Прежде всего разработчик должен хорошо понимать задачу, которую должна выполнять программа. Если нужно написать типичный модуль в составе более крупной системы, запрос должен охватывать:

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

Как системный дизайн формирует контекст

Для новых инициатив контекст для такого модуля должен браться из детального системного дизайна. Системный дизайн — это по сути чертеж программного обеспечения, который создается путем разбиения общего проекта на более мелкие, отдельные части, называемые модулями. Каждый модуль отвечает за выполнение конкретной функции, которую должно обеспечивать ПО. В микросервисных реализациях domain-driven design разбивает бизнес-требования на отдельные подсферы, которые можно сопоставить с микросервисами.

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

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

Confluent

Хотя один проход проектирования иногда может сработать, чаще разработчикам приходится итеративно дорабатывать дизайн, чтобы получить лучший результат. На это указывали многие эксперты по ПО, но, пожалуй, лучше всего это сформулировал известный компьютерный ученый Fred Brooks: «Планируйте выбросить один вариант — все равно придется».

Confluent

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

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

AI-инструменты трансляции могут сделать нас продуктивнее, но при этом несут риск, что мы станем ленивыми и зависимыми от них. Недавнее исследование показало, что написание эссе с помощью LLM снижало когнитивные затраты пользователя, связанные с работой, по сравнению с теми, кто писал без LLM. Этот эффект назвали «cognitive debt».

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

Современное программирование и AI-инструменты

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

Писать оптимизированный ассемблерный код уже не считается хорошим использованием времени, потому что компиляторы справляются с этим очень хорошо. Но до недавнего времени умение писать хороший код для компилятора или runtime-движка на Java, Go или Python было важным навыком. На самом деле эти навыки останутся важными и по мере того, как LLM будут поддерживать генерацию кода, потому что разработчикам все равно придется просматривать сгенерированный код и проверять, соответствует ли вывод LLM определенным стандартам. Опытные разработчики, которые пишут код много лет, уже обладают этими навыками. И новые, и действующие разработчики смогут учиться и расширять знания, взаимодействуя с LLM-инструментами, которые знакомят их с новыми техниками и идеями.

Нам нужно найти аналог силовой тренировки для кодирования: такой подход, который частично заменяет прямое написание кода, но сохраняет понимание и здравое суждение по отношению к коду, который выдает LLM. Куда направить мозг, чтобы избежать cognitive debt?

Как избежать опасности cognitive debt

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

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

Во-вторых, смысл prompt engineering — давать LLM контекст. Значит, ключом становится создание этого контекста и умение понимать и оценивать сгенерированный код. Помимо сохранения существующих навыков работы с языками и кодом, ИТ-специалистам следует уделять внимание и другим элементам жизненного цикла, особенно требованиям, архитектуре и дизайну, чтобы у них был качественный контекст для запросов.

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

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

Чтобы оставаться конкурентоспособным, нужно понимать, что планка будет повышаться. Исторически исследования показывали, что самые продуктивные индивидуальные разработчики уже примерно в 10 раз эффективнее наименее продуктивных, а лучшие команды — примерно в пять раз сильнее самых слабых. AI-инструменты могут увеличить эти различия еще в два или три раза, еще сильнее расширив разрыв в продуктивности. Многие из таких высокопродуктивных команд будут работать на ваших конкурентов.

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

Случайная и сущностная сложность — почему AI не может быть серебряной пулей

Некоторые утверждают, что AI существенно повысит продуктивность разработки ПО. Они представляют будущее, в котором разработчикам достаточно написать несколько запросов, а LLM создаст софт, способный заменить существующие SaaS-продукты. Но, как утверждал Fred Brooks в знаменитой статье 1986 года «No Silver Bullet», это по-прежнему невозможно из-за двух типов сложности, которые остаются: случайной сложности и сущностной сложности.

Случайная сложность, или «случайности»

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

Сущностная сложность, или «сущность»

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

AI не может быть серебряной пулей из-за inherent complexity программного обеспечения. Даже если бы вы могли свести время на все случайные задачи к нулю, именно сущностные задачи все равно останутся главным вызовом и будут занимать большую часть усилий. Тем не менее AI — мощный инструмент. Если использовать его правильно для управления сложностью и исследования пространства дизайна, он может существенно повысить продуктивность команд и качество разрабатываемого ПО.

—

Материал — перевод статьи с английского.

Оригинал: Three skills that matter when AI handles the coding