Во-первых, идея о последовательности действий при обучении кого-либо чему-либо:

1. Установить датчик. Это то же самое, что измерять состояние, получать метрики “как есть”. Датчик устанавливается путем объяснения понятия и механизма/алгоритма измерений.
2. Настроить актуатор. Это про способы изменения целевой (измеряемой датчиком) величины. Какие действия приводят к ее увеличению, а какие - к уменьшению. Здесь практика и отработка этих действий.
3. Управлять величиной. Здесь речь идет о целенаправленном изменении величины, подозреваю, что обязательно в каком-то высокоуровневом контексте, потому что само по себе изменение величины вряд ли важно, оно важно для чего-то еще. Тут, вероятно, нужно учитывать наличие нескольких петель обратной связи с разным временем “замыкания”.

И вот ровно эта же последовательность неявно присутствует и в другом тексте Левенчука, про современное понимание архитектуры систем. Точнее, даже, наверное, не в самой этой статье, а в книгах, на которые статья ссылается (не читал их еще, поэтому и “наверное”). Там речь идет о том, что все архитектурные решения (на самом деле не только архитектурные) должны быть обложены метриками, и должны изменять целевые характеристики предсказуемым образом. Очень похоже на этот общий алгоритм.

Для меня ценность этого алгоритма в том, что:

1. Это фильтр для отсеивания “решений ради решений”. Давайте будем делать X вместо Y. Обязательно будем, только сначала покажите, на что (целевая величина) это должно повлиять и каким образом (актуатор и действия), как мы это замерим (установка датчика) и как поймем, что достигли желаемого результата. А перед этим еще бы хорошо посмотреть на место этого изменения в более высокоуровневом контексте. Не можете это все объяснить? Ну тогда нам пока рано делать X вместо Y.
2. Это формализация драйверов изменений где угодно. В принципе, если какая-то идея прошла предыдущий фильтр, это значит, что она хорошо формализована с точки зрения отслеживания изменений. Даже на уровне работы с исходным кодом такой подход вполне возможен. Допустим, мы вносим какое-то изменение в поведение программы. Инженерная эвристика говорит, что Обязательно следовать OCP при изменениях кода. Обложим код метриками, чтобы понимать, насколько сейчас код не приспособлен к изменениям, посчитаем количество условных операторов, количество интерфейсов/абстракций, размер классов в области, относящейся к требуемым изменениям. Программисты вроде как должны уметь изменять эти величины, рефакторить код, что должно привести метрики к желаемым значениям. Я настолько формализованно о коде не думаю, возможно, часть этих размышлений уже уехала в неосознанную компетентность, поэтому может оказаться полезным вытащить их обратно в сознание.