SUTRA: The Reference Framework That Changed How I Build With AI

Discipline at Scale

Image by Google Gemini

A Journey From Chaos to Discipline

A year ago, I was facing a problem that most development teams encounter when they start working with AI assistants like OutSystems Mentor. We were all over the place.

One prompt would generate entities. The next would try to create screens before the data model was locked. Another would duplicate validation logic across multiple places. We spent more time coordinating Mentor responses than we spent thinking about the actual architecture. The prompts were reactive, not strategic. The code reflected that chaos.

Then I started asking a different question: what if I applied the same discipline to prompting that I apply to system architecture?

That question became SUTRA. Not a tool, but a framework. A thread of guiding principles that ensures every interaction with an AI assistant like Mentor follows a structured, layered approach. Today I want to share what I learned, how it works, and why it matters beyond OutSystems.

What Is SUTRA?

SUTRA stands for Simple Unified Tiered Reference Architecture for Applications (or Saugat’s Unified Tiered Reference Architecture, when I am narcissist). The name matters less than what it does.

SUTRA is a reference framework for efficient development with AI tools like OutSystems Mentor. It codifies a specific build order, naming conventions, reusable patterns, and review standards that ensure consistent, maintainable, enterprise-grade applications regardless of whether you are building with low-code platforms or distributed microservices.

The core insight is simple. AI assistants are very good at executing instructions within a clearly defined scope. They fail when scope is ambiguous, when they are asked to make architectural decisions on your behalf, or when they are expected to infer patterns across dozens of separate requests.

SUTRA removes that ambiguity by defining the entire build path in advance, then prompting for each layer in sequence. No inference. No guessing. Just discipline.

At its core, artificial intelligence is a predictive engine, not a reasoning mind. When a development tool displays the word ‘thinking,’ it is describing a computational process, not a cognitive one. An AI assistant calculates the most statistically probable next output given its inputs. It does not deliberate, infer intent across sessions, or exercise judgement independently. Recognising this distinction is not a limitation; it is the foundation of effective AI-assisted development. When you supply structure, context, and explicit patterns, the AI executes them with precision. When you leave gaps, it fills them with probability, not wisdom. SUTRA is built on exactly this understanding.

The SUTRA Approach: A Build Order That Works

When I was building an estimation application in OutSystems using Mentor, I discovered that the sequence of requests matters enormously. Ask for screens before your data model is solid and Mentor will create something reasonable, but you will rework it. Ask for server actions before you have defined your structures and you will duplicate validation logic across the codebase.

So, I created a build order. Not because it is the only valid sequence, but because it is the sequence that eliminates rework.

Here is how SUTRA structures the work:

1. Static Reference Data First

2. Editable Configuration Entities

3. Core Business Entities

4. Data Initialization Strategy

5. Transport Structures and Contracts

6. Security Roles and Permissions

7. Server-Side Business Logic

8. Reusable UI Components

9. Screen Composition and Navigation

Each layer depends on the layers above it. Each layer is requested as a cohesive unit, not as scattered individual pieces. This creates a cascade where earlier decisions constrain later ones in a productive way.

For the OutSystems build, I requested all static reference entities in one prompt. Then all editable reference entities in the next. Then all transport structures together. Mentor understood the full scope at each step, applied consistent patterns, and caught relationships I might have missed if I had been working piecemeal.

Instead of 50 back-and-forth prompts, I used 9 focused ones. Instead of three rounds of refactoring because screens needed data adjustments, I got it right the first time because the data layer was locked before UI work began.

Three Principles That Make SUTRA Work

Always Be Explicit About Scope

Tell Mentor not just what to build, but what already exists and why. Describe the application purpose, the layer you are currently building, and which elements are already in place. This context shapes every decision the AI makes.

When I said ‘Create the data model for our estimation application. Include static entities for classification, editable reference entities for configuration, and core business entities for the primary workflows,’ Mentor understood the full picture and applied consistent patterns across every entity.

If I had simply said ‘Create database entities,’ I would have gotten something that needed fixing.

Request Patterns, Not Instances

Do not ask for one save action and hope Mentor applies the same pattern to the next entity. Ask for the pattern itself.

My request specified: ‘For each entity, create a save action that follows this pattern: validate required fields, check length constraints, verify business rules, check for duplicates, then create or update. Return the saved identifier and a standard result structure.’

From that point, Mentor applied that exact validation sequence uniformly. No drift. No inconsistency between entities.

Always Require Descriptions

Every entity, attribute, action, structure, block, screen, and variable needs a meaningful description. This is non-negotiable.

The framework is designed to be handed off, understood by others and later instances of AI assistants, maintained, and extended. A description is a commitment to clarity. It is the single most important thing that prevents future maintainers from having to guess at intent.

How SUTRA Generalizes Beyond OutSystems

This is the part that made me realise SUTRA is not an OutSystems framework. It is an architecture reference framework that happens to be currently implemented with OutSystems Mentor.

In Microservices Architectures

The same build order applies. When designing a set of microservices, you follow an identical sequence:

1. Shared domain models and enumerations (equivalent to static reference data)

2. Service-specific configuration and reference data (editable reference entities)

3. Core business entities for each service boundary

4. Message contracts and API request and response structures

5. Inter-service authorization and role definitions

6. Service business logic and orchestration

7. API contracts and SDK patterns

8. Client SDK and developer experience layer

The discipline is identical. The prompt changes from ‘Create these OutSystems entities’ to ‘Create these service models and API request structures,’ but the framework remains the same.

Start with data contracts. Then configuration. Then core logic. Then APIs. Then clients. Not the other way around.

I have validated this with few of my friends building Node and .NET. The teams who followed a SUTRA-like order delivered faster and with significantly fewer breaking changes.

In Microfrontend Architectures

The same principle extends naturally to frontend architecture. In microfrontend development, the SUTRA sequence maps to:

1. Shared design tokens and type definitions (static reference data)

2. Configuration and feature flag schemas (editable reference entities)

3. Core component structures and composition rules (core business entities)

4. Context, state, and prop interfaces (transport structures)

5. Access control and permission boundaries (roles)

6. State management and business logic hooks (server actions)

7. Atomic and compound components (reusable blocks)

8. Feature modules and shell composition (screens)

We haven’t tested or enforced this on micro front end apps yet, but I believe this shall yeild consistent designs, fewer prop-drilling issues, and could onboard new contributors much faster. The build order changed the language but the discipline stayed the same.

The Practice: Four Focused Prompts and One Polish Pass

In a real engagement, SUTRA reduces to a straightforward workflow.

Prompt 1: Data Model, Structures, and Roles

Define entities, reference data, transport structures, pagination standards, and security roles. Lock the contracts.

Prompt 2: Business Logic

Request all server actions, validation rules, seed data strategies, and automation patterns. Lock the behaviour.

Prompt 3: UI Components

Request all reusable blocks, list patterns, edit patterns, and navigation logic. Lock the presentation patterns.

Prompt 4: Screens and Composition

Request screens that orchestrate the blocks and compose the user experience. Lock the navigation.

Plus One: Polish Pass

Review naming consistency, ensure descriptions are complete, validate SQL formatting, spot any duplicated logic, and confirm all patterns were applied uniformly.

This is dramatically different from the chaotic prompting that led me to SUTRA in the first place. Instead of 50 small requests, it is 4 focused ones that build on each other. The AI assistant understands the full scope at each layer, applies consistent patterns, and creates production-ready output that does not need rework.

Why This Matters for AI-Assisted Development

As development teams rely increasingly on AI assistants, the difference between prompting discipline and prompting chaos is becoming the difference between shipping on time and shipping late.

AI assistants are excellent at execution. They are not good at inference. They do not learn your patterns across 50 separate conversations. They do not remember why you made a choice in prompt 1 when you are asking for something in prompt 25.

SUTRA solves this by treating the AI assistant as a construction tool, not a design tool. You do the design. You define the build order. You specify the patterns. Then you hand off execution to the AI, confident it will follow the order precisely and apply the patterns consistently.

Few friends who have adopted SUTRA report:

• 40 to 60 percent fewer back-and-forth prompts

• First-pass code quality that is immediately deployable

• Dramatically easier handoffs to team members

• Faster time to production

• Significantly lower refactoring overhead

Getting Started With SUTRA

You do not need OutSystems Mentor to benefit from SUTRA. You do not even need AI.

SUTRA is a discipline. It is a way of thinking about how to organise architectural work so that later decisions do not invalidate earlier ones, patterns stay consistent, and handoffs are smooth.

If you are currently working with AI assistants, here is how to start:

1. Define the build order for your architecture (data, config, core logic, contracts, patterns)

2. Write down the patterns you want applied consistently (naming, validation, error handling)

3. Bundle your work into 4 to 5 focused prompts instead of dozens of small ones

4. Request descriptions and documentation as part of every specification

5. Run a polish pass to catch anything that drifted from the intended pattern

If you are on a team, create a simple playbook that documents your specific build order, naming standards, and architectural patterns. Then teach everyone to work in that order. The discipline pays for itself in the first week.

The Bigger Picture

SUTRA started as a way to work better with OutSystems Mentor. What I discovered is that it is a way of thinking about architecture that scales across platforms, languages, and paradigms.

It is a thread of guiding principles. A sutra, in the original sense.

As AI-assisted development becomes standard practice, this kind of discipline will separate the teams that ship quality on time from the teams that ship quality late.

The framework is not the tool. The framework is the discipline.

Next Steps

I am in process of publishing the full SUTRA framework documentation, playbook templates, and review checklists as reference material, and working with teams across different technology stacks to validate that these principles hold beyond my specific use case.

The goal is to demonstrate that architectural discipline with AI assistants is not an OutSystems thing. It is an industry-wide imperative.

If your team is struggling with AI-assisted development, or if you are building microservices or microfrontends and want to try a build order and reference architecture that actually works, I would love to help you adapt SUTRA for your context.

The future of development is AI-assisted. The question is whether we bring discipline to that assistance or let it spiral into chaos. I know which one I would choose.