Как Claude Code помог увидеть, что проблема была не в LLM, а в постановке задачи для embedded-деплоя
Один из моих крупных бизнес-проектов - разработка электроники и софта для БПЛА. Дошел до момента, когда на железе после MVP надо стало развернуть корректную воспроизводимую архитектуру деплоя. Конечно, я стал делать это Клодом. Для этого я попросил обнюхать весь проект.
Для понимания: проект действительно многосторонний. Ubuntu Linux, патченное ядро и драйвера, радио, сеть, несколько ролей у устройства, пачка собственного софта и утилит. Claude прочитал документы, нашёл скрипты, конфиги, тесты и выдал вполне осмысленный план.
Проблема была в том, что это был не план деплоя, а аккуратная раскладка всего, что он нашёл в проекте.
Снаружи похоже. В работе — не то.
Я попросил его систематизировать ответ. Стало еще аккуратнее, но не правильнее.
Тут и обнаружилась настоящая ошибка: я попросил результат, но не описал много необходимых деталей.
Для embedded-деплоя направление было таким:
1. Base system OS, kernel, kernel version, низкоуровневые зависимости 2. Platform layer радио, сеть, маршрутизация, системные сервисы 3. Device software основной софт устройства, оркестратор, прикладная логика 4. Extras тесты, диагностика, observability, дополнительные утилиты
Когда я явно описал эту схему, Claude выдал документ, который уже можно было использовать.
Не потому что модель внезапно стала умнее, а потому что задача наконец получила форму.
Промпт — это не заклинание. Это интерфейс к вашей модели задачи.
Если не сказать, как раскладывать задачу, LLM разложит её по-своему, дополнив все, что вы не указали, но реально нужно для решения задачи, своими измышлениями.
Поэтому подчас кажущийся плохим ответ LLM обычно даже полезен: он показывает, какие части задачи вы не сформулировали.
В моём случае Claude не столько ошибся, сколько честно продолжил мою недосказанную мысль. Своим способом.
Я попросил архитектуру, но не объяснил, в каком направлении раскладывать систему. И пока это направление не появилось, каждый следующий промпт только делал неправильный ответ аккуратнее. Не ведитесь на это!
Из моего опыта, в тч из текущего кейса видно, что самый "правильный" способ получить желаемое, явно указать:
Контекст Цель Направление декомпозиции Слои Ограничения Ожидаемый артефакт Проверка результата
Архитектура начинается не тогда, когда LLM пишет первый абзац. Она начинается, когда вы решаете, как раскладывать систему.
P.S. На самом деле, если честно, я все равно продолжаю работать в своем стиле: кидаю первичный запрос, через пару промтов понимаю, куда двигаться, формулирую корректно, и далее мы идем в нужном направлении. Есть люди, которые сначала выдают всю схему и сразу двигаются, куда надо. Каждому свое 🤷♂️
