Разработчик электроники и ПО для БПЛА дошёл до этапа, когда после MVP потребовалась воспроизводимая архитектура деплоя. Проект нетривиальный: Ubuntu Linux с патченным ядром и драйверами, радиомодули, сетевая маршрутизация, несколько ролей у одного устройства, собственный софт и утилиты. Claude Code получил доступ ко всему проекту — документам, скриптам, конфигам, тестам — и выдал развёрнутый план.
План выглядел осмысленно, но оказался не тем. Модель систематизировала всё найденное в проекте — фактически составила инвентаризацию компонентов. Это не то же самое, что план деплоя: список «что есть» и схема «в каком порядке и по каким слоям разворачивать» — принципиально разные артефакты. Повторные запросы с просьбой «систематизировать» делали ответ только аккуратнее, не меняя его природы.
| Слой | Содержимое |
|---|---|
| Base system | ОС, ядро, версия ядра, низкоуровневые зависимости |
| Platform layer | Радио, сеть, маршрутизация, системные сервисы |
| Device software | Основной софт устройства, оркестратор, прикладная логика |
| Extras | Тесты, диагностика, observability, дополнительные утилиты |
Проблема обнаружилась, когда автор явно описал нужную структуру: Base system (ОС, ядро, версия ядра, низкоуровневые зависимости) → Platform layer (радио, сеть, маршрутизация, системные сервисы) → Device software (основной софт, оркестратор, прикладная логика) → Extras (тесты, диагностика, observability). После этого Claude сгенерировал документ, пригодный к использованию. Модель не стала умнее — задача наконец получила форму.
Повторные уточняющие промпты делали ответ аккуратнее, но не меняли его суть.
Это иллюстрирует фундаментальное свойство LLM: модель заполняет незаданные параметры самостоятельно, опираясь на собственные представления о том, что «обычно имеется в виду». В embedded-деплое направление декомпозиции — от железа к прикладному слою — неочевидно для модели, обученной на широком корпусе текстов. Без явного указания Claude выбрал нейтральную стратегию: перечислить всё найденное.
Автор формулирует практическое правило: «плохой» ответ LLM полезен именно тем, что показывает, какие части задачи не были сформулированы. Каждый следующий промпт без уточнения структуры лишь полирует неправильный ответ. Чтобы этого избежать, в запросе стоит явно указывать контекст, цель, направление декомпозиции, слои системы, ограничения, ожидаемый артефакт и критерий проверки результата.
Подход применим шире embedded-разработки. Любая задача с неявной структурой — проектирование API, разбивка монолита на сервисы, составление технического задания — даст похожий эффект: LLM вернёт то, что статистически чаще всего следует за вашим запросом, а не то, что нужно конкретно вам. Промпт в этом смысле — не заклинание, а интерфейс к вашей собственной модели задачи.
