BONUS: When AI Knows Your Emotional Triggers Better Than You Do — Navigating Mindfulness in the AI Age

In this thought-provoking conversation, former computer engineer and mindfulness leader Mo Edjlali explores how AI is reshaping human meaning, attention, and decision-making. We examine the critical question: what happens when AI knows your emotional triggers better than you know yourself? Mo shares insights on remaining sovereign over our attention, avoiding dependency in both mindfulness and technology, and preparing for a world where AI may outperform us in nearly every domain.

From Technology Pioneer to Mindfulness Leader

"I've been very heavily influenced by technology, computer engineering, software development. I introduced DevOps to the federal government. But I have never seen anything change the way in which human beings work together like Agile." — Mo Edjlali

 

Mo's journey began in the tech world — graduating in 1998, he was on the front line of the internet explosion. He remembers the days before the internet, watched online multiplayer games emerge in 1994, and worked on some of the most complicated tech projects in federal government. Technology felt almost like magic, advancing at a logarithmic rate faster than anything else. But when Mo discovered mindfulness practices 12-15 years ago, he found something equally transformative: actual exercises to develop emotional intelligence and soft skills that the tech world talked about but never taught. Mindfulness provided logical, practical methods that didn't require "woo-woo" beliefs — just practice that fundamentally changed his relationship with his mind. This dual perspective — tech innovator and mindfulness teacher — gives Mo a unique lens for understanding where we're headed.

The Shift from Liberation to Dependency

"I was fortunate enough, the teachers I was exposed to, the mentality was very much: you're gonna learn how to meditate on your own, in silence. There is no guru. There is no cult of personality." — Mo Edjlali

 

Mo identifies a dangerous drift in the mindfulness movement: from teaching independence to creating dependency. His early training, particularly a Vipassana retreat led by S.N. Goenka, modeled true liberation — you show up for 10 days, pay nothing, receive food and lodging, learn to meditate, then donate what you can at the end. Critically, you leave being able to meditate on your own without worshiping a teacher or subscribing to guided meditations. But today's commercialized mindfulness often creates the opposite: powerful figures leading fiefdoms, consumers taught to listen to guided meditations rather than meditate independently. This dependency model mirrors exactly what's happening with AI — systems designed to make us rely on them rather than empower our own capabilities. Recognizing this parallel is essential for navigating both fields wisely.

AI as a New Human Age, Not Just Another Tool

"With AI, this is different. This isn't like mobile computing, this isn't like the internet. We're entering a new age. We had the Bronze Age, the Iron Age, the Industrial Age. When you enter a new age, it's almost like knocking the chess board over, flipping the pieces upside down. We're playing a new game." — Mo Edjlali

 

Mo frames AI not as another technology upgrade but as the beginning of an entirely new human age. In a new age, everything shifts: currency, economies, government, technology, even religions. The documentary about the Bronze Age collapse taught him that when ages turn over, the old rules no longer apply. This perspective explains why AI feels fundamentally different from previous innovations. ChatGPT 2.0 was interesting; ChatGPT 3 blew Mo's mind and made him realize we're witnessing something unprecedented. While he's optimistic about the potential for sustainable abundance and extraordinary breakthroughs, he's also aware we're entering both the most exciting and most frightening time to be alive. Everything we learned in high school might be proven wrong as AI rewrites human knowledge, translates animal languages, extends longevity, and achieves things we can't even imagine.

The Mental Health Tsunami and Loss of Purpose

"If we do enter the age of abundance, where AI could do anything that human beings could do and do it better, suddenly the system we have set up — where our purpose is often tied to our income and our job — suddenly, we don't need to work. So what is our purpose?" — Mo Edjlali

 

Mo offers a provocative vision of the future: a world where people might pay for jobs rather than get paid to work. It sounds crazy until you realize it's already happening — people pay $100,000-$200,000 for college just to get a job, politicians spend millions to get elected. If AI handles most work and we enter an age of abundance, jobs won't be about survival or income — they'll be about meaning, identity, and social connection. This creates three major crises Mo sees accelerating: attacks on our focus and attention (technology hijacking our awareness), polarization (forcing black-and-white thinking), and isolation (pushing us toward solo experiences). The mental health tsunami is coming as people struggle to find purpose in a world where AI outperforms them in domain after domain. The jobs will change, the value systems will shift, and those without tools for navigating this transformation will suffer most.

When AI Reads Your Mind

"Researchers at Duke University had hooked up fMRI brain scanning technology and took that data and fed it into GPT 2. They were able to translate brain signals into written narrative. So the implications are that we could read people's minds using AI." — Mo Edjlali

 

The future Mo describes isn't science fiction — it's already beginning. Three years ago, researchers used early GPT to translate brain signals into written text by scanning people's minds with fMRI and training AI on the patterns. Today, AI knows a lot about heavy users like Mo through chat conversations. Tomorrow, AI will have video input of everything we see, sensory input from our biometrics (pulse, heart rate, health indicators), and potentially direct connection to our minds. This symbiotic relationship is coming whether we're ready or not. Mo demonstrates this with a personal experiment: he asked his AI to tell him about himself, describe his personality, identify his strengths, and most powerfully — reveal his blind spots. The AI's response was outstanding, better than what any human (even his therapist or himself) could have articulated. This is the reality we're moving toward: AI that knows our emotional triggers, blind spots, and patterns better than we do ourselves.

Using AI as a Mirror for Self-Discovery

"I asked my AI, 'What are my blind spots?' Human beings usually won't always tell you what your blind spots are, they might not see them. A therapist might not exactly see them. But the AI has... I've had the most intimate kind of conversations about everything. And the response was outstanding." — Mo Edjlali

 

Mo's approach to AI is both pragmatic and experimental. He uses it extensively — at the level of teenagers and early college students who are on it all the time. But rather than just using AI as a tool, he treats it as a mirror for understanding himself. Asking AI to identify your blind spots is a powerful exercise because AI has observed all your conversations, patterns, and tendencies without the human limitations of forgetfulness or social politeness. Vasco shares a similar experience using AI as a therapy companion — not replacing his human therapist, but preparing for sessions and processing afterward. This reveals an essential truth: most of us don't understand ourselves that well. We're blind navigators using an increasingly powerful tool. The question isn't whether AI will know us better than we know ourselves — that's already happening. The question is how we use that knowledge wisely.

The Danger of AI Hijacking Our Agency

"There's this real danger. I saw that South Park episode about ChatGPT where his wife is like, 'Come on, put the AI down, talk to me,' and he's got this crazy business idea, and the AI keeps encouraging him along. It's a point where he's relying way too heavily on the AI and making really poor decisions." — Mo Edjlali

 

Not all AI use is beneficial. Mo candidly admits his own mistakes — sometimes leaning into AI feedback over his actual users' feedback for his Meditate Together app because "I like what the AI is saying." This mirrors the South Park episode's warning about AI dependency, where the character's AI encourages increasingly poor decisions while his relationships suffer. Social media demonstrates this danger at scale: AI algorithms tuned to steal our attention and hijack our agency, preventing us from thinking about what truly matters — relationships and human connection. Mo shares a disturbing story about Zoom bombers disrupting Meditate Together sessions, filming it, posting it on YouTube where it got 90,000 views, with comments thanking the disruptors for "making my day better." Technology created a cannibalistic dynamic where teenagers watched videos of their mothers, aunts, and grandmothers being harassed during meditation. When Mo tried to contact Google, the company's incentive structure prioritized views and revenue over human decency. Technology combined with capitalism creates these dangerous momentum toward monetizing attention at any cost.

Remaining Sovereign Over Your Attention

"Traditionally, mindfulness does an extraordinary job, if you practice right, to help you regain your agency of your focus and concentration. It takes practice. But reading is now becoming a concentration practice. It's an actual practice." — Mo Edjlali

 

Mo identifies three major symptoms affecting us: attacks on focus/attention, polarization into black-and-white thinking, and isolation. Mindfulness practices directly counter all three — but only if practiced correctly. Training attention, focus, and concentration requires actual practice, not just listening to guided meditations. Mo offers practical strategies: reading as concentration practice (asking "does anyone read anymore?" recognizing that sustained reading now requires deliberate effort), turning off AirPods while jogging or driving to find silence, spending time alone with your thoughts, and recognizing that we were given extraordinary power (smartphones) with zero training on how to be aware of it. Older generations remember having to rewind VHS tapes — forced moments of patience and stillness that no longer exist. We need to deliberately recreate those spaces where we're not constantly consuming entertainment and input.

Dialectic Thinking: Beyond Polarization

"I saw someone the other day wear a shirt that said, 'I'm perfect the way I am.' That's one-dimensional thinking. Two-dimensional thinking is: you're perfect the way that you are, and you could be a little better." — Mo Edjlali

 

Mo's book OpenMBSR specifically addresses polarization by introducing dialectic thinking — the ability to hold paradoxes and seeming contradictions simultaneously. Social media and algorithms push us toward one-dimensional, black-and-white thinking: good/bad, right/wrong, with me/against me. But reality is far more nuanced. The ability to think "I'm perfect as I am AND I can improve" or "AI is extraordinary AND dangerous" is essential for navigating complexity. This mirrors the tech world's embrace of continuous improvement in Agile — accepting where you are while always pushing for better. Chess players learned this years ago when AI defeated humans — they didn't freak out, they accepted it and adapted. Now AI in chess doesn't just give answers; it helps humans understand how it arrived at those answers. This partnership model, where AI coaches us through complexity rather than simply replacing us, represents the healthiest path forward.

Building Community, Not Dependency

"When people think to meditate, unfortunately, they think, I have to do this by myself and listen to guided meditation. I'm saying no. Do it in silence. If you listen to guided meditation, listen to guided meditation that teaches you how to meditate in silence. And do it with other people, with intentional community." — Mo Edjlali

 

Mo's OpenMBSR initiative explicitly borrows from the Agile movement's success: grassroots, community-centric, open source, transparent. Rather than creating fiefdoms around cult personalities, he wants mindfulness to spread organically through communities helping communities. This directly counters the isolation trend that technology accelerates. Meditate Together exists specifically to create spaces where people meditate with other human beings around the world, with volunteer hosts holding sessions. The model isn't about dependency on a teacher or platform — it's about building connection and shared practice. This aligns perfectly with how the tech world revolutionized collaborative work through Agile and Scrum: transparent, iterative, valuing individuals and interactions. The question for both mindfulness and AI adoption is whether we'll create systems that empower independence and community, or ones that foster dependency and isolation.

Preparing for a World Where AI Outperforms Humans

"AI is going to need to kind of coach us and ease us into it, right? There's some really dark, ugly things about ourselves that could be jarring without it being properly shared, exposed, and explained." — Mo Edjlali

 

Looking at his children, Mo wonders what tools they'll need in a world where AI may outperform humans in nearly every domain. The answer isn't trying to compete with AI in calculation, memory, or analysis — that battle is already lost. Instead, the essential human skills become self-awareness, emotional intelligence, dialectic thinking, community building, and maintaining agency over attention and decision-making. AI will need to become a coach, helping humans understand not just answers but how it arrived at those answers. This requires AI development that prioritizes human growth over profit maximization. It also requires humans willing to do the hard work of understanding themselves — confronting blind spots, managing emotional triggers, practicing concentration, and building genuine relationships. The mental health tsunami Mo predicts isn't inevitable if we prepare now by teaching these skills widely, building community-centric systems, and designing AI that empowers rather than replaces human wisdom and connection.

 

About Mo Edjlali

 

Mo Edjlali is a former computer engineer, and also the founder and CEO of Mindful Leader, the world's largest provider of Mindfulness-Based Stress Reduction training. Mo's new book Open MBSR: Reimagining the Future of Mindfulness explores how ancient practices can help us navigate the AI revolution with awareness and resilience.

 

You can learn more about Mo and his work at MindfulLeader.org, check out Meditate Together, and read his articles on AI's Mind-Reading Breakthrough and AI: Not Another Tool, but a New Human Age.

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20251129_Mo_Edjlali_BONUS.mp3?dest-id=246429

Docker recently announced the release of Docker Desktop 4.50, marking another update for developers seeking faster, more secure workflows and expanded AI-integration capabilities.

By Craig Risi

Evalite is a TypeScript-native eval runner designed for AI applications, enabling developers to create reproducible evals with rich outputs. Featuring first-class trace capture, scoring, and a user-friendly web UI, Evalite enhances testing ergonomics and iteration speed. Open-source under MIT, it seamlessly integrates with any LLM, ensuring complete data control and fostering rapid development.

By Daniel Curtis

Picture this. Product wants a minor discount tweak: if an order total is below 100, no discount. You open an endpoint, add a conditional, save and push. Ten minutes, job done.

Three months later, that simple rule exists in six different endpoints, each with its own tiny twist. Someone fixes a bug in two of them, forgets the others, and now nobody can answer a basic question: what is the real discount rule in this system?

That creeping mess has a name: Transaction Script.

Most teams start here. Some stay here forever and pay for it in every release. This post walks through what Transaction Script really is, how it looks in ASP.NET Core, where it shines, and how to recognize when it stops being a shortcut and becomes structural debt.

You will see C# examples of a pure Transaction Script, followed by a first refactoring step that opens the door to a richer design.

What Transaction Script Actually Is

Transaction Script treats each use case as a single procedure that does everything:

• Reads the request
• Loads data
• Applies business rules
• Persists changes
• Shapes the response

There is no separate domain model with behavior, no dedicated service layer that orchestrates aggregates. There is one script per scenario.

The pattern is not automatically wrong. It is brutally simple, which makes it powerful in the proper context and dangerous when the domain keeps growing.

A Concrete Example: Apply Discount as a Transaction Script

Here is a straight Transaction Script inside an ASP.NET Core minimal API endpoint.

app.MapPost("/discounts/apply", async (ApplyDiscountDto dto, AppDbContext db) =>
{
    var customer = await db.Customers.FindAsync(dto.CustomerId);
    if (customer == null)
    {
        return Results.NotFound("Customer not found.");
    }

    var order = await db.Orders
        .Include(o => o.Lines)
        .FirstOrDefaultAsync(o => o.Id == dto.OrderId && o.CustomerId == dto.CustomerId);

    if (order == null)
    {
        return Results.NotFound("Order not found.");
    }

    var total = order.Lines.Sum(l => l.Quantity * l.UnitPrice);

    if (total < 100)
    {
        return Results.BadRequest("Order total too low for discount.");
    }

    order.ApplyDiscount(dto.DiscountPercent);
    await db.SaveChangesAsync();
    return Results.Ok(new { order.Id, order.TotalAmount });
});

public record ApplyDiscountDto(Guid CustomerId, Guid OrderId, decimal DiscountPercent);

Everything lives in one block:

• Data access through AppDbContext
• Business rule about the minimum total
• Behavior that applies a discount
• HTTP responses and status codes

That is pure Transaction Script: a single procedure handles the entire transaction.

When Transaction Script Makes Sense

Used deliberately, Transaction Script fits real scenarios.

Small, Focused Endpoints

If a feature is bounded and straightforward, a script like this can be ideal:

• One administrative endpoint that fixes a specific data issue
• A tiny internal API for a tool that may never grow beyond a handful of operations
• A migration utility that processes a file and writes the results once

In these cases, creating a rich domain model or elaborate service layer can be pure overhead.

Short-Lived Features And Experiments

Sometimes you need a spike:

• Experiment with a new discount rule to see if customers respond
• Build an internal endpoint that may be replaced by a better system later
• Capture data for a temporary campaign

A Transaction Script lets you wire this up rapidly. If the feature dies quickly, you never pay a heavy design cost.

Teams Under Immediate Delivery Pressure

There are moments when:

• The business is blocked until a particular rule exists
• You are in the middle of an incident and need a quick workaround
• The system is early, and the domain rules are still chaotic

In those conditions, a well-written script can keep the system moving while you learn what the real domain boundaries look like.

The critical word there is “while”. At some point, the domain stabilizes. If the scripts remain the main design element, they become anchors.

The Real Cost: Repeating Yourself Into A Corner

The example above does not look frightening. The trouble starts when requirements evolve.

Imagine:

• A new discount rule for VIP customers that uses a lower threshold
• Another use case that applies discounts during checkout, not only via this endpoint
• A batch job that reconciles discounts at the end of the day

Every time you add a rule in script form, you have a choice:

• Copy the logic into the new script
• Call the existing script from somewhere strange
• Extract part of it into a helper or static method

Most teams take the fastest path, which often means copy, tweak, repeat. After a few iterations you have:

• Slightly different minimum totals scattered across scripts
• Conditionals that no one dares to touch because they are not sure who depends on them
• Business logic that can only be understood by reading several endpoints line by line

At that stage, you are not doing “simple procedural code”. You are maintaining a distributed domain model made of duplicated fragments.

Recognizing When Your Scripts Are Out Of Control

You do not need a fancy metric. Look for these practical signals.

Same Rule, Many Places

Search for the literal “Order total too low for discount” string. If you find variations of the same check in multiple endpoints or handlers, you already have a smell.

• Different thresholds per scenario, but no central decision point
• Edge conditions handled in some scripts, forgotten in others

That is a sign that the domain concept “discount eligibility” deserves its own abstraction.

Scripts That Do Everything

If an endpoint:

• Validates input
• Loads multiple aggregates
• Calculates totals
• Applies discounts
• Logs audits
• Sends notifications
• Saves changes

You no longer have a transaction script… You have a transaction novel. Changing anything inside that block risks side effects everywhere.

Testing Feels Painful

If writing tests for your discount behavior:

• Requires spinning up a full test server
• Requires hitting HTTP routes for every variant
• Requires seeding a complex database state repeatedly

Then the rules are too entangled with infrastructure. Transaction Scripts have swallowed your business logic.

First Refactor: Keep The Script, Extract The Rule

You do not need to jump straight from scripts to a full Domain Model. The first step can be modest: pull core rules into a domain abstraction, let the script delegate.

Introduce a small domain service that knows how discounts work.

public interface IDiscountPolicy
{
    DiscountDecision Evaluate(decimal orderTotal, decimal requestedPercent);
}

public record DiscountDecision(bool IsAllowed, string? Reason);

public class MinimumTotalDiscountPolicy : IDiscountPolicy
{
    private readonly decimal _minimumTotal;

    public MinimumTotalDiscountPolicy(decimal minimumTotal)
    {
        _minimumTotal = minimumTotal;
    }

    public DiscountDecision Evaluate(decimal orderTotal, decimal requestedPercent)
    {
        if (orderTotal < _minimumTotal)
        {
            return new DiscountDecision(false, "Order total too low for discount.");
        }

        if (requestedPercent <= 0 || requestedPercent >= 50)
        {
            return new DiscountDecision(false, "Discount percent out of allowed range.");
        }

        return new DiscountDecision(true, null);
    }
}

Now change the script to use this policy.

app.MapPost("/discounts/apply", async (
    ApplyDiscountDto dto,
    AppDbContext db,
    IDiscountPolicy discountPolicy) =>
{
    var customer = await db.Customers.FindAsync(dto.CustomerId);
    if (customer == null)
    {
        return Results.NotFound("Customer not found.");
    }

    var order = await db.Orders
        .Include(o => o.Lines)
        .FirstOrDefaultAsync(o => o.Id == dto.OrderId && o.CustomerId == dto.CustomerId);

    if (order == null)
    {
        return Results.NotFound("Order not found.");
    }

    var total = order.Lines.Sum(l => l.Quantity * l.UnitPrice);
    var decision = discountPolicy.Evaluate(total, dto.DiscountPercent);

    if (!decision.IsAllowed)
    {
        return Results.BadRequest(decision.Reason);
    }

    order.ApplyDiscount(dto.DiscountPercent);
    await db.SaveChangesAsync();
    return Results.Ok(new { order.Id, order.TotalAmount });
});

You still have a Transaction Script. It still coordinates the transaction. Something important has changed.

• The rule about whether a discount is allowed now lives in one place
• Other scripts or background jobs can reuse IDiscountPolicy
• You can unit test the policy with plain C# tests without a test server or database

This is the hinge where your system can move toward a Domain Model or a more structured Service Layer.

When Transaction Script Should Give Way To Other Patterns

Once a rule becomes central to the product, you want more than a simple procedure.

Domain Model For Rich, Interconnected Rules

If discounts:

• Depend on customer status, product category, time of day, and campaign rules
• Interact with loyalty points, tax calculations, and fulfillment
• Require sophisticated validation and simulation

then a Domain Model gives you a place to express those relationships. Aggregates, value objects, and domain services can capture those rules in a way that scripts never will.

In that world, discount logic might live inside an Order aggregate or a dedicated DiscountEngine, tested directly and used from multiple entry points.

Table Module For Table Focused Operations

If most of the logic operates on a single table or view, such as OrderSummary or InvoiceRow, and the operations are set-oriented, a Table Module can be enough.

A DiscountTableModule class that encapsulates queries and updates for discount fields can centralize behavior without inventing a full object model.

The critical point is not the pattern’s name. It is whether the rules live in a singular, testable place, rather than in scattered fragments.

Practical Guidelines For .NET Teams

If you build ASP.NET Core systems, you can treat Transaction Script as a controlled tool rather than a reflexive default.

• Use scripts for isolated use cases with simple rules and short life spans
• Watch for duplication: once a rule appears in more than one script, extract it into a domain component
• Keep orchestration and infrastructure in the script, push domain decisions into services or entities
• Add tests around the extracted domain pieces before you touch the scripts again

The goal is not to outlaw Transaction Script. The goal is to avoid waking up one day in a codebase where every important rule lives inside an untested endpoint.

A Challenge For Your Current Codebase

Pick one feature today:

1. Find an endpoint or handler that reads from the database, applies a rule, and writes back in a single method.
2. Identify a single rule inside that method that business people care about.
3. Extract that rule into a domain service or helper with its own unit tests.
4. Leave the rest of the script intact, let the endpoint call the new abstraction.

Run the tests. Show that nothing changed in behavior. Then ask yourself: if this one small extraction already made the rule clearer, what happens when you repeat that move across the parts of the system that hurt the most?

That is how Transaction Script turns from a permanent architecture into a stepping stone.

The post Enterprise Patterns for ASP.NET Core Minimal API: Transaction Script Pattern – The Shortcut That Quietly Reshapes Your System first appeared on Chris Woody Woodruff | Fractional Architect.

In this episode Alec and Brian talk about AI, turkey, and AI turkey?

Download audio: https://anchor.fm/s/104ead10c/podcast/play/111867649/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-10-29%2F413395343-44100-2-d89f910124d9c.mp3

I am back to my work to precisely define how we integrate with many different APIs. With this round I am doing it for a handful of use cases meant to satisfy customer conversations around their AI integration needs. If you’ve been tuned into my newsletter than you’ll know that I am wrestling with defining these conversations in the context of a capability. Not an API capability, but just a capability that describes something we need to be capable of when it comes to our businesses. As part of this work I am aggregating many voices from stories I’ve read online, but also podcast episodes I am producing as part of this work. Across these stories I regularly hear how a capability is a wrapper for everything you need to integrate with AI—something that like AI, often seems pretty hand wavy.

Everyone I am talking with is someone willing to do the work to define the technical details of what a capability is, but I don’t think everyone is willing to do the work to define the business details of what a capability is. I don’t think this is any nefarious act—it is just that we aren’t used to prioritizing these things in engineering circles. In my experience, the engineering folks who I sit down to define all of the technical details aren’t always equipped or willing to sit down and go through the business details. The same is on the other side of things, and the business folks who I sit down to define all the business details aren’t always equipped or willing to sit down and go through all the technical details. With the folks willing and able to do work on both sides being a very rare beast.

The result is that you encounter people on both sides who are on board with the concept of a capability helping define the future of integrations as they are needed to drive our businesses, but things get pretty hand wavy about the details of what that means, and there is very little connecting of the dots across the business and engineering landscape. I’d say the technical details get the lion share of work, and the business details just being left unspecified, or not connected with the technical details—resulting in drift down the road. You often just end up with two distinct sets of specifications, that may or may not be connected, but as the road map rolls forward, this disconnect becomes greater over time, resulting in much of the friction and pain associated with legacy systems.

The concept of a capability is pretty powerful for bridging these two worlds. You can define, educate, govern, and align across what the two groups want. It also lets you set the context window for not just aligning with AI applications, but any application, as well as the human coordination, communication, and collaboration required to make this work. Capabilities exist within a domain, which has a well-defined vocabulary for tagging and organizing everything into meaningful boundaries. Capabilities have a well-defined set of services that are being used—including the business and technical details of these services. This alone, will help reduce the “everything you need to integrate with AI” to something that is manageable and communicated across the business and engineering groups, but also with the non-human interactions that are increasingly required to do business.