це не зараз. це так завжди і було.

— ми ж тут говоримо в контексті AI coding agents, не про базові SDLC практики, вірно? — тому раніше такого не було — був prompt engineering, який переріс в context engineering, який переріс/переростає в SDD

Я от писав, вмію, тому й знаю, що цей спосіб може, навіщо потрібний.

а для кого це — робиться?

ось тут головна зміна — раніше ви писали специфікації орієнтовані на людей — для інженерів які будуть все це імплементовувати, специфікації жили в умовній confluence wiki, з діаграмами в вигляді images, etc. А зараз специфікації скажімо так подвійного призначення — хоча все більше і більше орієнтовані на AI агентів, в markdown файлах, без діаграм в вигляді images, а текстові, чи mermaid, і живуть вони ближче до коду.

А навіть коли ШІ те все робить, все одно виникає specification gap, і все одно — код стає джерелом істини.

— знову таки ні, код відображає поточну реалізацію, і лише специфікація джерело істини, так було завжди, і так і залишиться. Для ілюстрації уявімо в нас є сервіс який генерує рахунки за спожиту електроенергію і підтримує багатозонні лічильники (день-ніч, etc.), але поточна реалізація не враховує різні типи лічильників і всі опрацьовує як однозонні. З вашого твердження, що код джерело істини, ніякої помилки в цьому немає, хоча по факту це критична помилка, яку потрібно негайно виправляти.

то якісь бовдури казали що описати треба — весь проект.

— ні — в цьому і відмінність Waterfall, вся специфікація проекту повинна бути описана від початку і до кінця, можливість вносити правки по ходу хоч і допускається, але дуже не бажана. І так Waterfall все ще актуальний, особливо поза межами IT, для фінального budget approval, sign-off, наприклад. Прикладом може бути будівництво будинку/офісного приміщення/заводу. Інакше то вже не Waterfall — а Agile чи інші SDLC моделі.

згоден — зараз більш актуальні product-minded software engineers — недавно на ДОУ це обговорювалось тут

а SDD це він і є. Оновлений Waterfall.

— ні — ви можете написати SDD під новий конкретний функціонал — тобто під якусь частину проекту

Взагалі то промптами код не пишуть вже.

— вірно — зараз через /plan: Analyze → Plan → Create → Scale & Repeat, або знову таки через /plan, але з ще більшою деталізацією, тобто через SDD: Specify → Plan → Tasks → Code
Одним словом як не крути — через специфікацію)
І плюс через синхронізацію документації/специфікацій після мержу.

Наприклад булет ліст фактів (або характеристик) немає сенсу представляти діаграмою.

а — ви мабуть мене не так зрозуміли (чи я вас) — я мав на увазі опис сценаріїв, залежностей, etc.

Якщо ви хочете щоб люди також активно користувались бібліотекою напряму

Все це вирішується, Github, наприклад, підтримує відображення Mermaid diagrams.

Якщо це AI агенти то їм важливіше мати текстовий опис елементів та їх взаємодіі, і діаграми наврядчи дадуть якийсь додатковий профіт тут.

Навпаки, LLM моделі дуже добре знають Mermaid синтакс. Щоб точно впевнитися, що і для ваших проектів працює, можете попросити LLM згенерувати Mermaid diagram-у для одного з ваших флоу, а потім в новій сесії попросити розшифрувати Mermaid синтакс назад в текстовий опис.

+ github.com/getzep/graphiti — Build Real-Time Knowledge Graphs for AI Agents

+ Недавно Andrej Karpathy опублікував LLM Wiki (A pattern for building personal knowledge bases using LLMs) — може бути корисно почитати його думки на рахунок генерування і підтримання документації використовуючи LLMs

Стандартний підхід в IT — діаграми. BPMN, UML activity, swim-lane.

Плюс діаграми для AI-агента — не дуже зручний формат. Йому потрібен текст, модульний, з чіткими лінками.

Не дивилися в сторону Mermaid?

Дякую за статтю.

Ми тестували reranking від LLM, але Cohere видає найкращу якість та швидкість.

— це ви маєте на увазі Cohere Rerank API?
Також згадав ось цю статтю на ДОУ, Як працюють сучасні AI-боти: розбір продакшн RAG-пайплайну, може бути корисною.
І ось ця: Як ми побудували власну RAG-систему: від проблеми до оптимального рішення

cybernews.com/...​n-ai-sora-crash-and-burn кажуть що

OpenAI was estimated to be spending $15 million a day on inference to enable users to produce videos

— тому так — тут лише гроші — хтось очікував іншого від Альтмана? :)

Перша навичка новачка — це не «як написати код», а «як збудувати архітектуру, якою керуватимуть агенти».

100% — але є нюанс, що навіть тут ви використовуєте AI — спеціалізований агент(и)/Claude Code skill(s), etc. :) - і якщо не прямо зараз, то в найближчому майбутньому для невеликих і навіть середнього плану сервісів, AI зможе з нуля будувати якісну архітектуру з усіма об"язками (CI/CD, Infrastructure as Code, observability, scaling, etc.), яка буде адаптована під AI агенти. Тому навіть не знаю — теж поки-що не маю відповіді, на що саме робити акцент, щоб залишатися конкурентноспроможним на ринку через 3-5 років)

Дякую за статтю! В цілому посил статті вірний, хоча як зазначили в коментарях, product-minded software engineers, blog.pragmaticengineer.com/...​-product-minded-engineer були в ціні завжди, — і згоден, що всім, хто до цього просто виконував поставлені задачі, потрібно переосмислити підхід, щоб залишатися конкурентним на ринку праці.

Яка ціна питання?

це тема іншої статті (DORA метрики)

так DORA метрики ж не про кошти — так як тут мова йде про AI, то DORA це про адаптацію/інтеграцію AI на рівні організації чи окремої команди, скажімо так, організаційні практики, які потрібно впроваджувати, щоб інтеграція AI дійсно почала приносити результат і покращила класичні DORA метрики. Див. cloud.google.com/...​ral-ai-capabilities-model

How do we move from just using AI to truly succeeding with it? How do we ensure our investment in AI delivers better, faster, and more reliable software?

думаю ні — доу схоже конвертує короткий дефіс в довгий

ви описали Waterfall

— тут не погоджуся — ці фази актуальні для всіх SDLC моделей, Agile спрінти ви ж так само плануєте — який функціонал ви хочете імплементувати — а цьому передує збір вимог — потім розробка, тестування, деплой — просто в Agile цей цикл коротший, зазвичай один спрінт — це 2 неділі
оця стаття, як на мене, доволі добре описує ці моменти www.ibm.com/think/topics/sdlc

ваш «фреймворк» є монстром де перемішані усі етапи, немає контролю, передбачуваності

— тут згоден — все перемішано — і, на мою думку, викладені підходи в статті можуть спрацювати для побудови прототипу, а не production ready рішення, яке можна підтримувати і приймати контріб"юшени від різних команд

я би автору порекомендував забути про Microsoft Copilot, перечитати останні best practices для Spec-Driven Development — і дивитися в сторону Claude Code (CLAUDE.md, skills)

фантастичні фільми мого дитинства потроху стають реальністю)

speech-to-speech prompt injections))

дякую за статтю — справді є над чим замислитися — прогрес дуже серйозний