Анализ, коты, цветы и Катя

Где должен заканчиваться аналитик в AI-SDD?

У меня одна из проблем внедрения SDD выстраивание процессов и разделение ролей. Пока это видится примерно так:
Spec → Plan делает аналитик.
Code делает разработчик.
То есть роли и процесс, по сути, остаются теми же.
Но когда в спецификациях неизбежно находят замечания и правки, на их внесение начинает тратиться больше времени, чем в классическом подходе. Тк спеку продолжает править аналитик.
Раньше было проще:
Разработчик пинает аналитика.
Аналитик спорит.
Аналитик всё равно правит 🤣
Пока же теряется та самая гибкость, которую AI-SDD вроде как должен был дать. 😃

Возникает вопрос: насколько вообще целесообразно сохранять прежнюю схему ролей, если разработка уже строится вокруг AI-SDD?
Если всю цепочку будет делать 1 человек, то кто?

Кто уже внедряет или внедрил AI-SDD как вы решаете этот вопрос?

В чём, собственно, были не правы секретарши, которые писали пароль на стикер и клеили его к монитору?
Я вот так хорошо пожила в Сочи, что забыла пароль от своего компьютера 😒

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

P.S. Пароль я так и не вспомнила. Стандартные средства восстановления через флешку не помогли. Старая добрая переустановка ОС, добро пожаловать.🌸

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чем я хуже? Подумала и затестила Fable 5.

Качество результата одобряю🙃. Жор токенов - не одобряю 🙃

Задачки были несложные. Где-то на 2 из 10 по моей внутренней шкале сложности. До этого те же самые задачи пробовала на GPT 5.5 и Sonnet 4.6. И вот с Fable 5 я удивилась тому, как из того минимума информации, который я дала, модель смогла вытащить нужные нюансы и раскрутить мысль практически без лишних домыслов.

То есть мне почти ничего не пришлось править.

Жаль только, что нулевой баланс довольно быстро поставил эксперименты на паузу 🌟

А как ваши впечатления и опыт работы с Fable 5?

А вообще я всё ещё дико ору с этой приколюхи 🕺

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

Пока получается не очень 😏

Готовые rules и skills

Лично мой опыт пока такой: быстрее написать свои промпты, правила и скиллы с помощью Prompt Professor для GPT, чем искать готовые.
Но вдруг кому-то пригодится 😏

Маркет MCP

Готовые правила (rules) для разных языков программирования
Скиллы:
https://cursor.directory/plugins/agent-skills
https://agent-skills.techleads.club/skills/
https://mcpmarket.com/tools/skills

Но если у вас есть хорошие скиллы и правила для системного аналитика и менеджера с уклоном в планирование буду рада, если поделитесь)

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

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

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

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

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

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

AI-SDD и проблема стартового контекста

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

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

Но когда я прошу OpenCode или Cursor сделать эту работу, начинается совсем другое веселье. 😕 Приходится всё вычитывать, удерживать в голове тот контекст, который раньше формировался постепенно, и при этом стараться не повестись на сгенерированные ИИ мысли.

Объём информации временами заставляет скулить от беспомощности 😧 А затем больше половины того, что нагенерировано на старте, в итоге оказывается ерундой.

То есть стартовые шаги анализа в формате «Сделай мне» пока подружить с собой-человеком у меня не получается.

Acceptance criteria как стабилизатор AI-разработки

Мыслительная гимнастика на тему: почему именно критерии приемки так важны в ИИ-разработке? привела меня к следующим заключениям.

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

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

И вот в этом месте критерии приёмки в AI-SDD становятся основой:
😊 конкретики
😊 проверяемости
😊 и, что особенно важно, возможности для ИИ проверять результат собственной работы.

Теперь осталось убедится в этом на практике.

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

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

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

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

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

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

😑
Подбираемся к горяченькому..

Как думаете, какой артефакт в AI-SDD внезапно стал одним из основных среди спек?

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

Путь в SDD для тех, кто пока не очень знаком с подходом, наверное, хорошо начинать с этих двух материалов:
What Is Spec-Driven Development?
GitHub Spec Kit

И если судить по ним, то я, пытаясь примериться к SDD, пока всё делаю неправильно 😏

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

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

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

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

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

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

Продолжая тему шаблонов 2

Больше всего мне сейчас помогают следующие артефакты:

💌 внутренние правила версионирования API и правила проектирования API на уровне синтаксиса
💌 гигантский монструозный документ с правилами валидации системы
💌 шаблоны описания типовых задач для фронта и бэка
💌 шаблоны расширения БД
💌 шаблон описания ролевой модели
💌 шаблон ADR

По сути, всё то, что больше всего помогало мне и в обычной рутине раньше.

То есть снова получается: всё, что упрощало ручной инженерный труд, продолжает отлично работать и в эпоху ИИ
Следующий этап - оптимизировать это под AI-SDD

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

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

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

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

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

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

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

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

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

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

В школе одноклассники-гуманитарии часто говорили: «Зачем мне физика, химия? Я же не про это».

Школа осталась далеко. Выбираем свисток от медведей. Разница в 100 дБ и 120 дБ кажется не такой уж большой. Зачем переплачивать за 20 дБ? Но что-то ещё со школьных времён не даёт покоя про эти дБ. Начинаю проверять. А разница огромная!

Теперь осталось, чтобы медведь тоже оценил, что я физику не пропускала мимо ушей 🕺

#выходнойконтент