Все, но не сразу: мастерство сосредоточенной декомпозиции

Привет, Я Пётр — разработчик приложения «Совкомбанк Инвестиции» для Android.

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

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

Ожидания от агентов

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

Чтобы на практике получить ту самую «ИИ-эффективность», необходимо ясно понимать, какую работу или ее часть можно делегировать ИИ-агенту.

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

В каких случаях работа с ИИ может не принести желаемого результата?

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

• Не даёте достаточного контекста: не указываете существующие паттерны, не объясняете ограничения системы.

• Перегружаете контекст: много вводной информации— это не всегда хорошо. Из-за перегрузки агент начинает «галлюцинировать» и теряться в действиях.

• Пропускаете этапы проверки, надеясь на «волшебный» результат с первого запроса.

Если вы совершаете какие-то из вышеперечисленных действий, попробуйте поступить так:

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

2. Проверяйте результат каждого шага до перехода к следующему.

3. Давайте ИИ контекст: примеры кода, ошибки, требования.

4. Итеративно уточняйте и исправляйте, а не генерируйте всё заново.

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

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

Проблема больших задач

Поручая ИИ масштабную задачу, многие требуют от него роли опытного разработчика, который с первого же запроса:

• Полностью понимает их кодовую базу

• Знает все принятые в команде соглашения

• Разбирается в предметной области проекта

• Учитывает принятые архитектурные решения

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

Типичные проблемы:

• Модель начинает делать необоснованные предположения

• Контекст предыдущих шагов теряется

• Сгенерированный код выглядит корректным, но не соответствует реальным требованиям

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

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

Решение: decomposed prompting

Decomposed prompting или сокращенно DecomP – это подход в области разработки промптов, при котором сложное задание или проблема разбивается на более мелкие, чётко сфокусированные подзадачи. Вместо того, чтобы давать одну объёмную монолитную инструкцию, вы формируете последовательность или древовидную структуру промптов, каждый из которых отвечает за решение конкретной подзадачи. При этом каждую из них можно обработать отдельным промптом.

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

Для разных типов подзадач допустимо задействовать специализированных агентов – отдельных ИИ‑моделей или модулей, оптимизированных под конкретные типы задач.

Ключевой принцип подхода заключается в представлении задачи не в виде «чёрного ящика», а цепочки прозрачных и контролируемых шагов, решающих определенные проблемы.

Пример сосредоточенной декомпозиции

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

Неудачный подход:

— Исправь ошибку ввода короткого кода в процессе регистрации клиента

Более удачный подход:

— Посмотри на это сообщение об ошибке. В чём её причина?
— Вот код файла MyGlitchyRegistrationApp.kt. Что нужно изменить?
— Напиши тест, который подтвердит, что исправление работает.
— Сделай коммит с описанием изменений, указанием, в чем была проблема и как ее исправили.

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

Почему это работает лучше?

Используя DecomP, мы:

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

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

• Обеспечиваем локализацию ошибок. Если что-то идёт не так, это происходит в небольшом изолированном фрагменте, который легко исправить или перегенерировать.

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

Ключевые аспекты

Не все задачи по программированию одинаково хорошо подходят для работы с ИИ. Предлагаю разделить их на три типа:

Тип 1: Узкие, прямолинейные задачи

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

Тип 2: Конкретные задачи, требующие контекста

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

Тип 3: Масштабные, открытые задачи

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

Четырёхшаговый процесс

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

1. Фиксирование ошибки и создание контекста

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

2. Анализ причины

   Просим агента разобраться в сути проблемы: «Вот ошибка: [вставить текст ошибки или отладочный журнал]. В чем причина ошибки?».

3. Внесение правок в код

   Показываем агенту конкретный фрагмент и запрашиваем решение: «Функция, в которой возникает ошибка – whereIsMyMoney в Salary.kt. Исходя из ошибки, что нужно изменить?».

4. Проверка и тестирование

   После исправления просим создать тест: «Напиши тест, который выявляет этот конкретный баг». Почему просим написать тест? Правильно: потому что любой баг – это тест который никто не написал.

Четыре сфокусированных взаимодействия дают четыре маленьких победы:

• Ошибка исправлена

• Проблема задокументирована

• Добавлено тестирование

• Выполнение ускорено по сравнению с решением задачи целиком

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

Почему небольшие шаги эффективнее

Исследования показывают: разработчики, использующие ИИ‑инструменты, часто тратят больше времени на проверку кода, чем экономят на его написании. Это верно в случае, когда агент генерирует большие блоки кода, требующие тщательного анализа.

Работая маленькими шагами, вы получаете:

• Быструю проверку – каждая ревизия занимает секунды, а не минуты.

• Простую отладку – каждый фрагмент изолирован, что упрощает поиск проблем.

• Понятный код – вы не перегружены объёмными блоками кода от агента, которые сложно осмыслить.

• Непрерывный прогресс – вы двигаетесь вперёд, не застревая на разборе сгенерированного агентом вывода.

Подходящий режим

Большинство агентов поддерживают несколько режимов работы. Таким образом агенты поддерживают подход к декомпозиции, описанный в первой части статьи. Как правило это: Chat, Plan и Agent. Каждый из режимов пригодится на своем этапе решения большой задачи.

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

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

Режим Chat

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

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

Режим Plan

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

Режим Agent

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

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

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

Разные агенты – разные режимы – разные модели

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

Срезание углов

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

Рабочие процессы

Это настраиваемые ИИ‑рабочие процессы или workflows, объединяющие промпты, правила и инструменты. Их цель – выполнять конкретные, часто повторяющиеся, шаблонные задачи. Подготовьте несколько рабочих процессов и разместите их вместе с кодом проекта, после чего они станут доступны всей команде. Большинство агентов поддерживают такую возможность, например, Kilo Code. Каждый рабочий процесс можно настроить для решения одной или нескольких схожих задач.

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

Горячие клавиши

Для переключения между различными режимами в большинстве агентов предусмотрены сочетания клавиш. Используйте их, и вы перейдете в нужный режим или запустите агента для планирования первых шагов. Горячие клавиши ускоряют работу в любой программе, агенты не исключение. В Intellij IDEA есть возможность переназначить горячие клавиши. Не стоит игнорировать такую возможность: это сделает работу.

Slash-команды

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

Подведем итог

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

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

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

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

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

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

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

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

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

Ссылки на материалы

1. LLMs Get Lost In Multi-Turn Conversation

2. Break Down Your Prompts for Better AI Results

3. Decomposed Prompting: A Modular Approach for Solving Complex

4. Decomposed Prompting: GitHub-repository

5. Crafting Effective Prompts for Agentic AI Systems: Patterns and Practices