Как делать продукт с ИИ, а не фабрику из случайного кода

СегодняСегодня

1 мин

Прочитал на Хабре заметку про spec-driven development и поймал себя на мысли: это не про «как лучше промптить». Это про управляемость. Когда ИИ пишет код быстро, размытые требования превращаются в огромные MR и бесконечные правки. Симптом знакомый: «написали много, а что именно хотели - так и не ясно». Мой рабочий рецепт на 7 шагов (и он одинаково годится и для Python-сервисов, и для агентных штук): 1. 🎯 Зафиксируйте контракт фичи Одна страница: проблема, границы, что НЕ делаем, критерии приемки (проверяемые), 2-3 примера вход-выход. 2. Делайте спеки маленькими S: до 10 минут, M: 10-20, L: 20+. Одна спека в работе (WIP limit). Так дешевле держать фокус и проще ревьюить. 3. 🧱 Архитектуру пишем текстом, а не «в голове» Для M/L добавляйте простые диаграммы: последовательность вызовов, модель данных, C4-уровни. Храните это рядом с кодом, как артефакт. 4. Разделите роли ИИ • Редактор спецификации: превращает голосовой/сырой поток мыслей в структуру и критерии. • Исполнитель: пишет к

Прочитал на Хабре заметку про spec-driven development и поймал себя на мысли: это не про «как лучше промптить». Это про управляемость.

Когда ИИ пишет код быстро, размытые требования превращаются в огромные MR и бесконечные правки. Симптом знакомый: «написали много, а что именно хотели - так и не ясно».

Мой рабочий рецепт на 7 шагов (и он одинаково годится и для Python-сервисов, и для агентных штук):

1. 🎯 Зафиксируйте контракт фичи

Одна страница: проблема, границы, что НЕ делаем, критерии приемки (проверяемые), 2-3 примера вход-выход.

2. Делайте спеки маленькими

S: до 10 минут, M: 10-20, L: 20+. Одна спека в работе (WIP limit). Так дешевле держать фокус и проще ревьюить.

3. 🧱 Архитектуру пишем текстом, а не «в голове»

Для M/L добавляйте простые диаграммы: последовательность вызовов, модель данных, C4-уровни. Храните это рядом с кодом, как артефакт.

4. Разделите роли ИИ

• Редактор спецификации: превращает голосовой/сырой поток мыслей в структуру и критерии.

• Исполнитель: пишет код строго по спеке.

Человеческое «да/нет» и ответственность остаются у владельца продукта.

5. ✅ Любая правка - через спецификацию

Не «поправь тут в чате», а обнови спеку и только потом меняй код. Иначе теряется воспроизводимость.

6. 🛡️ Для Python-интеграций думайте про надежность раньше красоты

Мои последние эксперименты упёрлись не в модель, а в обвязку: разрывы API, плохая связь, очереди, ретраи, локальный буфер, лимиты. Это, вобщем, и есть продукт. Добавьте метрики качества и журнал решений (что сделал агент и почему).

7. Экономика: считайте цену неопределенности

10-30 минут на спеку часто экономят часы ревью, багфикса и переговоров. Особенно когда продукт живёт долго и его будут «допиливать» разные люди и агенты.

Если хочется быстрый старт: возьмите одну фичу и сделайте S-спеку с 5 критериями приемки. Потом дайте её ИИ и сравните качество с «обычным» промптом. Почти всегда разница видна сразу.

Источники:

• Spec-Driven Development: контроль AI-кодогенерации (Хабр)

• Spec-driven development (Martin Fowler)

• PlantUML (диаграммы как код)

https://t.me/archfinance

#ии #продукт #архитектура #управление #python