Evidence-based planning, или что не так с чистым SDD TL;DR: Одно из самых недооцененных свойств AI-кодинга - это проектирование софта через ранние дешевые эксперименты. Стандартный путь (часто) выглядит так: собрать весь input, скормить его в spec-driven framework или аналог, который нарежет все на тикеты, и погнали кодить агентами. Проблема в том, что спека, написанная до контакта с реальностью, фиксирует галлюцинации автора и агента о задаче, а формальность документа создает иллюзию продуманности. Я делаю иначе, через контакт с реальностью как можно раньше. Сначала задаюсь вопросом, где больше всего белых пятен и ключевых развилок, и начинаю экспериментальное исследование: прощупываю границы интеграций, возможные подходы, варианты интерфейсов. Постепенно расширяю карту - от неопределенного к протестированному фактами (отсюда evidence-based), до состояния, где я могу сказать: - "Этот кусок решен, вот здесь точно работает". - "При интеграции мы получим ровно такой JSON, если возьмем эту альтернативу". - "Протестил все семь вариантов - эти два показывают себя лучше всех, на цифрах". - и т.д. И только потом задачи - там теперь есть ссылки на проверенные решения, конкретные контракты и доказательная база под ними. Ощущается это как стратегия в реальном времени: карта под туманом войны, и каждый прогон открывает участок - здесь проходимо, здесь обрыв, здесь дорога упирается в rate limit/неожиданную зависимость/и тд. Бонусом получаешь границу достаточно понятного куска, а его уже проще и проектировать, и верифицировать, и раздавать людям и агентам параллельно. Это спайки, у которых сняли лимит Вся традиционная инженерия построена на одном допущении: код дорого писать и еще дороже переписывать. Из него выросло много дефолтов, включая умозрительное проектирование на бумаге - проверить было непозволительно дорого. У практики проверять есть старое имя - спайк (spike), из методики экстремального программирования (XP): короткий эксперимент, цель которого - знание, а не продукт. Но спайк всегда был дорогим удовольствием, поэтому и оставался редкостью. Сейчас он стоит минуты/часы внимания: агенты не только пишут код, но и сразу исполняют его, документируя успехи, неудачи и подводные камни. Причем пачками и параллельно. Заметьте, я не предлагаю меньше думать и больше делать. Просто к думанию добавилась роскошь, которой раньше не было: проверить дешево вместо того, чтобы гадать. Вход и выход спайка На входе один сформулированный вопрос ("что именно я хочу узнать/проверить") + релевантный контекст. На выходе: 1. Решения - выбор из альтернатив с зафиксированным "почему" и "почему не остальные" 2. Контракты - фактические интерфейсы, схемы, форматы ошибок, лимиты, которые эксперимент выдал по факту 3. Границы проверенного - докуда дошел эксперимент и какие вопросы остались открытыми Код прогона можно выбросить (или оставить), но эти три вещи забираем. Они идут в план, в спеку и в тикеты - и поэтому реализация становится почти механической, и яснее, как ее верифицировать. Одна оговорка про параллельность. Она ценна, пока узкое место - генерация. Как только им становится ваша способность оценить результаты, каждая новая ветка дает отрицательную отдачу. --- Кстати, удешевление экспериментов уже не раз двигало целые дисциплины (тысячи нитей накаливания у Эдисона, аэродинамическая труба братьев Райт, A/B-тесты в вебе). Что касается софта - каждый раз убеждаюсь, что этот подход работает прекрасно, и что откладывать это невыгодно. Предполагать теперь дороже, чем проверить. 🔥 ➕ 🔁 @nobilix