SPDD (Structured Promt Driven Development)
https://martinfowler.com/articles/structured-prompt-driven/
Пришла пора подвести итоги использования SPDD, как самостоятельного, так и в рамках консалтинга.
Я не увидел в SPDD чего-то, что бы фундаментально меняло подход к разработке, в сущности – это инструмент для того, чтобы обуздать и дисциплинировать работу ненадежным, стохастическим генератором кода (хотя Мартин Фаулер иного мнения - «material change in how developers build software», можно так сказать, но даже сама статья не сказать, что этот тезис раскрывает).
Инженерная работа, которую ранее разработчик мог выполнить во время написания кода, – проработка структуры сущностей, описание модели, фиксация атрибутов качества, определение инвариантов, теперь, как и завещали нам все инженерные школы (начиная с XP) выносится вперед, как проработка конкретной задачи перед началом работы над ней, иначе нейронка просто не реализует то, что нужно.
Все дело в том, что разработчики (developers) к моменту начала разработки обладали большим количеством неявного знания отовсюду, - из доков, ранее написанного кода, жизненного опыта, кучи встреч и случайных обсуждений. Логично, что у нейронки этого нет и это надо:
a) вынести из головы в промт
б) структурировать должным образом
Такой Structured Promt обычно содержит не мало подробностей (REASONS), чуть приземленнее:
▪️в какой слой вносить изменения
▪️конкретные изменения в API и какие API трогать нельзя
▪️какие инваринаты домена нельзя нарушать
▪️какие тесты обязательны
▪️какие граничные кейсы обязательно обработать
▪️какие архитектурные соглашения соблюдать
▪️что считается успешным результатом
В целом, выгоды очевидны, их ощущаешь даже в одиночку:
▪️[Возможная] повторяемость, причем спустя долгое время (все же зависит и от модели и от температуры и от самого промта, тут не очевидно)
▪️Более точный результат, тут без комментариев – больше деталей – точнее результат
▪️Если есть ревью, людьми, то ревью проходит лучше – есть описание задачи и результат, своего рода сверка
▪️Быстрые драфты, особенно там где надо кучу кода изменить, – можно делать небольшие изменения в промте, которые распространяются сразу на много частей системы, объективно быстрее при накопленной строгой структуре
▪️Senior пишет правила, по которым составляется промт, всякие чеклисты, шаблоны и в целом ребята с меньшим опытом могут ими пользоваться
Однако, у всего есть побочка:
▪️Не просто так разработчики решали задачи в процессе разработки, – постепенное продвижение в решении с каждым шагом открывало новые вопросы, которые в момент обсуждения голосом могли даже не возникнуть в голове, пресловутое «о, а тут что должно быть?». Соответственно, глобально меняется модель мышления – сначала решение, затем модель пишет код. Это теперь _требует_ использования структурированных методов решения инженерных задач, коих много, но которые часто игнорировались. Похоже, этим практикам и методам теперь дается вторая жизнь.
▪️Чтобы грамотно поставить задачу нейронке, нужно с ней общаться на понятном ей языке, а она понимает любой язык (и сила и слабость). То есть если ей не сказать – здесь лучше использовать Chain of Responsibility и Builder, то она с высокой вероятностью не будет их использовать. А это методы локализации изменений, а локализация изменений – прямой метод оптимизации потребления токенов и повышения вероятности успеха при внесении изменений. То есть нужен точный доменный и инженерный язык.
▪️Все это нужно описать словами. А это бывает нудно. Если человек привык писать код по 10 часов в день в течение 10 лет, то перейти к написанию спецификаций может оказаться сложным (но придется)
В итоге SPDD снижает стоимость печатания кода 🙂 Но повышает важность постановки задачи, декомпозиции, верификации и архитектурной дисциплины. То есть это не про преимущество над классической разработкой в сложной инженерной работе, а скорее существенное преимущество в управляемом использовании LLM.
https://martinfowler.com/articles/structured-prompt-driven/
Пришла пора подвести итоги использования SPDD, как самостоятельного, так и в рамках консалтинга.
Я не увидел в SPDD чего-то, что бы фундаментально меняло подход к разработке, в сущности – это инструмент для того, чтобы обуздать и дисциплинировать работу ненадежным, стохастическим генератором кода (хотя Мартин Фаулер иного мнения - «material change in how developers build software», можно так сказать, но даже сама статья не сказать, что этот тезис раскрывает).
Инженерная работа, которую ранее разработчик мог выполнить во время написания кода, – проработка структуры сущностей, описание модели, фиксация атрибутов качества, определение инвариантов, теперь, как и завещали нам все инженерные школы (начиная с XP) выносится вперед, как проработка конкретной задачи перед началом работы над ней, иначе нейронка просто не реализует то, что нужно.
Все дело в том, что разработчики (developers) к моменту начала разработки обладали большим количеством неявного знания отовсюду, - из доков, ранее написанного кода, жизненного опыта, кучи встреч и случайных обсуждений. Логично, что у нейронки этого нет и это надо:
a) вынести из головы в промт
б) структурировать должным образом
Такой Structured Promt обычно содержит не мало подробностей (REASONS), чуть приземленнее:
▪️в какой слой вносить изменения
▪️конкретные изменения в API и какие API трогать нельзя
▪️какие инваринаты домена нельзя нарушать
▪️какие тесты обязательны
▪️какие граничные кейсы обязательно обработать
▪️какие архитектурные соглашения соблюдать
▪️что считается успешным результатом
В целом, выгоды очевидны, их ощущаешь даже в одиночку:
▪️[Возможная] повторяемость, причем спустя долгое время (все же зависит и от модели и от температуры и от самого промта, тут не очевидно)
▪️Более точный результат, тут без комментариев – больше деталей – точнее результат
▪️Если есть ревью, людьми, то ревью проходит лучше – есть описание задачи и результат, своего рода сверка
▪️Быстрые драфты, особенно там где надо кучу кода изменить, – можно делать небольшие изменения в промте, которые распространяются сразу на много частей системы, объективно быстрее при накопленной строгой структуре
▪️Senior пишет правила, по которым составляется промт, всякие чеклисты, шаблоны и в целом ребята с меньшим опытом могут ими пользоваться
Однако, у всего есть побочка:
▪️Не просто так разработчики решали задачи в процессе разработки, – постепенное продвижение в решении с каждым шагом открывало новые вопросы, которые в момент обсуждения голосом могли даже не возникнуть в голове, пресловутое «о, а тут что должно быть?». Соответственно, глобально меняется модель мышления – сначала решение, затем модель пишет код. Это теперь _требует_ использования структурированных методов решения инженерных задач, коих много, но которые часто игнорировались. Похоже, этим практикам и методам теперь дается вторая жизнь.
▪️Чтобы грамотно поставить задачу нейронке, нужно с ней общаться на понятном ей языке, а она понимает любой язык (и сила и слабость). То есть если ей не сказать – здесь лучше использовать Chain of Responsibility и Builder, то она с высокой вероятностью не будет их использовать. А это методы локализации изменений, а локализация изменений – прямой метод оптимизации потребления токенов и повышения вероятности успеха при внесении изменений. То есть нужен точный доменный и инженерный язык.
▪️Все это нужно описать словами. А это бывает нудно. Если человек привык писать код по 10 часов в день в течение 10 лет, то перейти к написанию спецификаций может оказаться сложным (но придется)
В итоге SPDD снижает стоимость печатания кода 🙂 Но повышает важность постановки задачи, декомпозиции, верификации и архитектурной дисциплины. То есть это не про преимущество над классической разработкой в сложной инженерной работе, а скорее существенное преимущество в управляемом использовании LLM.