Nocode умер, да здравствует nocode
Всю дорогу разработчики пытались упрощать создание программ. Начинали с Assembler, с каждым новым языком программирования повышали уровень абстракции, создавали библиотеки / фреймворки для упрощения и ускорения разработки.
В итоге мы дошли от Assembler до Python, Go, TypeScript и других языков. Попытались пойти дальше и сделать инструменты nocode — ещё одну абстракцию, которая позволит создавать системы не программистам.
В итоге получали очень нишевый инструмент автоматизации или очередной язык программирования мышкой с проблемами версионируемости и наблюдаемости. Характерный пример — n8n. Кто на нём пытался собрать что-то больше прототипа, неизбежно сталкивался с множеством проблем, которые решались большими костылями.
С приходом кодинговых агентов целесообразность в ноукоде драматически упала: агенты кратно лучше работают с кодом, чем с платформами ноукода, е2е реализуют более сложные системы без болей ноукода, так как системы построены на коде, для которого придумали механизмы версионирования, стабильного обновления и наблюдаемости.
Но все же возникает вопрос, как построить систему с идеологией ноукода, где разрабатывают и обновляют не программисты, есть простой деплой без девопсов и наглядная визуализация. При этом без минусов ноукода, описанных выше.
Этот подход — Spec-Driven Development.
Давайте вспомним подход enterprise-компаний: есть бизнес аналитики, которые формируют требования и скоуп, есть системные аналитики и архитекторы — они придумывают, как система вписывается в текущий ландшафт и взаимодействует с другими системами. Программисту в таких компаниях остаётся транслировать проработанные требования в код, доработав детали, которые не учли на этапе проектирования.
В итоге получается, что текущие процессы компании уже заточены под формирование требований и только процесс создания кода остаётся всё ещё на людях. А что, если принять документацию как код, и на её основе генерировать код с помощью агентов.
В итоге мы получим новый уровень абстракции nocode в виде спецификации и детерминированную реализацию в формате кода и тестов, которая лишена минусов ноукод-систем. При этом полностью отходим от участия кодера (намеренно использовал эту формулировку вместо «разработчика») в создании кода.
Возникает справедливое возражение: агенты же нейрослоп кодовый генерируют. Через некоторое время это невозможно будет поддерживать.
Да, всё так. Поэтому нужно строить принципы-правила-навыки, по которым агент будет работать. То есть задача разработчика смещается от ручной трансляции требований из спецификации в код в создание конвейера для агентов, мониторинга качества «продукции» и оперативного реагирования на нарушение технологического процесса.
Как это реализовать, поделюсь в следующем посте. Чтобы сузить скоуп, расскажу про агентские автоматизации, а не системы общего назначения.
#александр_опрышко
Всю дорогу разработчики пытались упрощать создание программ. Начинали с Assembler, с каждым новым языком программирования повышали уровень абстракции, создавали библиотеки / фреймворки для упрощения и ускорения разработки.
В итоге мы дошли от Assembler до Python, Go, TypeScript и других языков. Попытались пойти дальше и сделать инструменты nocode — ещё одну абстракцию, которая позволит создавать системы не программистам.
В итоге получали очень нишевый инструмент автоматизации или очередной язык программирования мышкой с проблемами версионируемости и наблюдаемости. Характерный пример — n8n. Кто на нём пытался собрать что-то больше прототипа, неизбежно сталкивался с множеством проблем, которые решались большими костылями.
С приходом кодинговых агентов целесообразность в ноукоде драматически упала: агенты кратно лучше работают с кодом, чем с платформами ноукода, е2е реализуют более сложные системы без болей ноукода, так как системы построены на коде, для которого придумали механизмы версионирования, стабильного обновления и наблюдаемости.
Но все же возникает вопрос, как построить систему с идеологией ноукода, где разрабатывают и обновляют не программисты, есть простой деплой без девопсов и наглядная визуализация. При этом без минусов ноукода, описанных выше.
Этот подход — Spec-Driven Development.
Давайте вспомним подход enterprise-компаний: есть бизнес аналитики, которые формируют требования и скоуп, есть системные аналитики и архитекторы — они придумывают, как система вписывается в текущий ландшафт и взаимодействует с другими системами. Программисту в таких компаниях остаётся транслировать проработанные требования в код, доработав детали, которые не учли на этапе проектирования.
В итоге получается, что текущие процессы компании уже заточены под формирование требований и только процесс создания кода остаётся всё ещё на людях. А что, если принять документацию как код, и на её основе генерировать код с помощью агентов.
В итоге мы получим новый уровень абстракции nocode в виде спецификации и детерминированную реализацию в формате кода и тестов, которая лишена минусов ноукод-систем. При этом полностью отходим от участия кодера (намеренно использовал эту формулировку вместо «разработчика») в создании кода.
Возникает справедливое возражение: агенты же нейрослоп кодовый генерируют. Через некоторое время это невозможно будет поддерживать.
Да, всё так. Поэтому нужно строить принципы-правила-навыки, по которым агент будет работать. То есть задача разработчика смещается от ручной трансляции требований из спецификации в код в создание конвейера для агентов, мониторинга качества «продукции» и оперативного реагирования на нарушение технологического процесса.
Как это реализовать, поделюсь в следующем посте. Чтобы сузить скоуп, расскажу про агентские автоматизации, а не системы общего назначения.
#александр_опрышко