Проблема командного использования LLM
LLM-ассистенты для программирования продемонстрировали значительную ценность, однако преимущественно для отдельных разработчиков. В командном контексте возникает принципиальная сложность: промпты не версионируются, не воспроизводятся и не становятся частью общего технического знания команды. Каждый разработчик работает в своей манере, без общих стандартов — результат непредсказуем и не поддаётся ревью.
Именно с этой проблемой столкнулась внутренняя ИТ-служба Thoughtworks, используя LLM-ассистентов для своих команд. Ответом стала методология SPDD, призванная сделать изменения, вносимые с помощью LLM, управляемыми, проверяемыми и воспроизводимыми.
Принципы SPDD
Ключевая идея SPDD — рассматривать промпты как артефакт первого класса. Промпты хранятся вместе с кодом в системе контроля версий (VCS, например Git), что позволяет их ревьюить, изменять и воспроизводить — как любой другой программный артефакт. Это принципиально отличает подход от стихийного использования LLM через чат, когда история запросов теряется.
Кроме сугубо технической функции, промпты в SPDD выполняют роль связующего звена между разработкой и бизнесом. Зафиксированный и версионированный промпт описывает не только техническую задачу, но и бизнес-контекст, в котором она возникла, — что делает намерения команды явными и прослеживаемыми.
В статье описывается простой пример рабочего процесса по методологии SPDD; детали реализации опубликованы на GitHub.
Ключевые навыки разработчика
Мы обнаружили, что разработчикам для эффективной работы в рамках SPDD необходимы три ключевых навыка.
Первый — согласованность (consistency): единообразное применение промптов в рамках команды, следование общим шаблонам и стандартам формулировок. Без этого преимущество командного подхода теряется.
Второй — подход «сначала абстракция» (abstraction-first): задача формулируется на уровне намерений, а не конкретных инструкций по реализации. Разработчик описывает что нужно сделать — LLM берёт на себя детали того, как именно это реализовать.
Третий — итеративный анализ: оценка результата каждого шага перед переходом к следующему. Такой подход обеспечивает контроль над процессом и позволяет вовремя скорректировать направление, не накапливая ошибок.
