Spec Driven Development в эпоху LLM — сомнительная фигня на грани карго-культа.
Фронтирные модели способны виртуозно выкручиваться, когда их заваливают километровыми спеками. Достаточно пары случайно оброненных слов в ТЗ — и сетка радостно нагородит оверинжиниринг на три слоя абстракций, о которых никто не просил. И виноват будет, конечно "этот ИИ, который никогда не заменит Настоящих Программистов".
Вместо написания простыней текста сделайте нормальный boilerplate и заложите нужные вам паттерны. Модель читает код, модель живёт кодом, модель продолжит реальные бест практис кодом гораздо точнее, чем попытается расшифровать литературные фантазии о ста листах.
Зачем писать эти километры спек? Чтобы оправдать занятость аналитиков и создать видимость "важного артефакта перед началом кодинга"? Чтобы "делать всё привычно, там же должна быть аналитика перед разработкой"?
Я ставлю ребром вопрос — должен ли AI SDLC быть "автоматизированным с помощью ИИ SDLC".
Есть ощущение — что не должен. Что AI SDLC должен строиться на других принципах.
Сделай веточку -> Запили инкрементальное изменение -> выкати на тестовый стенд -> РАЗБЕРИСЬ, ЧТО вышло. Подошло — забираем. Получилась дичь — отклонили и перегенерили с нуля.
Ключевой шаг — РАЗОБРАТЬСЯ. Сам принцип приёмки меняется фундаментально. Это выглядит не как "потыкать кнопочки в UI" и уж точно не "поверить агенту на слово, что он всё сделал". Нужен многосторонний инженерный аудит: архитектура, ключевые точки в коде типа миграций, безопасность, надежность, продуктовая наполненность, и много-много всего ещё.
И цель всех этих муторствований — не пройти по бизнес-процессу производства нейрослопного кода. Цель — находясь в постоянно меняющейся, непознанной среде (код меняется, процессы меняются, запросы клиентов меняются, бизнес адаптируется) проводить эксперименты, проверять гипотезы и накапливать экспертизу.
"Программирование на спеках" — это попытка в меняющейся среде с недетерменированными акторами построить конвеер по выпеканию одинаковых булочек.
Фронтирные модели способны виртуозно выкручиваться, когда их заваливают километровыми спеками. Достаточно пары случайно оброненных слов в ТЗ — и сетка радостно нагородит оверинжиниринг на три слоя абстракций, о которых никто не просил. И виноват будет, конечно "этот ИИ, который никогда не заменит Настоящих Программистов".
Вместо написания простыней текста сделайте нормальный boilerplate и заложите нужные вам паттерны. Модель читает код, модель живёт кодом, модель продолжит реальные бест практис кодом гораздо точнее, чем попытается расшифровать литературные фантазии о ста листах.
Зачем писать эти километры спек? Чтобы оправдать занятость аналитиков и создать видимость "важного артефакта перед началом кодинга"? Чтобы "делать всё привычно, там же должна быть аналитика перед разработкой"?
Я ставлю ребром вопрос — должен ли AI SDLC быть "автоматизированным с помощью ИИ SDLC".
Есть ощущение — что не должен. Что AI SDLC должен строиться на других принципах.
Сделай веточку -> Запили инкрементальное изменение -> выкати на тестовый стенд -> РАЗБЕРИСЬ, ЧТО вышло. Подошло — забираем. Получилась дичь — отклонили и перегенерили с нуля.
Ключевой шаг — РАЗОБРАТЬСЯ. Сам принцип приёмки меняется фундаментально. Это выглядит не как "потыкать кнопочки в UI" и уж точно не "поверить агенту на слово, что он всё сделал". Нужен многосторонний инженерный аудит: архитектура, ключевые точки в коде типа миграций, безопасность, надежность, продуктовая наполненность, и много-много всего ещё.
И цель всех этих муторствований — не пройти по бизнес-процессу производства нейрослопного кода. Цель — находясь в постоянно меняющейся, непознанной среде (код меняется, процессы меняются, запросы клиентов меняются, бизнес адаптируется) проводить эксперименты, проверять гипотезы и накапливать экспертизу.
"Программирование на спеках" — это попытка в меняющейся среде с недетерменированными акторами построить конвеер по выпеканию одинаковых булочек.