Evidence-based planning, или что не так с чистым SDD

TL;DR: Одно из самых недооцененных свойств AI-кодинга - это проектирование софта через ранние дешевые эксперименты.

Стандартный путь (часто) выглядит так: собрать весь input, скормить его в spec-driven framework или аналог, который нарежет все на тикеты, и погнали кодить агентами. Проблема в том, что спека, написанная до контакта с реальностью, фиксирует галлюцинации автора и агента о задаче, а формальность документа создает иллюзию продуманности.

Я делаю иначе, через контакт с реальностью как можно раньше. Сначала задаюсь вопросом, где больше всего белых пятен и ключевых развилок, и начинаю экспериментальное исследование: прощупываю границы интеграций, возможные подходы, варианты интерфейсов. Постепенно расширяю карту - от неопределенного к протестированному фактами (отсюда evidence-based), до состояния, где я могу сказать:
- "Этот кусок решен, вот здесь точно работает".
- "При интеграции мы получим ровно такой JSON, если возьмем эту альтернативу".
- "Протестил все семь вариантов - эти два показывают себя лучше всех, на цифрах".
- и т.д.

И только потом задачи - там теперь есть ссылки на проверенные решения, конкретные контракты и доказательная база под ними.

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

Это спайки, у которых сняли лимит

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

У практики проверять есть старое имя - спайк (spike), из методики экстремального программирования (XP): короткий эксперимент, цель которого - знание, а не продукт. Но спайк всегда был дорогим удовольствием, поэтому и оставался редкостью.

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

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

Вход и выход спайка

На входе один сформулированный вопрос ("что именно я хочу узнать/проверить") + релевантный контекст.

На выходе:
1. Решения - выбор из альтернатив с зафиксированным "почему" и "почему не остальные"
2. Контракты - фактические интерфейсы, схемы, форматы ошибок, лимиты, которые эксперимент выдал по факту
3. Границы проверенного - докуда дошел эксперимент и какие вопросы остались открытыми

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

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

---

Кстати, удешевление экспериментов уже не раз двигало целые дисциплины (тысячи нитей накаливания у Эдисона, аэродинамическая труба братьев Райт, A/B-тесты в вебе).

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

🔥 ➕ 🔁 @nobilix