Как эффективно соответствовать кодексу Клода

Повысьте производительность с помощью ваших программ магистратуры.

Делиться

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

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

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

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

Почему стоит сотрудничать с агентами по программированию?

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

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

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

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

• В вашем объяснении могут быть неясности.

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

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

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

Как наладить взаимодействие с вашими агентами по программированию

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

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

Агенты всегда выбирают решение по умолчанию.

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

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

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

Позвольте привести конкретный пример:

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

Однако в плохо организованном коде это не будет представлено в одном файле, а вместо этого поставщики вызовов LLM будут определены во многих разных файлах, и каждый файл будет содержать отдельный вызов LLM.

Это называется плохим разделением задач .

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

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

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

Если вы хотите узнать больше о рефакторинге кода, вы можете прочитать мою статью на эту тему на сайте TDS, ссылка на которую приведена ниже:

Как рефакторить код с помощью Claude Code

Главное преимущество рефакторинга в наше время заключается в том, что вы можете просто поручить это специалистам по программированию.

Активное использование планового режима

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

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

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

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

• То, что вы себе представляете
• Какие проблемы может выявить программа LLM в отношении того, что вы хотите реализовать?
• Как можно решить эти проблемы?

Предоставьте программисту как можно больше контекстной информации.

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

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

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

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

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

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

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

Чтобы этого избежать, необходимо предоставить агенту программирования как можно больше контекста. Например, агенту программирования следует предоставить доступ к:

• Стенограммы совещаний
• Каналы Slack и личные сообщения
• Заметки-подсказки

А также все остальные знания и контекст, которые могут быть полезны для LLM или агента программирования при выполнении реализации. Это предотвращает проблемы, когда агенту программирования не хватает контекста, что ухудшает его способность принимать решения.

Заключение

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

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

👋 Свяжитесь с нами

👉 Моя бесплатная электронная книга и вебинар:

🚀 Увеличьте свои инженерные знания в 10 раз с помощью магистратуры (бесплатный 3-дневный курс по электронной почте)

📚 Получите мою бесплатную электронную книгу «Модели визуального языка».

💻 Мой вебинар по языковым моделям зрения

👉 Найдите меня в социальных сетях:

💌 Substack

🔗 LinkedIn

🐦 X / Twitter

Эйвинд Кьосбаккен Посмотреть все Эйвинд Кьосбаккен

Источник: towardsdatascience.com