AI-SDD — или как индустрия переоткрыла требования
Благодаря Cursor, Kilo вокруг снова начали говорить про подход SDD (Specification-Driven Development кратко сначала требования → потом разработка).

Причём до сих пор вижу, как это презентуют в духе: «Это вам не позорный вайбкодинг, а настоящий прорыв».
Мне как аналитику такое, конечно, забавно слышать. Никаких великих открытий в самой концепции подхода тут нет. И именно этим поначалу сбивает с толку этот ваш AI-SDD.

Сейчас, копая тему глубже, всё интереснее наблюдать разницу между требованиями, которые пишу для людей, и теми, которые генерирую в первую очередь для ИИ и меньше для людей.
Разница есть. Но там где процессы и анализ уже были поставлены, не такая коласальная в артефактах, как могла бы быть.

Думала шаблоны никому не нужны, но оказалось что в эпоху ИИ шаблоны все же конкурентное преимущество

При работе с Cursor и подобными инструментами на этапе создания структуры проекта, включая документацию, для меня самым удобным оказалось просить использовать мои шаблоны, которые лежат где то там же в проекте.

Иначе каждый раз получаются разные ADR, ER-диаграммы и даже разный OpenAPI.

В целом все правила-шаблоны, которыми я не ленилась обкладывать свой ручной процесс проектирования, сейчас начинают играть мне в плюс при эпоху ИИ.

Вот только пока не поняла, эффективнее шаблон использовать как заготовленный промт, или все же отдельный файл. Кажется отдельный файл, но данных мало

#Мысли_об_ИИ #AI_SDD

Продолжая тему шаблонов 3. Другая сторона медали в том, что сегодня практически любой шаблон можно достаточно быстро подготовить с помощью ИИ.

Да, это дополнительное время. Но если шаблонов у вас пока нет - ещё не всё потеряно. Просто появляется ещё один обязательный шаг прежде чем бросаться в разработку.

Преимущество отсуствия шаблонов - их можно сразу адапитировать под понимание машиной и конкретной LLM.

#Мысли_об_ИИ #AI_SDD

Суровая правда: Если у вас слишком много рабочих задач, то, возможно, стоит думать не о том, как потратить время на изучение очередного ИИ-инструмента, а уже наконец-то поменять работу.

Барабанная дробь и ответ!

Артефакт звездным часом которого стал рассвет AI-SDD методологии: Критерии приёмки (acceptance criteria)!

Да, для аналитиков это не новый артефакт, но лично в моей практике я использовала их редко. Обычно для сложных случаев, где важно не упустить неочевидные нюансы.

Если честно, писать нормальные критерии приёмки получается не так-то просто. То, что сам ИИ генерирует, выглядит… мягко говоря, странно.

Господа аналитики и другие специалисты, а каков ваш опыт применения Критериев приемки? В разработке без ИИ как часто вы вообще сталкивались с эти артефактом? И есть ли у вас какие-то свои правила или приёмы для их написания?

Как же справится с нагрузкой из последнего поста?

Пока я всё же не сразу хватаюсь за генерацию документации для проекта.

Сначала по старинке пытаюсь выявить всё, что можно выявить: понять контекст, ограничения, связи, реальные потребности. На этом этапе ИИ использую скорее как собеседника: для обсуждения вопросов и поиска информации через GPT или Perplexity.

И только когда становится более-менее понятно, что именно мы вообще делаем, начинается та часть работы, которая уже похожа на то, что обычно имеют в виду под AI-SDD.

Есть ли во всём этом выигрыш по времени и качеству по сравнению с эпохой без ИИ? Да. Как раз сейчас пытаюсь собрать нормальную статистику.

В этом снова помогают таймшиты в процессах 🙂

Сколько контекста нужно AI на самом деле?

Продолжаю эксперименты. Решила пойти самым простым путём.

Взяла проект, который легко отчуждается от большой системы: и со стороны кода (его автоматизация сводится буквально к небольшому bash-скрипту), и со стороны требований.

Сам проект уже был реализован. То есть на него существовали и требования, и готовый код.

Требования и все вспомогательные материалы перевела в формат MD. Причём взяла именно те версии, которые уже были отсмотрены разработчиками и тестировщиками.

Даже немного заморочилась: подложила стайлгайды, архитектурные договорённости и прочие артефакты, которые обычно существуют где-то между строк.

Агента просила задавать вопросы, если что то не понятно. Отвечала только на них. Задавал кстати мало. Что уже сразу не одобряем. Каких-то особых скиллов не было.

Как думаете, хватило агенту контекста? Удалось ли получить работающую автоматизацию после нескольких часов доработок кода с моей стороны, но без добавления новых спецификаций?

Спойлер на эксперемнт: 10 раз Ха-ха. Буквально на старте встряли. Как думаете на чем?

Документации для ИИ всегда мало

Результаты эксперемента. Итак, проблемы начались уже на старте. В требованиях было указано использовать Kerberos-аутентификацию. Для разработчика системы тут всё более чем понятно. А вот агенту — нет.

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

Дальше выяснилось, что описания данных и ER-диаграммы (ну или их вариации) агенту тоже недостаточно. Он вообще невдуплил откуда взять данные и куда их положить.

А дальше уже сдалась я. Поскольку программист из меня всё-таки так себе, решила больше не вайбкодить. Стало очевидно, что мы уверенно движемся куда-то не туда.

Зачем я вообще это делала?

Всё ещё пытаюсь понять, какой объём артефактов для ИИ можно считать достаточным. Изначально мне казалось, что тот набор артефактов, который я обычно передаю дальше по цепочке разработки, для ИИ будет даже избыточным.

Сейчас же у меня ровно противоположное ощущение.

Кажется, что этого критически не хватает. И приходится дополнительно обкладываться стайлгайдами, правилами и прочими документами, которые объясняют вещи, считающиеся само собой разумеющимися внутри команды разработки. И это действительно маленький проект, который некоторое время назад с моей помощью реализовал специалист технической поддержки.