ИИ разработке нужны не спецификации, а полноценная трассировка требований

Начнем с вывода

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

ИИ радикально ускоряет написание кода, но узкое место разработки — инженерный процесс и коммуникация. Чтобы пройти эти узкие места нужно:

• Делать ИИ частью процесса, а не «ускорителем печати».

• Фиксировать артефакты, правила трассировки и критерии приемки так, чтобы их можно было исследовать, проверять и связывать с кодом.

• Строить работу на малой связке ролей (владелец продукта, аналитик, инженер) с четкими точками соглашения: требования → архитектура → исполнение.

Ну и куда же без своих поделок — мои 5 копеек в фреймворки для Human-AI Design & Development: SpecLoom (MIT, все дела). Это обвязка над LLM чтобы создавать требования, архитектуру и код, трассировать их друг с другом и валидировать на каждом этапе.

Проблема “кода”

Разработка — это инженерная задача

Где-то полгода назад я понял, что меня так смущает в инфополе касательно ИИ разработки. Все меряются количеством PR, написанных строк кода, ругают качество, безопасность и стандартные ошибки. Но когда на ретро мы обсуждаем почему спринт получился не таким как мы хотели, самая частая причина — не то, что что-то сложно технически. Жалобы в основном на то, что нам приходится оценивать задачу исходя из требований, которые не очень четкие, наши архитектурные решения, принятые до этого не учли чего-то, стейкхолдеры не отвечают так быстро как хотелось бы, технический долг накапливается — в общем все что мы с вами знаем. Но весь мир так увлекся что сложная когнитивная задача (написание кода) может быть решена машиной, что, как мне кажется, решает не ту проблему.

В моем представлении, разработка программного обеспечения или иных программных решений — это инженерная задача. Когда то давно, один их архитекторов сказал мне: чтобы “кодить” достаточно средне-специального образования. А вот чтобы разрабатывать ПО нужно много чего уметь и знать, где написание кода — это приятный бонус. Положив руку на сердце, я хочу сказать, что ИИ достаточно хорошо решает задачу написания кода. Только вот он решает не ту задачу.

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

Помните такую классную диаграмму — Stacey Complexity Matrix? Она вот об этом.

Задача в разработке может быть легкой, а может быть сложной — чем определенее задача описана и чем более четкие соглашения между участниками, что это за задача — тем прощее ее выпонить. А также, уже на мой взгляд, тем лучше эта задача решает проблему клиента/стейкхолдера.

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

Разработка — это процесс

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

Сегодня команды разработки это 5-10 человек, 2-3 недели на доставку значимой части продукта для сбора обратной связи (которая буквально заменила требования). Аналитики и системные архитекторы сосредоточены на спецификациях, а владельцы продукта взяли на себя высокоуровневый бизнес-анализ. Коммуникация все еще огромная проблема. 10-30% всего времени уходит на ритуалы.

Подумайте, где в такой конфигурации можно применить ИИ для улучшения? Я надеюсь ваш ответ не “нам нужно чтобы разработчик быстрее печатал”. Основные центры затрат в этом процессе это:

• Коммуникации (до 30% FTE команды!): 5-10 человек могут договориться, но им требуются ритуалы для синхронизации и эффективного обсуждения. Убрать коммуникационные барьеры аналогично по стоимости тому, как сократить 3 человека в комманде из 10.

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

• Полезность: Текущая итерация должна быть полезна иначе вы увеличиваете риск продуктовой ошибки. Пользователи должны голосовать использованием.

Все эти затраты остаются с ИИ или без ИИ. Когда OpenAI говорит: “100% кода пишет ИИ”, я им верю. Чего они как мне кажется недоговаривают, это то, что перед тем как ИИ что-то напишет, человеки решают такие интересные вопросы как: “А что писать?”, “Как убедиться, что это работает как мы хотели?”, “А как сделать так, чтобы это было поддерживаемо?”, “Кто принесет пиццу на наш ночной овертайм, потому что нам нужно отревьюить те 862 PR появившихся после обеда?”.

Разработка — та еще “работка”

В истории IT была “идеальная” система коммуникации в разработке ПО — Waterfall c требованиями, архитектурой, V-Model и полной трассировкой от потребности к коду. Основой таких моделей была системная инженерия. Однако платой за такую системность была низкая скорость и негибкость. Невозможно эффективно коммуницировать с потребителями итерациями в год, невозможно эффективно коммуницировать между 10 командами разработки обнаруживая критические баги на интеграционных тестах раз в полгода. Но если смотреть на матрицу Стейси — все задачи в такой системе должны быть легкими. Они просто запаздывали с пользой и проваливались в интеграции.

Но именно это нам обещает ИИ — ускорение итераций! Так давайте вернемся к классике и пересмотрим ее. Давайте откопаем Вигерса и вспомним, как это должно быть в мире, где есть четкие спецификации.

А самое главное с ИИ эти спецификации обозреваемые, как система знаний (я с содроганием вспоминаю тех. описание своей первой системы и ее требований, корторое занимало 4хх страниц). Скормим это ИИ, свяжем с кодом и наконец перестанем “вайбкодить”, но взглянем на ИИ разработку «по-взрослому», где разработчик “владеет” результатом, а ИИ “ответственный” за него (я имею ввиду accountable и responsible, не знаю как лучше сказать).

Вот с такими мыслями я решил сделать Specloom.

SpecLoom

В общем меня в один вечер пробесило как все происходит с разработкой в ИИ и я решил «хватит это терпеть» и решил пилить свой фреймворк как и все вокруг 🙂

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

Specloom состоит логически из трех частей:

1. Процесс разработки

2. Стандарт документации

3. Харнесс для работы ИИ со Specloom

Как и какая команда с этим должна работать? В моем идеальном представлении это связка из трех человек:

Собственно весь процесс это классическая разработка с четкими требованиями и прекрасной V-model, только на стероидах из-за ИИ (что аж умещается в спринт) и намного меньшим количеством людей. Такой команде не нужны дейли, не нужны многочасовые “alignments” — их мало, они эффективны в коммуникации. У владельца продукта может быть много команд.

С позиции Specloom и ИИ агента процесс это каскад связных артефактов, которые можно группировать при выполнении задачи:

Стандарт

В сердце спеклума лежит стандарт документации — JSON схемы, которые определяют как выглядят артефакты (требования, элементы архитектуры и т.п.).

Например:

{  "$schema": "http://json-schema.org/draft-07/schema#",  "title": "Functional Requirement",  "type": "object",  "properties": {    "id": {      "type": "string",      "description": "Unique identifier, e.g., FR-001"    },    "title": { "type": "string" },    "description": {      "type": "string",      "description": "The 'System shall...' statement."    },    "trace_to": {      "type": "object",      "properties": {        "user_requirements": {             "type": "array",             "items": { "type": "string" },            "description": "IDs of parent URs"         },        "stakeholders": { "type": "array", "items": { "type": "string" } },        "assumptions": { "type": "array", "items": { "type": "string" } },        "business_rules": { "type": "array", "items": { "type": "string" } },        "nfrs": { "type": "array", "items": { "type": "string" } },        "constraints": { "type": "array", "items": { "type": "string" } },        "design_nodes": {             "type": "array",             "items": { "type": "string" },            "description": "IDs of architectural components (LCOMP-*, PCOMP-*, API-*, DATA-*) that implement this FR. MANDATORY for Design phase."         },        "verification_plans": {             "type": "array",             "items": { "type": "string" },             "description": "IDs of Test Scenarios (SCN-*) or Verification Tasks (TASK-*). MANDATORY for Verification phase."        }      },      "minProperties": 1    },    "acceptance_criteria": {      "type": "array",      "items": { "type": "string" },      "minItems": 1,      "description": "Conditions that must be met for the requirement to be marked as complete."    },    "verification_method": {      "enum": ["Analysis", "Demonstration", "Inspection", "Test"],      "default": "Test"    },    "priority": { "enum": ["Must-have", "Should-have", "Could-have"] },    "stability": {       "enum": ["Stable", "Draft", "TBD"],      "description": "Used to signal to the agent if the requirement is ready for implementation."    },    "status": {      "enum": ["Proposed", "Active", "Deprecated"],      "default": "Proposed"    }  },  "required": ["id", "title", "description", "trace_to", "acceptance_criteria", "priority", "stability"]}

Создавая артефакт Specloom каждый раз валидирует созданные артефакты на этих схемах и зашитых правилах трассировки (например, Functional Chain всегда имеет ребро графа к Функциональному требованию и т.п.)

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

Но самое интересное, как эти артефакты связаны:

При написании кода ИИ использует артефакт задачи как точку сбора контекста по трассировке. Т.е. он не тянет все требования или всю архитектуру, а только те компаненты и артефакты, которые нужны для задачи.

Такой же принцип лежит в основе изменений — когда к вам прибегает владелец продукта и говорит, что теперь вместо локальной базы, вам нужен SSO — требование можно отследить и понять его импакт на всю систему.

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

Чтобы не быть голословным — вот пример небольшого веб приложения начатого со SpecLoom для иллюстрации его возможностей: Pathcamp. Я его не закончил, вы можете клонировать его и поиграться с кодом или добавлением новых требований и т.п., чтобы понять как это работает.

В общем, в чем преимущества такого подхода:

• Вы точно знаете что вы разрабатываете. Разработка идет не от количества строк или как быстро вы отправляете PR, она идет от потребности и договоренности.

• Работает в команде. Текущие инструменты направлены на индивидуальную разработку и эффективность. Но будем честны, наша экспертиза ограничена. Нам нужны другие профессионалы.

• Не уничтожает «экспертность». Черт побери, ну серьезно, если ты не знаешь что делаешь, процесс не контроллируем, не поддерсживаем, ты не можешь принимать взвещеные решения. Контроль это важно. SpecLoom должен работать вместе с тобой, а не за тебя.

• Сделано с расчетом на Change Management. Любое изменение это импакт. На больших проектах такой импакт нужно оценить. Без трассировки требований к коду это почти невозможно. Принять арзитектурное решение тоже очень сложно. В теории это должно существенно упрощать архитектуру (не нужно закладывать дополнительные требования «с запасом» на scalability. На практике конечно нужно 🙂 ).

Что-то тут не так

Естетственно есть ограничения и куда расти:

1. Specloom это дорого в токенах. Дороже чем вайбкодинг на одну итерацию. В долгосрочной перспективе скорее всего количество токенов падает поскольку переделывать нужно меньше, качество лучше, а поддержка продукта не требует переписывать его с нуля. Но от первого контекста к прототипу вайбкодер сожжет потенциально меньше токенов, хотя я не замерял.

2. Все еще нужны люди. Причем не один. Если выкинуть из Specloom человеческую экспертность — вы получите на выходе отвратительные продукты. Вспомните: книгопечатанье убрало писцов-переписчиков, но их экспертиза была нужна для штампов, грамотного текста, первых экземпляров и т.п. Тут так же — Specloom это не вайбкодинг. Мое мнение, без экспертизы разработка обречена на провал (пока)

3. Brownfield проекты сделаные не со SpecLoom не получится дорабатывать. Легаси не победить таким подходом. Я несколько раз пробовал подойти к этой задаче пытаясь вытащить архитектуру и требования из кода, но все было безуспешно. Я подумываю попробовать еще раз когда вместо комментариев сделаю трассировку кода по AST, но у меня небольшие надежды. Пока Specloom — это только новые проекты.

4. Процесс не очень гибкий, а протоколы и процедуры отнимают токены. Правила должны быть вшиты и контролироваться не сложными .md, а онтологией, а контекст не собираться из текстового файла, а напрямую помещаться в окно контекста и управляться. Я обдумываю что-то типа KG RAG.

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