Evidence-based SDLC: проверить дешевле, чем предположить

Код подешевел, а вместе с ним подешевел и прогон: агент сам пишет, запускает и приносит результат. Как я использую это до кода (спайки, симуляторы, разведка), после кода (сломать и доказать) и как храню то, что узнал, чтобы оно не испарилось

Рефат Аметов

Сооснователь Devstark и SpreadSimple

Refat Talks: Tech & AI

Главное за минуту

Код подешевел, а с ним и прогон: агент сам запускает код и приносит результат, поэтому проверить теперь дешевле, чем предположить.

Спека до контакта с реальностью записывает догадки. Сначала спайки на реальных данных и настоящих API, потом короткая спека на проверенном.

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

После кода агента просят сломать изменение, а в каждом PR ждут доказательства: что проверено, как и что осталось непроверенным.

Проверенное закрепляют тестом, а эксперименты, в том числе неудачные, записывают в журнал рядом с ADR.

Подешевел еще и прогон

Что код стало писать дешевле, говорят все. Только из этого совсем не следует, что весь SDLC кратно подешевел. Реже говорят, что подешевел прогон: агент сам запускает код и приносит результаты, а их можно использовать при проектировании и приемке. По моему опыту это одна из самых простых и самых сильных техник, которые вообще можно применить.

Мысль не новая. В экстремальном программировании еще в 1999-м был спайк, пробный прогон на случай неуверенной оценки: не уверен – выгоднее прогнать. Брукс советовал планировать, что первую версию вы выбросите. А Ройс, которому приписывают термин «водопад», в 1970-м предлагал делать все дважды, сначала прощупать на практике, потом переделать. То есть даже автор водопада, грубо говоря