Hi @Dorine Boudry ,

Thank you for this feedback! You’ve hit on exactly the core tension of modern software development: balancing the messy, iterative reality of discovery with the need for clean execution.

I completely agree with you that the 90s illusion of 'perfect upfront design' is dead and buried. If SUTRA were demanding a multi-month blueprint for an entire enterprise system before writing a single line of code, it would absolutely fail in today's environment.

That is actually a missing piece of context from my article that I need to clarify: SUTRA is designed to be executed per sprint, not per monolith. It is essentially Specification-Driven Development applied to short iterations. When we dive into a sprint, we do know what small slice of functionality we are trying to build over those two weeks. SUTRA simply argues that within that specific sprint slice, the order in which you prompt the AI assistant matters immensely.  

If you let the AI guess the data structures based on a UI mockup you want this week, it fills the gaps with statistical probability, leading to micro-rework even within a two-week cycle. The microservices and microfrontend references in the article weren't meant to imply a massive, rigid architecture, rather, they were examples to validate that whether your sprint delivery is a low-code module or a microservice, a disciplined build-order prevents immediate technical debt.  

I love your point about 'embracing and managing the chaos.' I think where we align is that AI accelerates development by 10x. However, my experience has been that 10x speed without an internal execution order just creates 10x the technical debt, faster. SUTRA isn't about stopping the iterative loop; it’s about making sure that when you do iterate, your AI assistant is treating your current sprint goals with architectural precision rather than guessing wildly.  

Really appreciate you pushing back on this: it helps me refine how I explain the framework!

Best

Saugat

Ok, 

that makes a lot more sense.  

When requirements are pretty clear, that's roughly how you (at least I) as a developer would already approach development anyway, so it is natural to also do that sequence in promting.

Are you saying that this works better than just having all your requirements in a single prompt or document.  Why break it up in steps exactly ? Do you have human validation steps between those prompts (like checking the result/quality of the generated datamodel + wrappers before going to the business logic ?)  Is that what you mean with 'locking' ?

I myself am a data first thinker, meaning that how my brain works, I look at a system as being data at it's core, and proces is there to bring that data into existence and transition it.  There are also proces first thinkers, that see a system as being proces at it's core, and data is there to support the proces.  Of course, the truth is in the middle.

So the approach you advocate feels natural to me, but I have learned that sometimes, and especially when the business / product owner are more proces thinkers, it is actually needed to start from the other side, develop a thin layer of screens and processes, and then thicken it with logic and data as you go.

Good luck with the launch of your playbook,

Dorine

Hi @Daniël Kuhlmann,

Great catch, and I appreciate you looking into it!

To clarify, SUTRA is an architectural reference framework/playbook that I am currently finalising and documenting, not a commercial SaaS tool or software product. The websites you found (sutra.ai and sutra.team) are completely unrelated commercial entities.  

Regarding its relationship to OutSystems: The framework was actually born directly out of a specific low-code challenge. When my team began building applications using OutSystems Mentor, we noticed that the AI assistant was incredibly fast, but it often generated a lot of architectural 'noise code' if prompted reactively. For instance, it would duplicate validation logic across multiple server actions or misalign entities if we asked for screens too early.  

SUTRA was created as a specific build-order playbook to mitigate that noise. By enforcing a disciplined sequence within OutSystems Mentor (locking static data, then core entities, then business logic), we forced the AI to generate clean, enterprise-grade architecture right on the first pass.  

The references to microservices or microfrontends later in the post were simply to illustrate how these same prompting constraints can generalize to other development stacks. I am looking forward to sharing the finalized, open playbook templates soon to clear up any naming confusion!

Best,

Saugat