Как делать продукт с ИИ, а не фабрику из случайного кода
Прочитал на Хабре заметку про 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
Прочитал на Хабре заметку про 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
❤2
Мониторинг конкурентов руками - это вкладка с 30 сайтами и привычка забивать.
Я собираю это иначе. Crawl4AI ходит по сайтам конкурентов, отдаёт чистый Markdown, а не HTML-помойку. Дальше upsert в векторку, сверху RAG. Спрашиваешь "что у них поменялось в ценах" - получаешь ответ, а не 30 вкладок.
Главное: self-hosted, без API за деньги. Краулер сам тут.
#crawl4ai #webscraping #python
📱 Макс · 📖 Дзен · ✈️ Telegram · 🌐 hr-s.ru
Я собираю это иначе. Crawl4AI ходит по сайтам конкурентов, отдаёт чистый Markdown, а не HTML-помойку. Дальше upsert в векторку, сверху RAG. Спрашиваешь "что у них поменялось в ценах" - получаешь ответ, а не 30 вкладок.
Главное: self-hosted, без API за деньги. Краулер сам тут.
#crawl4ai #webscraping #python
📱 Макс · 📖 Дзен · ✈️ Telegram · 🌐 hr-s.ru
👍1