Claudio Lassala's Blog

1. Introduction: The “AI in the Loop” Paradigm

In the traditional “Human in the Loop” model, AI takes the lead while the human serves as a mere speed bump—a manual validator in an automated race. As a Strategic Architect, I advocate for a reversal: AI in the Loop. In this paradigm, the human owns the intent, the goals, and the outcomes. AI is the strategic tool used to handle the “plumbing”—the CSS, the boilerplate, the routine migrations—leaving the consultant free to focus on empathy and human intent.

The shift requires moving from a “Software Developer” mindset to a “Solution Developer” mindset. As one team lead once bluntly told a developer focused on over-engineering abstractions: “We are here to sell shit. We are not here to write code.” Software is rarely the point; the solution is.

Mindset Shift: Software vs. Solution

Dimension	Software Developer Mindset	Solution Developer Mindset
Primary Focus	Building software and crafting code.	Developing solutions to fulfill needs.
Core Question	“What code should I write?”	“What is the underlying need?”
Success Metric	Velocity and story points.	Outcomes and value resolution.

To deliver true value, we must look beneath the surface of a request to find the foundational values driving it.

---

2. The Intent Hierarchy: Values, Aspirations, and Needs

Jumping straight to solutions is the fastest way to “build the wrong thing faster.” High-velocity AI assistance only gets you lost at a greater speed if the trajectory is wrong. We must follow a rigorous progression: Values → Aspirations → Needs → Problems → Solutions.

The Analytical Breakdown

• Values: Fundamental beliefs that guide decisions (e.g., “I believe our customers deserve transparency when things go wrong” or “I believe my employees should have the tools to do their best work”).

• Aspirations: What the person wants to become or experience (e.g., “I want our customers to feel confident recommending us to others” or “I want my sales team to spend time building relationships, not fighting with tools”).

• Needs: What must be true for aspirations to be realized (e.g., “I need my support team to resolve issues before customers escalate” or “I need visibility into which products are actually driving revenue”).

Technique Spotlight: Asking Why in Layers

Use these active commands during discovery to strip away the “Implementation Language”:

1. Identify the Problem: “What specifically is obstructing your progress?”

2. Define the Need: “What must be true for you to move forward?”

3. Uncover the Value: “What fundamental belief makes this matter to you?”

By digging to the values layer, you find where clarity lives. This hierarchy serves as the foundation for the narrative shift from “User” to “Human.”

---

3. Narrative Transformation: Engineering the “Human Story”

Traditional user stories (“As a [role], I want…”) often bury the “why” at the end, encouraging teams to focus on buttons rather than lives. We flip this: In order to [Benefit], As a [Human], I need [Feature].

I am demanding on this point: If you cannot finish the “In order to” sentence in plain English, you have no business writing code. This is the “So What?” layer. If the benefit isn’t clear to a non-technical person, the feature is likely gold-plating.

User Story: A technical interaction description. (e.g., “As a user, I want a date-picker.”)

Human Story: The narrative a person tells a friend about how their life improved. (e.g., “I was struggling to track my growth, but this showed me my progress, which kept me motivated.”)

---

4. Designing for Intent: Behavioral Separation and CQRS

Command Query Responsibility Segregation (CQRS) is not about database tooling; it is about human intent. By separating “intent to change” (Commands) from “requests for information” (Queries), we align the system with the human mental model.

Capturing Intent over Updating Fields

When a customer interacts with an e-commerce system, they aren’t “Creating a Sales Order Record.” They are expressing an intention to buy.

• The Interpretive Layer: From the customer’s view, it is a Purchase Order. From the business’s view, it is a Sales Order. The system must receive the intention to be interpreted by the business (e.g., checking inventory, processing payments) rather than just filling database rows.

Clarity in Chaos: The Hyperinflation Context

My perspective on intent was forged at age 15 while managing cash flow during Brazil’s hyperinflation. Timing and intent were everything—waiting an hour to move money could lose the business its profit. In high-stakes environments, decisions are made with incomplete information. Your system must capture the intent of the decision-maker at that specific moment to maintain clarity amid chaos.

Intent-Revealing Patterns

• Event Sourcing (Recording the Game): Don’t just store the “final score” (current state). Record the “Game Film” (events).

• The Invisible Gorilla: Traditional CRUD systems “count the passes” (state changes) but miss the “Gorilla” (the narrative). Storing events provides an Audit of Intent. If a price changes, we need to know: Was it an AI optimizing for cost, or a human responding to a crisis? You cannot coach a team from a final score; you need the film.

---

5. Story-Showing: Visual Alignment and the “30-Second Wow”

Storytelling hands images to the listener’s imagination, leading to divergent visions. Story-Showing provides a shared vision, the ultimate defense against “Training Debt”—the cost of teaching people to work around software that doesn’t fit their reality.

The “30-Second Wow”

Through rapid AI-assisted prototyping, we aim for the “30-Second Wow.” Within thirty seconds of seeing a visual, a stakeholder should realize they explained their need incorrectly. It is better to fail in a mockup than in expensive production code.

The Graphic Novel Workflow

For complex Epics, we use AI to illustrate the human journey:

1. Character Reference Sheets: AI-generated personas for visual consistency.

2. The “Before” Panels: Illustrating the current pain points and frustrations.

3. The “After” Panels: Illustrating the value and relief after implementation.

4. Storyboard Generation: Using AI to show the human experience, not just UI screenshots.

---

6. The “Cockpit” Methodology: From Information to Action

A high-quality interface is a Cockpit, not a Dashboard.

• Dashboard: Passive information (like an airport flight board).

• Cockpit: Actionable data with controls (like a pilot’s instruments).

The Batmobile vs. The Batcave

A Cockpit must adapt to the role and the task. In the Batmobile, chasing a lead, the pilot needs high-speed, task-specific controls. In the Batcave, the analyzer needs broad, environmental data. Your UI must shift based on whether the user is driving or analyzing.

The Cockpit Litmus Test

Ask these two questions of every screen:

1. Does this lead to a decision? If not, the user will become “blind” to it.

2. Can the user act on that decision from here? If they must navigate away, you’ve built a dashboard.

Examples: Quality Alerts with direct supplier links; Configurable Thresholds that interpret “good” vs “bad”; and Actionable Inventory that allows a Purchase Order creation directly from an “oversold” alert.

---

7. Closing the Loop: Living Documentation and BDD

Behavior-Driven Development (BDD) is a conversation practice first and an automation practice second. The automation question can wait; clarity cannot.

GWT Everywhere

To minimize the “context switch tax,” use Given-When-Then (GWT) across the entire stack—from UI components to API specs. This keeps the conversation in plain English, accessible to all stakeholders.

Natural Language vs. Implementation-Dressed-in-English

We must be demanding about language. Tests must remain stable during refactoring by focusing on behavior rather than implementation.

• Incorrect (Implementation-Dressed-in-English): “Select 4 days from the duration dropdown and click ‘Create’.”

• Correct (Natural Language): “Given I want to plan a 4-day trip to Paris…”

The AI-First Execution Loop

Our workflow is a consistent cycle using specialized agents:

1. Conversation: Record and transcribe stakeholder needs.

2. Human Stories: Use tools to create “In Order To” stories and GWT scenarios.

3. Automated Validation: Use AI to generate end-to-end tests directly from the GWT scenarios.

4. Living Documentation: Generate feature overviews with screenshots from successful end-to-end test runs.

5. Refinement: Use tools to refine design and implementation.

---

Conclusion: Pace Yourself

In software, as on the race track, you must slow down to go fast. We “walk the track” first—identifying values, aspirations, and intent—before we ever touch the throttle. By building calluses on the “cheap guitar” of clear thinking and rigorous intent, we can eventually pick up the “expensive guitar” of high-end AI models and truly “melt faces.” Invest in clarity today so your AI-assisted delivery remains consistently fast, rather than just intensely wrong.