The promise of Generative Artificial Intelligence is seductive: instant code, solutions in seconds, and skyrocketing productivity. But for project management roles, this raises an uncomfortable question: if machines don’t get tired, do we expect our human teams to keep up with that pace? In this productivity boom, XP’s “sustainable pace” is the only guarantee that your team won’t implode from burnout.

This is where Extreme Programming (XP) comes back into the spotlight, not as an engineering methodology, but as a manifesto for human sustainability. Paradoxically, to move at AI speed, we need the safety brakes and psychological well-being that Kent Beck designed in the ’90s.

How does XP ensure well-being in “high-speed” environments?

Unlike other agile frameworks that sometimes turn into a “ticket factory,” XP has explicit principles around team mental health. These are not HR suggestions—they are strict technical rules.

• The Sustainable Pace rule

XP explicitly forbids heroics. The premise is simple: a tired person introduces more bugs in one hour than they can fix in two. XP states that if overtime happens one week, it’s an exception. If it happens two weeks in a row, the problem lies in the plan, not the team.

• Psychological safety (the value of “courage”)

XP requires the courage to say “no” or “I don’t know”, but it also requires leadership to respect and listen to that truth. By eliminating fear-based estimation and replacing it with “accepted responsibility”—where the person doing the work estimates the work—anxiety around unrealistic deadlines is drastically reduced.

• The end of the “lone wolf” concept

Through Collective Code Ownership, XP removes the stress of being “the only person who knows how this works.” If someone gets sick or goes on vacation, the project doesn’t stop—and no one has to take emergency calls from the beach.

Is AI the end of Pair Programming or its rebirth?

One of the most controversial XP practices has always been Pair Programming (two people, one computer). With tools like Copilot, ChatGPT, Windsurf, Cursor, and many others, many managers ask: “Why pay for two people if I have AI?”

To the question of whether AI will replace developers, we can respond with an analogy: “Autopilot in airplanes has been around for decades, optimizing work—but it has never replaced the pilot. Why is the human factor still necessary?”

In software teams, we cannot rely solely on Vibe Coding (just as we cannot rely only on autopilot in aviation).

Vibe Coding produces code that seems to work but is incomprehensible and ultimately unmaintainable, leading to production failures due to lack of human oversight, with much higher long-term cost and impact.

To avoid this scenario, XP proposes a crucial evolution:

• From “Driver and Navigator” to “Cyborg Pairing”. AI doesn’t replace people—it elevates the pair. In this new model, AI acts as a “learning accelerator” for junior profiles, reducing the time spent searching for information—but (and this is critical) without removing the need for human validation.
• The danger of “Vibe Coding”. Martin Fowler and Kent Beck warn about the risk of accepting AI-generated code just because it “seems to work.” XP acts as a counterbalance: human Pair Programming remains essential for strategy and architectural design—areas where AI tends to hallucinate or introduce complex technical debt. AI writes, humans navigate, and XP sets the traffic rules.

TDD: why work twice as hard to go faster?

XP requires writing the test before the code (Test-Driven Development).

• TDD is not a testing technique—it’s an anxiety management technique. Knowing you have an automated safety net that alerts you in seconds if something breaks gives the team “extreme” confidence.
• AI excels at generating tests. Using AI to generate the TDD test suite before writing the code is the ultimate productivity hack. It turns AI into the strictest quality gatekeeper.

The death of documentation (as we know it)

XP has a reputation for lacking documentation, which is false—but it stems from breaking away (with the Agile manifesto) from the traditional approach of the ’80s (pages and pages of documentation rarely used).

• XP relies on clean code practices and self-explanatory code that others can understand without context.
• Today, AI tools can read XP’s clean code and automatically generate business documentation. But this only works if the team follows XP’s discipline of “Simplicity” and proper naming. If the code is a mess, AI will document a mess.

Conclusion: returning to the human to survive the artificial

In the age of AI, speed is a commodity. Anyone can generate code quickly. A team’s competitive advantage is no longer how much code it produces, but its ability to maintain it, adapt it, and—above all—avoid imploding from burnout in the process. XP is the methodology that reminds us that software is built by people, for people.

This detail, which might seem trivial, is precisely what separates a well-crafted, thoughtfully designed digital product from a generic, dull application.

That said, there’s no need to overload your website with unnecessary animations. But when you use them in the right place (like on that primary action button), you achieve something very powerful: giving users immediate and satisfying feedback.
And the truth is, creating these kinds of animations is much easier than it seems. So in today’s post, we’ll build, step by step, a particle-based microinteraction for a like button.

What tools are we going to need?

For this project, we’ll use HTML, CSS, and JavaScript, but the real animation engine will be GSAP.

If you haven’t heard of GSAP, it’s one of the most popular tools for animating almost anything on the web. It saves a lot of time (and lines of code) compared to doing it natively.

I’ve prepared a CodePen example so you can try it out and see the final result right away, but we’ll still go through it step by step. You can check it out here: Like Button (GSAP)

HTML Structure: defining the semantic structure of the button

To get started, we’ll set up a basic HTML structure. The most important part here—besides linking our local style and logic files—is importing the required libraries so the particle animation can work properly.

<html>
  <head>
    <meta charset="UTF-8">
    <link rel="stylesheet" href="./style.css">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Like Button</title>
  </head>
  <body>
    <!-- GSAP -->
    <script src="https://unpkg.com/gsap@3/dist/gsap.min.js"></script>
    <script src="https://assets.codepen.io/16327/Physics2DPlugin3.min.js"></script>

    <!-- SCRIPT -->
    <script src="./script.js"></script>
  </body>
</html>

For this effect to work properly, we need to import two key pieces from the GSAP ecosystem:

• GSAP Core: this is the main engine of the library. It allows us to create timelines and manage the basic properties of the elements we’re going to animate.
• Physics2DPlugin: this plugin acts as the physics simulation engine for the animation. It lets us define parameters such as gravity, velocity, and dispersion angle, delegating all the complex mathematical calculations to GSAP to achieve realistic trajectories.

Note: the Physics2D plugin is a premium GSAP tool. In this example, we use it via a specific URL for CodePen usage, but it requires a license if you plan to implement it in a commercial project.

Now, inside our <body> (and always before the <script> tags), we’ll add the button structure.

<button id="like-btn">
  <div id="emitter">
    <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2" stroke="currentColor">
      <path stroke-linecap="round" stroke-linejoin="round" d="M21 8.25c0-2.485-2.099-4.5-4.688-4.5-1.935 0-3.597 1.126-4.312 2.733-.715-1.607-2.377-2.733-4.313-2.733C5.1 3.75 3 5.765 3 8.25c0 7.22 9 12 9 12s9-4.78 9-12Z" />
    </svg>
  </div>
  <span>Like</span>
</button>

In this structure, we’ve defined two important identifiers:

• like-btn: this is the ID of the main button. We’ll use it in JavaScript to listen for the click event and to manage style or text changes when the user interacts with it.
• emitter: this element is essential. It acts as the container for the icon, but its main purpose is to serve as the "origin point" for the particles. By keeping it separate, we can ensure that the explosion starts exactly from the position of the heart, rather than from any part of the button.

CSS Styles: preparing the look & feel and the container

To define the styles, we’ll create a file called style.css. The first step is to import the typography and define a set of CSS variables (Custom Properties). This will allow us to manage colors and reusable values from a single place, making our design much easier to maintain.

@import url('https://fonts.googleapis.com/css2?family=DM+Sans:ital,opsz,wght@0,9..40,100..1000;1,9..40,100..1000&display=swap');

:root{
  --color-bg: #e9ecef;
  --color-primary: #495057;
  --color-accent: #ff3562;
  --color-on-accent: #ffffff;

  --text-sm: 1.1em;
  --text-md: 1.8rem;
    
  --transition-default: all 0.25s ease;
}

Next, we'll define the global style to clear the margins and center our button on the screen.

*{
  font-family: "DM Sans", sans-serif;
}

body,
html {
  height: 100%;
  margin: 0;
  padding: 0;
  overflow: hidden;
}

body {
  display: flex;
  align-items: center;
  justify-content: center;
  flex-direction: column;
  min-height: 100vh;
    background-color: var(--color-bg);
}

In addition, we'll set up the .particles-container class. Although we'll create this container dynamically in JavaScript, for the sake of code clarity, we'll define its style here:

.particles-container {
  position: absolute;
  left: 0;
  top: 0;
  overflow: visible;
  z-index: 2;
  pointer-events: none;
  opacity: 0;
}

In the .particles-container class, there are a few properties that deserve special attention:

• z-index: 2: the z-index property controls the stacking order of elements along the Z-axis (depth). By default, elements have a value of 1 (or auto). If we want the particles to explode above the button and not be hidden behind it, we need to assign them a higher value—in this case, 2.
• pointer-events: none: this property is key. It prevents the particles from interfering with mouse interactions. This way, even if a particle passes over the cursor, the user can still click the button without any issues.
• opacity: 0: initially, the container is invisible. We’ll only reveal it with GSAP at the exact moment of the animation.

The next step is to define the style of our button. You’ll notice that we make use of the CSS variables defined earlier, which helps keep the code cleaner and more consistent.

We’ll also prepare the .clicked state. This class will be added via JavaScript when the button is clicked, allowing us to modify the style of the button and its inner elements (such as the icon and the text):

button{
  border-radius: 8px;
  cursor: pointer;
  padding: 12px 26px;
  font-size: var(--text-md);
  border: 2px solid var(--color-primary);
  display: flex;
  align-items: center;
  gap: 12px;
  color: var(--color-primary);
  background-color: #e9ecef;
  transition: var(--transition-default);
}

button.clicked{
  border-color: var(--color-accent);
  background-color: var(--color-accent);
  color: var(--color-on-accent);
}

button svg{
  width: var(--text-sm);
  fill: var(--color-primary);
  stroke: var(--color-primary);
  transition: var(--transition-default);
}

button.clicked svg{
  fill: var(--color-on-accent);
  stroke: var(--color-on-accent);
}

Finally, we need to define the particle's appearance. In this example, we've chosen a design featuring circular dots. However, you can customize this style however you like.

.dot {
  position: absolute;
  border-radius: 50%;
}

JavaScript Logic: building the particle system with GSAP

It’s time to take action. Now we’ll set up the logic required for the button to respond to clicks and generate the particle explosion. We’ll manage this entire process from our script.js file.

Step 1. Register GSAP plugins

The first thing we need to do is register the plugin with the GSAP core engine. This is essential so the library can recognize the physical properties we’ll use later.

gsap.registerPlugin(Physics2DPlugin);

Step 2. Declare the elements

In this step, we’ll capture the DOM elements we’re going to interact with. We’ll also take the opportunity to dynamically create the container where our particles will live:

// Main emitter element (used as explosion origin)
const emitter = document.getElementById("emitter");

// Like button + text
const likeBtn = document.getElementById("like-btn");
const text = likeBtn.querySelector("span");

// Container that holds all particles
const container = document.createElement("div");
container.className = "particles-container";
document.body.appendChild(container);

Step 3. GSAP configuration and states

At this point, we’ll define the variables that control the behavior of our animation. What’s interesting about this approach is that, by simply tweaking these values, you can completely transform the effect.

I encourage you to experiment with parameters like velocity or gravity to see how the physics of the motion changes. In addition, in this step we’ll also declare the initial state of the button:

const emitterSize = 2;        // spawn area radius
const dotQuantity = 12;     // number of particles
const dotSizeMax = 12;      // max particle size
const dotSizeMin = 4;       // min particle size
const speed = 0.6;            // initial velocity multiplier
const gravity = 0.1;          // gravity strength

// Toggle state (liked / not liked)
let liked = false;

Step 4. Explosion setup

In this step, we’ll create a reusable function responsible for generating the "explosion" every time it is called. The idea is to build a GSAP timeline that contains the individual animations for each particle.

const explosion = createExplosion(container);

function createExplosion(container) {
  const tl = gsap.timeline({ paused: true });

  for (let i = 0; i < dotQuantity; i++) {

    // Create particle element
    const dot = document.createElement("div");
    dot.className = "dot";

    // Assign random color
    const colors = ["#ff4d6d", "#fb6f92", "#ff8fab", "#ffb3c1", "#cdb4db", "#a2d2ff"];
    dot.style.backgroundColor = colors[Math.floor(Math.random() * colors.length)];

    container.appendChild(dot);

    // Random size & direction (angle in radians)
    const size = gsap.utils.random(dotSizeMin, dotSizeMax, 1);
    const angle = Math.random() * Math.PI * 2;

    // Initial offset inside emitter radius
    const length = Math.random() * (emitterSize / 2 - size / 2);


    gsap.set(dot, {
      x: Math.cos(angle) * length,
      y: Math.sin(angle) * length,
      width: size,
      height: size,
      xPercent: -50,
      yPercent: -50,
      force3D: true,
      scale: gsap.utils.random(0.8, 1.2)
    });

    tl.to(
      dot,
      {
        physics2D: {
          angle: (angle * 180) / Math.PI, // convert to degrees
          velocity: (120 + Math.random() * 200) * speed,
          gravity: 500 * gravity
        },
        duration: 1 + Math.random()
      },
      0
    )
    .to(
      dot,
      {
        opacity: 0,
        scale: 0.5,
        duration: 0.3,
        ease: "power2.in",
      },
      0.3
    );
  }

  return tl;
}

In this function, there are a few technical concepts we need to understand:

1. Creation loop. We use a for loop based on the dotQuantity variable to generate all particles at once. Each one gets a random color and size so the explosion doesn’t look artificial or repetitive.
2. Trajectory calculation. We use mathematical functions (Math.cos and Math.sin) to position the particles in a circle around the center point. This allows them to shoot out in all directions (360 degrees).
3. The power of Physics2D. Instead of manually animating the x and y coordinates, we simply pass an angle, velocity, and gravity to the plugin. GSAP takes care of drawing the perfect parabolic motion.
4. Synchronization (position parameters). You’ll notice that the .to() functions include a 0 or a 0.3 at the end. In GSAP, this is called a Position Parameter.

• The "0": forces all particles to start their animation exactly at second zero on the timeline. Without it, particles would appear one after another; with it, they all fire simultaneously, creating the explosion effect.
• The "0.3": indicates that the particle should start fading out (opacity 0) when the timeline reaches 0.3 seconds, allowing it to disappear while still moving, resulting in a much smoother and more natural effect.

Step 5. Explosion function

Once we have the animation logic ready, we need a function that positions the particle container in the correct place and triggers the movement. Without this step, the particles might appear in a corner of the screen instead of originating from the center of the button.

function explode(element) {
  const bounds = element.getBoundingClientRect();

  // Move container to element center
  gsap.set(container, {
    x: bounds.left + bounds.width / 2,
    y: bounds.top + bounds.height / 2,
    opacity: 1
  });

  // Restart animation from the beginning
  explosion.restart();
}

This function is responsible for positioning the effect in space: first, we use getBoundingClientRect() to calculate the exact coordinates of the button on the screen, and then, using gsap.set(), we instantly move the particle container to its center.

Finally, we execute explosion.restart() so the animation timeline resets and plays from the beginning with each new click, ensuring the explosion always originates from the correct position.

Step 6. Click event and final interaction

To wrap up, we need to detect when the user interacts with the button and trigger all the logic we’ve implemented. With the following code, we handle the state change, visual update, and particle launch:

likeBtn.addEventListener("click", () => {

  // Toggle like state
  liked = !liked;
  text.textContent = liked ? "Liked" : "Like";

  // Toggle active class (for styling)
  likeBtn.classList.toggle("clicked", liked);

  // Button press animation (quick scale feedback)
  gsap.fromTo(
    likeBtn,
    { scale: 1 },
    { scale: 0.9, duration: 0.1, yoyo: true, repeat: 1 }
  );

  // Trigger particle explosion
  liked && explode(emitter);
});

In this final block, two key things happen:

• Tactile feedback: using gsap.fromTo, we create a real press sensation by slightly scaling the button. The use of yoyo: true makes the button automatically return to its original size.
• Conditional logic: thanks to the && operator, the explode function only runs when the user hits "Like", preventing particles from triggering when the action is undone.

I hope this post has helped you better understand how these kinds of effects work and that, from now on, you feel confident enough to implement your own particle animations to add a touch of “magic” to your interfaces. Time to experiment!

In this post, we break down the reality. What happens if you don’t measure latency, cost per token, and the traceability of each call? Simply put, you end up with an experiment that’s not very useful in a professional environment.

Integrating LLMs into production requires an engineering mindset where the prompt is just the tip of the iceberg of a complex and auditable system.

Is prompting a trend or an engineering discipline?

There is a misconception that simplifies prompt engineering to just writing polite instructions for language models. The reality in development teams is very different. When you try to scale an agentic system, you quickly realize that the prompt is code and, as such, it requires versioning, testing, and constant monitoring.

We’ve seen organizations embedding prompts directly into their source code, creating an operational nightmare every time they want to tweak a comma or test a new model. Treating the prompt as an external, managed asset allows iteration without redeploying the entire microservices infrastructure.

The real problem arises when we move from a simple chat to a network of specialized agents. Here, a misinterpretation error in the “supervisor agent” can lead to an endless loop of API calls that skyrocket your monthly bill. Designing a robust AI system means controlling which model responds to each task based on its complexity.

How much does each word your model generates actually cost?

If you don’t have visibility into token consumption, you’re navigating blind. Model selection is a matter of process economics. Using high-performance models for simple classification tasks is a waste of resources, negatively impacting both budget and user experience due to accumulated latency.

In our implementations, we segment tasks: we reserve heavier models for complex reasoning and use “Flash” versions or local models for metadata extraction or intent classification.

Why settle for the first response? Prompt optimization using advanced techniques like Few-Shot or Chain of Thought improves accuracy and reduces the need for retries.

Every failed or hallucinated call means wasted time for the user and unnecessary cost. End-to-end traceability becomes essential to identify where efficiency is lost or where the model starts drifting.

Why operate a black box without real metrics?

Observability is the Achilles’ heel of many AI projects. This is where tools like Langfuse come into play, shedding light on what happens behind each request.

It’s not enough to know that the system responded—we need to know how long each node in the execution graph took, which prompt version was used, and whether the retrieved context (RAG was actually useful for the final answer.

Having a centralized prompt repository with caching policies reduces retrieval latency and ensures scalability under high demand.

Evaluation cannot be subjective. We implement “LLM-as-a-judge” systems and test datasets to automatically score toxicity, conciseness, and factual accuracy against a ground truth. Automating performance evaluation allows us to detect quality regressions before end users encounter inconsistent responses.

How does model size influence your prompt structure?

Not all LLMs process information with the same level of sophistication, and this is where cost efficiency collides with technical reality.

In our architecture, we orchestrate flash, mini, nano, or pro versions depending on the task, confirming an inverse rule: the larger the model, the less prompting effort you need. When using a powerful model, you rarely need complex prompt structures—it resolves things through brute force.

The challenge arises when optimizing for millisecond-level latency with smaller models. Technical demands grow exponentially: the lighter the model, the more precise and unambiguous your prompt must be to avoid inconsistent outputs.

Conclusions

The success of a generative AI implementation does not depend on finding the “perfect prompt,” but on building an engineering ecosystem around it.

Controlling latency, optimizing costs through smart model selection, and measuring every interaction with observability tools are essential steps for any team aiming to move beyond the prototype phase.

Operational transparency is the only way to build trust in systems that are, by nature, probabilistic.

If you still have doubts about whether anyone can work as a prompt engineer, here’s a bonus:

Are you talking to the real engine or a polished version?

There’s a reality shock when you move from interacting with a language model through its conversational interface to integrating it via code. The interface you use daily hides a massive system prompt that shapes everything.

That artificial politeness and tendency toward long explanations come from a layer designed for end users. When you connect directly to the API, you face a raw environment that assumes nothing for you.

Proactive assistants disappear, and you encounter vague systems. Operating at this level forces you to build your own guardrails. Every detail matters.

If you still think this role isn’t necessary in an AI team and want to give it a try—good luck 🍀. I’ll read you in the comments 👇.

References and links

• Langfuse integration documentation
• Prompt management and two-level caching guide
• Quality and fidelity evaluation systems in LLMs
• Agent orchestration architecture with LangGraph

However, for roles like Manager / Scrum Master / Flow Master who aim not only to organize work but to ensure technical excellence and team sustainability, overlooking XP is a strategic mistake. While other frameworks focus on management flow, XP focuses on the trenches—on how the product is built to be robust, flexible, and sustainable.

What is XP?

If you’ve never gone deep into XP, think of it not as a radical invention, but as a collection of what actually works. Just as J.R.R. Tolkien didn’t invent myths about elves and dwarves, but instead compiled and systematized centuries of European folklore into a coherent and functional mythology, Kent Beck did something similar with software engineering in the late ’90s.

Beck didn’t invent testing, code review, or customer collaboration. What XP did was gather these isolated “best practices”, already known to improve quality, and push them to the extreme of their effectiveness, organizing them under a unified philosophy.

Beyond technical excellence, XP also emphasized the importance of having what we now call a Product Owner physically present with the team (on-site customer) to improve the conversation between business and development. Additionally, one of XP’s most remembered contributions to Agile is User Stories as we know them today (with the 3 C’s), replacing heavy and hard-to-understand requirement documents.

In short, XP is a framework designed to reduce risk in projects with vague or changing requirements, applying strong technical practices, fostering communication, and discarding what is not needed at the moment. In summary: prioritizing customer satisfaction and software quality.

That’s the quick overview for those who missed that class.

But be careful: thinking XP is just this (a set of programming practices) is like reading the synopsis “a dysfunctional family in space” and assuming you understand the entire Star Wars saga.

What that summary misses is the real value for leadership. XP is a system for risk management and psychological safety.
XP assumes that agility without technical excellence becomes a factory of technical debt. That’s why it builds an unbreakable safety net (through automated testing, continuous integration, and simple design) that allows teams to move fast, adapt constantly, and avoid burnout. It ensures that speed doesn’t destroy quality.

And it is precisely this tension between speed and safety that hits us today.

We now have in our hands the greatest productivity accelerator in history: Generative AI. But generating code at high speed is not the same as generating maintainable or correct code. How do we govern this new hyper-speed without burning out teams or breaking products? The answer has existed for nearly 30 years.

A new hope: evolving XP with Artificial Intelligence

How does this ’90s framework fit into the era of Generative AI? The reality is that AI doesn’t make XP obsolete—on the contrary, it turns it into the necessary safety structure for this new speed. We are witnessing the birth of AI-XP (term used by Justin Beall).

Integrating AI into XP is not just about using autocomplete tools—it’s a systemic evolution that enhances the framework’s original principles through three modern feedback loops:

1. VISION (Planning). Where we once relied only on human intuition to define long-term goals, AI can now analyze market data to align XP’s “Planning Game” with real needs and trend predictions.
2. ADAPT (Agile iterations). AI acts as a facilitator that improves responsiveness. It can help break down complex user stories and ensure the team understands acceptance criteria, reducing ambiguity.
3. LEAP (Daily execution). This is where classic Pair Programming evolves into “AI Pairing.” AI handles routine and boilerplate code, allowing developers (the “navigator”) to focus on strategy, security, and design.

The new paradoxes of AI-XP

Before celebrating and assuming AI plus ’90s practices will solve everything, as technical and delivery leaders we must reflect. This new model introduces paradoxes and uncertainties that will reshape the rules:

• The user story paradox

Originally, XP freed us from heavy requirement documents with lightweight user stories (promises of conversation). Today, to prevent AI from hallucinating, we need extremely rich context (detailed specs, exhaustive prompts, explicit business rules).
Are we returning to hyper-documentation just so machines understand us? The challenge is ensuring AI requirements don’t kill human conversation.

• Redefining the “hybrid team”

Not long ago, hybrid meant remote vs. in-office. Today, a modern hybrid team is composed of human minds and AI agents. Managing trust, expectations, and collaboration in this new setup is the real challenge for Agile Coaches.

• AI as the new “knowledge silo”

XP promoted Collective Code Ownership to avoid knowledge concentration. But what happens if AI writes most of the code and developers only review it? We risk turning AI into a black box, losing deep understanding and control of our product.

Back to humanity

In conclusion, AI has the potential to accelerate software delivery—but also to accelerate chaos without proper governance, and XP provides that governance.

By automating technical complexity and routine code generation, AI enables XP to fulfill its most ambitious promise: humanity and respect.

Freed from repetitive coding tasks, teams can focus on what XP has always valued most: creativity, complex problem-solving, and high-value human collaboration. XP is not dead—it has simply found, thirty years later, the perfect tool to reach its full potential.

In this post, I want to show you how I designed an NLP pipeline to tackle this problem. It’s not about “adding AI just for the sake of it,” but about creating a logical flow that classifies, extracts, and cleans the information for us. The best part is that, with a few tweaks, this approach works just as well for risk analysis as it does for classifying support tickets or legal contracts.

What we’re going to build does four key things:

• Prioritizes. Is this a fire or a routine alert?
• Labels. Is it fraud, a technical failure, or a legal issue?
• Detects data. Extracts IPs, accounts, emails... the “hard” stuff.
• Understands context. Identifies which laws or companies are mentioned.

The flow architecture (Keep it simple)

There’s no need to overcomplicate things with huge models for everything. Here we combine business logic (rules) with statistical models.

The flow is:

Raw document → Urgency classifier → Risk labeling → Technical data extractor → NER (Entities) → Structured JSON.

A real case to test it

To avoid staying in theory, let’s use this incident alert (I made it up, but it’s very close to what you’d find in a real system):

OPERATIONAL RISK ALERT - ID-2026-00142 A critical failure has been detected in the transaction processing system... it affects credit cards. It started at 14:23 UTC and impacts around 15,000 customers. Data: IP 192.168.1.50 | Error: ERR-DB-TIMEOUT | TXNs: TXN-A7B3C9D2, TXN-F4E8A1B6. Warning: It exceeds the 0.5% MiFID II threshold. CNMV must be notified.

Classifying the fire: criticality

The first step is to know whether we need to escalate immediately or if it can wait until tomorrow. For this, we use a weight-based system. If words like “penalty” or “fraud” appear, the score skyrockets.

class CriticalityClassifier:
    def __init__(self):
        # Define what keeps us up at night
        self.keywords_critico = {'fraud': 10, 'loss': 10, 'non-compliance': 10, 'fine': 10}
        self.keywords_alto = {'risk': 7, 'alert': 6, 'failure': 5}
        # ... (other levels)

    def _calculate_scores(self, text: str):
        text_lower = text.lower()
        # Add points based on matches
        return {
            'critical': sum(w for k, w in self.keywords_critico.items() if k in text_lower),
            'high': sum(w for k, w in self.keywords_alto.items() if k in text_lower),
            # ...
        }

Result: in our example, it would yield a HIGH level with 57% confidence. Enough to trigger an automatic alert.

What are we dealing with? (Categories)

A document can belong to multiple categories at the same time. For example: technical (server outage) and compliance (regulatory breach). I used precompiled Regex patterns because, honestly, for specific keywords they are much faster and cheaper than a neural network.

# A small map of what to look for in each risk
self.category_keywords = {
    'operational': ['failure', 'error', 'outage', 'technical incident'],
    'compliance': ['regulation', 'penalty', 'cnmv', 'mifid'],
    'cybersecurity': ['attack', 'malware', 'hack', 'breach']
}

Extraction of technical "threads"

This is where NLP shines by saving time. Instead of having an analyst copy and paste IPs or error codes, we let regular expressions do the dirty work.

We extract simultaneously:

• IPs: 192.168.1.50
• Transaction IDs: TXN-A7B3C9D2
• Emails: incidents@sample-bank.com

NER. Who’s who?

To extract entities (organizations, laws, products), I use spaCy. It’s the Swiss Army knife for this. We add a custom dictionary because spaCy knows what a “person” is, but sometimes struggles to understand what “MiFID II” or “CNMV” are unless we explicitly tell it.

# We combine spaCy with our own domain-specific rules
self.custom_entities = {
    'regulations': ['mifid ii', 'gdpr', 'pci dss'],
    'organizations': ['cnmv', 'ecb', 'bank of spain']
}

The final result: JSON

In the end, the pipeline outputs something as clean as this:

{
  "criticality": "high",
  "categories": ["operational", "compliance", "technical"],
  "indicators": {
    "ipv4": ["192.168.1.50"],
    "error_code": ["ERR-DB-TIMEOUT"]
  },
  "entities": {
    "regulations": ["MiFID II"],
    "organizations": ["CNMV"]
  }
}

Does this scale?

If you run it sequentially, it might put you to sleep. But using ThreadPoolExecutor in Python, I’ve managed to process around 1,500 documents per minute. For most companies, that’s more than enough to handle the entire incoming flow in real time.

• Real metrics:
• Latency: 38ms (blazing fast).
• Accuracy: ~95% (the remaining 5% is usually very ambiguous language that requires human judgment).

Conclusion

Automating this is not just about cost savings—it’s about reaction time. If a system detects a regulatory breach in 40 milliseconds, you can mitigate the risk before it turns into a million-dollar fine.

What do you think? Would you introduce heavier models like Transformers (BERT/LLMs), or do you believe this hybrid approach is more stable for risk classification? I’ll read you in the comments.

One of Sociology’s core pursuits is precisely this: getting closer to an accurate representation of reality, and therefore of complexity (because reality is always complex).

This is where warm data comes into play: relational and transcontextual information that allows us to understand how a system is sustained (or blocked) beyond KPIs.

Cold data vs. warm data (a useful distinction)

• Cold data (Hard, Cold Data): what is measurable and comparable. Time, costs, throughput, errors, queues, deviations.
• Warm data: what connects and gives meaning to the above. Trust, implicit norms, tensions, commitments, “what is left unsaid,” fears, shared stories, social and cultural context—what Sociology refers to as “interactions.”

Both are necessary. The problem begins when we try to optimize only what can be “easily” measured.

Three theses for viewing organizations as living systems

This topic was a fundamental part of the work of Gregory Bateson, philosopher, sociologist, and cyberneticist, and later of his daughters Cathy and Nora Bateson. The Bateson family’s theses on what to consider when analyzing ecosystems such as organizations are as follows:

1 The transcontextuality thesis

“No process exists in a single context.”

In traditional process design (Business Process Model and Notation - BPMN), we tend to isolate processes (e.g., “credit approval”). For the Batesons, this is a functional simplification error. Warm data provides that transcontextual information: the approval process is “marinated” in economic context, workplace climate, the employee’s personal life, and the company’s technological culture.

Application in processes

Process Mining may detect technical inefficiencies such as delays (cold data). Warm data may explain that the delay occurs because the employee prioritizes the client relationship over system metrics to avoid cultural conflict.

2 The relationality thesis

“Intelligence is not in the parts, but in the relationships between them.”

Gregory Bateson argued that to understand a system, we must look not at the subjects but at the messages they exchange. Nora extends this idea, stating that warm data describes the interdependencies that keep the system alive.

Cold data measures silo performance; warm data measures the health of the connections between silos.

Application in processes

In a DTO (Digital Twin of the Organization), it is not enough to model tasks. You must also model “adhesion” and trust in the process. A process may be technically optimal but relationally toxic, ensuring long-term failure.

3 The coalescence thesis

“Real changes in complex systems are invisible processes of coalescence.”

This thesis states that before a change becomes visible in a KPI (cold data), an “Aphanipoiesis” occurs: an accumulation of small variations in relationships and perceptions (warm data), subtle but system-shaping. They “coalesce” (like raindrops merging into a larger drop). If we only manage what is measured (cold data) and ignore this coalescence, we will react too late to crises or opportunities.

Application in processes

For example, in their work, an Agile Coach does not only look for “burn rate velocity,” but for changes in team communication that precede efficiency gains. Before a team becomes formally “agile” (events, artifacts… cold data), there is a “coalescence of trust, shared language, and tacit rule understanding.” Without seeing this, a consultant risks deploying processes on unstable ground.

Warm data enables proactive orchestration, detecting system fatigue before logs reflect performance drops.

Warm data in a process: a practical example enriching VSM

Imagine you map a process using a Value Stream Map: you extract a SIPOC matrix, measure activity times, classify inefficiencies, and validate hypotheses. You detect that an administrative process has 30% waste in waiting time. Cold data may suggest automation, but warm data may reveal that delays stem from lack of trust between teams, fear of mistakes, underused tools, or implicit norms slowing agility.

Without relational data, any optimization is superficial—and often counterproductive.

For an optimization expert, ignoring warm data is like trying to understand a forest by analyzing only the wood (cold data), without considering root symbiosis and climate (warm data).

A comprehensive orchestration in 2026 requires both. This approach can mean the difference between a solution that works on paper and a real, sustainable transformation.

Warm data has traditionally been dismissed as “soft,” subjective, or unscientific. Relational sociology proves otherwise. It captures relationships, not isolated variables. Combined with cold data (costs, time, performance), it helps explain how human and cultural dynamics shape those numbers, including interactions with processes and machines—as anticipated by Lean TPS autonomation (Jidoka).

How do we integrate warm data into process analysis?

Detecting and measuring warm data is challenging, which is why it is often ignored. As a starting point:

• Observe interactions, not just outcomes. How are decisions made? What conversations never happen? Why are certain tools chosen? How do teams relate? Are there implicit rules?
• Analyze behavioral patterns, not just outputs. Why do inefficiencies persist despite good solutions? Are we automating hidden inefficiencies?
• Include multiple perspectives. Operational data is not enough; we must understand lived experiences, emotions, and leadership dynamics. #diversitymatters
• Finally, challenge your own optimization efforts. Does optimization reduce cognitive load or just redistribute it? Is change adopted or merely tolerated?

Warm data and agility: a natural connection

Agile and Lean frameworks emphasize adaptation and iterative improvement. Defining a framework is defining a way of working together, and agility has invested heavily in this. However, without understanding invisible relationships and contexts, improvement remains superficial.

Warm data reveals resistance to change, cultural values, and systemic impacts of interventions.

At Paradigma Lean Papers, we have discussed the importance of BA (context) to understand systems, daily team life, and the observation of Gen-ba as a living ecosystem.

Conclusion

In a world obsessed with numerical precision, we must remember that organizations and their processes are living systems.

If you work in optimization, remember: complexity is an experience. If your models do not explain the reality teams live, you are not optimizing—you are dangerously simplifying.

How do you integrate relational data into your agile projects? I’ll read you in the comments 👇

References

• Nora Bateson, Neurocognitive Academy
• Bateson Institute
• Warm Data Labs, Bateson Institute
• “Aphanipoiesis”, Nora Bateson

Today, we complete our map of 8 key technology decisions by analyzing the final four pillars that ensure the integrity, security, and long-term impact of our digital ecosystem.

5 Data governance and traceability

This is the engine that ensures data remains a trustworthy asset, directly impacting the company’s Governance (G). Reliable data doesn’t just ensure compliance—it accelerates decision-making and builds market trust.

Key selection factors

Data must have a clear identity and ownership. It is essential to choose technologies that guarantee end-to-end traceability for critical data and provide governance capabilities that ensure quality and integrity.

• Key usage factors

Transparency is non-negotiable. It requires clearly defined access and retention policies, along with continuous security monitoring and audit processes for responsible usage.

• Organizational impact

Faster decisions driven by trusted data. The result is strong regulatory compliance and support for ESG transparency through verifiable and auditable reporting.

“Trusted data doesn’t just ensure compliance: it accelerates decisions, builds market confidence, and opens the door to new opportunities.”

6 Cybersecurity and resilience

Security is not a cost; it is the insurance policy that protects business continuity and value, making it a critical pillar of Governance (G) and Social Responsibility (S).

• Key selection factors

Prepare for “when,” not “if.” We must evaluate incident response and recovery capabilities, ensuring compliance with standards such as ISO 27001, NIS2, or DORA.

• Key usage factors

No one enters without permission. Implement Zero Trust-based access management and foster a security culture through continuous training and strict protocols.

• Organizational impact

Peace of mind knowing your business is resilient. It minimizes financial risks from cyberattacks, ensures operational continuity, and strengthens trust among customers and investors.

“Security is no longer a cost: it is the insurance policy that protects continuity, reputation, and business value.”

7 ESG integration in the supply chain

Our technological responsibility extends to every partner; a supply chain aligned with Environmental (E), Social (S), and Governance (G) criteria is more competitive and reliable.

• Key selection factors

Tell me who you work with, and I’ll tell you who you are. It is essential to adopt platforms that enable supplier traceability and integrate with ESG risk management systems.

• Key usage factors

Your suppliers’ commitment is your own commitment. It requires continuous monitoring of their ESG performance and clear criteria for selection and retention.

• Organizational impact

A “clean” platform end to end. It reduces reputational risks across the value chain and ensures compliance with governance best practices.

“An ESG-aligned supply chain is more competitive, more reliable, and more attractive to customers and investors.”

8 Software lifecycle optimization

Efficient code means lower costs and faster delivery; it contributes positively to the Environmental (E) pillar by optimizing resource consumption.

• Key selection factors

Build today with tomorrow in mind. Choose frameworks that facilitate maintainability and scalability, while supporting energy efficiency metrics.

• Key usage factors

Deploy fast, but thoughtfully. Implement CI/CD processes for agile delivery and apply refactoring strategies to eliminate obsolete code that consumes unnecessary resources.

• Organizational impact

Sustainability translated into profitability. It reduces operational costs, improves delivery quality, and extends the lifespan of technological assets.

“Efficient code means lower costs, faster delivery, and development that leaves a… positive footprint.”

Conclusion: choosing technology is choosing the future

As I shared at the Smart Energy Congress 2025, choosing technology is choosing the future. By integrating these 8 decision points into our strategy, we transform technology from a support function into a driver that aligns business with social, environmental, and governance challenges.

• Enabler of real impact: technology drives everything from energy efficiency to digital inclusion.
• Competitive advantage: conscious decisions in architecture, data, security, AI, and accessibility enable new business models.
• Investment in resilience: purpose-driven design is not a cost, but an investment that fosters innovation and trust.
• Engine of transformation: platforms don’t just support the business—they connect it to a positive global impact.

"True technological disruption lies not in what machines can do, but in the purpose we choose when designing them."

After everything shared in this series of three posts on technology platforms, what will you do from today onwards? I’ll read you in the comments.

Being one of the latest to arrive does not mean it should be overlooked. Given its track record as a true game-changer—especially when it comes to transparent application execution—Docker has completely revolutionized the development world.

Model Runner is the new tool that Docker has released for running AI models locally, and in this article we will explore its main features.

As a quick reminder, in case you missed any of the previous articles, you can check out the rest of the local LLM execution series here:

• Running LLMs locally: getting started with Ollama
• Running LLMs locally: advanced Ollama
• Running LLMs locally: LM Studio
• Running LLMs locally with Llamafile

How it works and key features

Docker Model Runner enables AI model execution by embedding an inference engine (built on top of the llama.cpp library) as part of the Docker runtime environment. At a high level, the architecture is composed of three main components:

• Model distribution (model storage and client): the model store is the core component of the architecture, where tensor files are stored. The client performs operations (such as downloading) against OCI registries.
• Model Runner: maps API requests to processes that run inference engines (/engines) and models (/models). It includes components such as the scheduler, loader, and runner, which coordinate loading and unloading models from memory (both inference engines and models operate as ephemeral processes). For each combination of inference engine (e.g., llama.cpp) and model (e.g., ai/llama3.2:3B-Q4_0), a separate process is executed depending on incoming API requests.
• Model CLI: the main user interaction component. This is a Docker CLI plugin that provides an interface similar to running Docker images. Under the hood, the CLI communicates with the Model Runner API to execute most operations.

An important note is that, although the overall architecture remains the same, depending on the platform where it is deployed, these three components are packaged, stored, and executed differently (sometimes on the host, sometimes in a virtual machine, and sometimes inside a container).

Some of the main features of Docker Model Runner include:

• Ability to download and upload models to/from Docker Hub.
• Model execution via endpoints compatible with the OpenAI API.
• Packaging GGUF files as OCI artifacts to publish them in any container registry.
• Running and interacting with models directly from the command line.
• Managing local models.
• Defining input prompt details as well as model responses.
• Support for multi-turn interactions (chat).

Installation

Model Runner is available for major operating systems (Windows, macOS, and Linux), either through Docker Desktop or Docker Engine. In this article, we will run Docker Model Runner on Ubuntu using Docker Engine.

After installing Docker Engine if necessary, you can proceed to install Model Runner by executing the following command:

sudo apt-get install docker-model-plugin

Verifying the installation using the command:

docker model version

CLI Commands

Once Docker Model Runner is installed, you can interact with models using the following commands:

1 INSPECT

This command displays detailed information about a model.

docker model inspect ai/llama3.2:3B-Q4_0

docker model inspect ai/llama3.2:3B-Q4_0 --openai #Presentar la información en formato OpenAI

2 LIST

Command to list the models downloaded to the local environment.

docker model list

docker model list --json #List the models in JSON format

docker model list --openai #List the models in OpenAI format

docker model list --quiet #Show only the model IDs

3 LOGS

Command to display logs.

docker model logs

docker model logs --follow#View logs in real time

4 PACKAGE

Command to package a file in GGUF format into a Docker Model OCI artifact.

docker model package --gguf <path> [--license <path>...] [--context-size <tokens>] [--push] MODEL

docker model package --gguf /home/simonrodriguez/dockerModelRunner/model.gguf my_new_llama_model

The available options for this command are:

• --chat-template: absolute path to the chat template file (the template must be in Jinja format).
• --context-size: size of the context window.
• --gguf (required): absolute path to the file in GGUF format.
• --license: absolute path to the license file.
• --push: upload to the registry.

5 PULL

Command to download a model from Docker Hub or Hugging Face.

When downloading from Hugging Face, if no tag is specified, it will attempt to download the Q4_K_M version of the model. If this version does not exist, it will download the first GGUF file found in the model’s Files section on Hugging Face. To specify the model quantization, you simply need to add the corresponding tag.

6 PUSH

Command to upload a model to Docker Hub.

docker model push ai/llama3.3

7 RM

Command to delete local models.

docker model rm ai/llama3.2:3B-Q4_0

docker model rm ai/llama3.2:3B-Q4_0 --force #Force model deletion

8 RUN

Command to run a model and interact with it by sending a prompt or via chat mode.

docker model run ai/llama3.2:3B-Q4_0 #A prompt opens for an interactive chat, which you can exit with the command /bye

docker model run ai/llama3.2:3B-Q4_0 “Hello, what can you tell me about Docker Model Runner?”

docker model run ai/llama3.2:3B-Q4_0 --debug #Enables debug mode

docker model run ai/llama3.2:3B-Q4_0 --ignore-runtime-memory-check #Option to prevent the download from being blocked if the model is estimated to exceed system memory

When a Docker model is executed, it calls the API endpoint of the inference server hosted by Model Runner. The model will remain in memory until another model is loaded or the inactivity timeout is reached.

9 PS

Command that displays the models currently running.

docker model ps

10 UNLOAD

Command to unload a running model.

docker model unload ai/llama3.2:3B-Q4_0

11 DF

Command that displays the disk space occupied by the models.

docker model df

12 STATUS

Command to check if Docker Model Runner is running.

docker model status

docker model status --json #Display the information in JSON format

13 TAG

Command to create a specific tag for a model.

docker model tag ai/llama3.2:3B-Q4_0 quantized-model

If the tag is not specified, the default value is latest.

14 VERSION

Command to check which version of Docker Model Runner is installed on the system.

docker model version

API

Once Model Runner is enabled, API endpoints are automatically exposed (both native Docker Model Runner endpoints and OpenAI-compatible endpoints), which can be used to interact with models programmatically.

When making requests to the exposed API, it is important to consider the origin of the request:

• From other containers: send requests to http://172.17.0.1:12434/. This interface may not always be available for calls from containers. If that is the case, you must include the extra_hosts instruction in the Docker Compose configuration file:

extra_hosts:
  - "model-runner.docker.internal:host-gateway"

With the previous instruction, the API can be accessed through the address http://model-runner.docker.internal:12434/

• From the host: send requests to http://localhost:12434/

Native endpoints

The available endpoints are:

• /models/create (POST): endpoint to download a model.

• /models (GET): endpoint to list existing models in the system along with their information.

• /models/{namespace}/{name} (GET): endpoint to display information about a model.

• /models/{namespace}/{name} (DELETE): endpoint to delete a local model.

OpenAI-compatible endpoints

The exposed endpoints are:

• /engines/llama.cpp/v1/models (GET): endpoint to list available models in the system.

• /engines/llama.cpp/v1/models/{namespace}/{name} (GET): endpoint to expose information about a model.

• /engines/llama.cpp/v1/chat/completions (POST): endpoint to send a chat interaction and receive the assistant’s response. Multiple parameters can be specified, such as temperature, stream, seed, etc.

• /engines/llama.cpp/v1/completions (POST): model response to user input. This endpoint is already deprecated by OpenAI.

• /engines/llama.cpp/v1/embeddings (POST): endpoint to retrieve embeddings from a text.

Since currently only one inference engine (llama.cpp) is supported, this part can be omitted from the URLs above (for example, /engines/llama.cpp/v1/models becomes /engines/v1/models).

Docker Compose

Docker Compose allows you to define models as core components of your application, so they can be declared alongside services, enabling the application to run on any platform compatible with the Compose specification. To run models in Docker Compose, you need at least version 2.38.0 of the tool, as well as a platform that supports models in Compose, such as Docker Model Runner.

For using models in Docker Compose, the models element has been introduced, which allows you to:

• Declare AI models required by the application.
• Specify configurations and requirements for each model.
• Make the application portable across different platforms.
• Allow the platform to manage the model lifecycle.

The configuration options for the models element are:

• model (required): the OCI artifact identifier for the model. This is what will be downloaded and executed by Model Runner.
• context_size: defines the maximum context window size for the model.
• runtime_flags: list of parameters passed to the inference engine when the model starts. For example, for llama.cpp, the parameters can be found here.
• x-*: extensible properties for platform-specific options.

A simple example of a models definition could be:

models:
  llm:
    model: ai/llama3.2:3B-Q4_0
    context_size: 4096
    runtime_flags:
      - "--temp"                # Temperature
      - "0.1"
      - "--top-p"               # Top-p sampling
      - "0.9"

Services can reference models in two ways:

• Short form: the simplest approach. With this method, the platform automatically generates environment variables based on the model name:
  • LLM_URL: URL to access the LLM model.
  • LLM_MODEL: identifier of the LLM model.
  • EMBEDDING_MODEL_URL: URL to access the embedding model.
  • EMBEDDING_MODEL_MODEL: identifier of the embedding model.

services:
  app:
    image: my-app
    models:
      - llm
      - embedding-model

models:
  llm:
    model: ai/llama3.2:3B-Q4_0
  embedding-model:
    model: ai/embeddinggemma

• Long form: with this configuration, the service is explicitly provided with:
  • AI_MODEL_URL and AI_MODEL_NAME for the LLM model.
  • EMBEDDING_URL and EMBEDDING_NAME for the embedding model.

services:
  app:
    image: my-app
    models:
      llm:
        endpoint_var: AI_MODEL_URL
        model_var: AI_MODEL_NAME
      embedding-model:
        endpoint_var: EMBEDDING_URL
        model_var: EMBEDDING_NAME

models:
  llm:
    model: ai/llama3.2:3B-Q4_0
  embedding-model:
    model: ai/embeddinggemma

Here you can find some configurations for specific use cases of the models element in Docker Compose.

Demo

To see this new models element in Docker Compose in action, we created a simple application to interact with an LLM. The application uses the following components:

• Java 21
• Spring Boot 3.4.4 (with built-in support for Buildpacks to create Docker images for applications)
• Spring AI
• Maven 3.8.5
• Docker version 28.4.0
• Docker Model Runner 0.1.40
• Docker Compose 2.39.4

The application simply exposes a /chat endpoint that receives user input and sends it to the corresponding LLM.

Here you can download the sample application code and the README file with the steps to run it.

Conclusions

In this final post of the series, we explored how to run LLMs with Docker and the ease it provides to integrate them into our applications thanks to Docker Compose integration.

Throughout this series focused on running LLMs locally, we have reviewed the most widely used tools and their particularities, all of which offer core functionalities such as commands and API endpoints to interact with models. Currently, Ollama arguably stands out among the rest in terms of available features and advanced model customization.

Based on what we have seen with Ollama and Docker, will we soon see custom AI models (containerized or not) running in the cloud alongside our microservices? Only time will tell.

References

• Docker Model Runner Documentation

In this second article of our Green Quality Assurance (GQA) series, we leave behind the “why” and move into the “how.” If in the first article we established that measuring quality in watts and CO2 is just as important as ensuring software works properly, now it is time to build the foundations that will support this new way of working. It is not just about reducing the energy consumption of our tests or running fewer test cases; it is about completely reimagining our approach to software quality.

The software industry must understand that technical excellence and environmental responsibility are not mutually exclusive goals. In fact, the most innovative organizations are discovering that sustainable QA practices often lead to more efficient processes, more productive teams, and, surprisingly, better final product quality.

But to achieve this balance, we need a robust framework that allows us to assess, implement, and continuously improve our practices.

The journey toward Green QA is evolutionary. We cannot expect an organization to go from zero to one hundred overnight. That is why, in the following sections, we explain a gradual approach that recognizes different maturity levels, provides concrete tools for each stage, and enables us to measure our progress.

Framework layers

Addressing cultural change in an organization regarding quality is usually an evolutionary process in which awareness plays a major role. The shift proposed by GQA (Green QA) introduces a new dimension to that awareness: the goal of doing things in the greenest way possible. But are we really aware of what must change to make this happen? Let’s explore it.

Governance

First of all, it is important to have governance that is appropriate for this context. This is the organization’s official “mandate” and the basis of the entire process. Without it, Green QA remains an isolated initiative. Governance addresses the following points:

• Sustainable quality policy

This is not just a document; it is about defining the “Green Acceptance Threshold.” It establishes the sustainability goals the company is pursuing, setting targets by resource type. Once these goals are defined, everything else is aimed at meeting them. For example: “No production deployment may increase the energy consumption of the microservice by more than 5%.”

• Responsibility matrix

This defines what each member of the organization involved in the delivery lifecycle is responsible for.

1. QA: designs efficiency test cases, defines baseline metrics, and is responsible for executing measurements in each cycle.
2. Architecture: validates that design decisions do not introduce structural energy debt before reaching the testing phase.
3. DevOps / Platform Engineering: ensures that the instrumentation needed to measure consumption is available in test environments. Without observability infrastructure, QA cannot measure.
4. Sustainability: provides energy-to-CO2 conversion factors and ensures data traceability into the ESG reporting system.
5. Compliance: verifies that data collection, processing, and reporting comply with current regulations, particularly the CSRD.
6. Product Owner: formally accepts that acceptance criteria include efficiency metrics, not only functionality and traditional performance.

• Alignment with ESG and corporate strategy. In the previous post, we discussed ESG extensively and its connection to Green QA, and it is something that must be considered within governance.

Processes

This layer establishes how Green QA is integrated into the project’s day-to-day work.

• Shift-Left Green: integrating environmental criteria during the Refinement phase. If a feature consumes too much unnecessary data, it is rejected before development begins.
• Green Gateways in the Pipeline: adding “quality gates” into CI/CD. If automated tests detect an unusual spike in CPU or RAM usage, the build fails. Environmental controls must be present in design, development, testing, and deployment.
• Suppliers: evaluating whether our service providers (Cloud, SaaS) operate using renewable energy.

It is important that governance also defines the consequences of non-compliance with the policy, whether by blocking a release, creating technical debt, or establishing the appropriate mechanisms to prevent bypassing the defined goals.

Data and metrics

This framework layer analyzes the quality of the data that will support decision-making.

• Data traceability: ensuring that ESG data has a clear lineage, from the sensor or server log to the annual report.
• QA Data Cleaning: a process for deleting test environments, temporary databases, and old execution logs that worsen storage conditions and consume unnecessary energy.
• Accuracy vs. estimation: defining which data is measured (real) and which is estimated (mathematical models), applying different QA approaches to each.
• Definition of environmental and ESG KPIs
• Data quality controls (accuracy, completeness, traceability)
• Audit and reporting

Technology

This is the layer of tools. Green QA needs technical eyes to “see” energy. Therefore, it is advisable to have tools to measure the impact of programming languages (for example, comparing Python vs. Rust consumption in critical processes), optimize test suites so they do not run 2,000 tests if only 2 lines of code changed (risk-based test selection), configure the framework so test environments “self-destruct” immediately after execution, and have measurement tools (energy, carbon, resources), green test automation, and infrastructure optimization (cloud, hardware).

Continuous improvement

Within the framework layers, it is advisable to invest in the cultural and improvement aspect so that the framework becomes circular rather than linear.

Elements such as “Retro-Green,” where each sprint retrospective can include a question like: “what process or code did we make more efficient this month?”, gamification through rankings of development/QA teams that have reduced their digital carbon footprint the most, and the updating of standards.

As ESG laws evolve, this layer changes and is typically reviewed quarterly. In this way, the framework continues to comply with new regulations and allows organizations to establish measurable reduction goals, whether quantitative or qualitative.

The path toward Zero-waste Testing

One of the points mentioned above is measurement. It is essential to understand at every moment where we stand relative to the objectives in order to take the necessary actions and decisions while working within the defined governance. If you are familiar with TMMi, it is a process that measures maturity levels in relation to testing within an organization.

In this regard, below is an analysis of existing levels in relation to GQA, so that we can understand where we are and what the goals should be to consolidate or advance through them. Each of these levels should be further developed to make evaluations more concrete.

Level 1: initial (we start walking)

At this level, the company is not aware of the environmental impact of its testing. If there is efficiency, it is for cost savings, not because of purpose. Compliance is reactive, without metrics.

At this early stage, all tests are always executed in environments where we have no visibility into their consumption and which generally remain on 24/7.

Level 2: basic (awareness has awakened)

Stakeholders understand what Green QA is, and the first manual efforts begin to document impact. Manual controls and basic reporting appear.

At this intermediate level, assets such as servers and tools are identified in order to request sustainability reports from providers, creating an inventory of digital assets. Testing begins to be handled more consistently with this policy, for example by deleting old test data.

At this stage, actions still depend on people rather than automated processes.

Level 3: defined (the green standard)

Sustainability is officially integrated into the quality manual. The first standardized processes and KPIs appear.

At this level, having a green production readiness checklist should be one of the goals. To support this, green KPIs are defined (for example, watts per test suite).

At the same time, this level seeks to ensure that the QA team has sufficient training in Green Coding and energy efficiency.

Level 4: managed (automated and measurable quality)

A set of metrics has been established, and continuous reporting automation through pipelines is in place.

Once certain aspects are consolidated, including cultural ones, the goal becomes the use of “real-time carbon dashboards” integrated into tools like Jira or Grafana, so teams can see their daily impact.

The challenge is integrating this data with the rest of the company (ESG). CI/CD pipelines include tools that automatically measure the CPU/RAM consumption of tests. If a test is inefficient, an alert is generated.

Level 5: optimized (Green QA as DNA)

GQA is no longer an “extra”; it is the only way of working. It is aligned with the company’s overall strategy.

Now the company uses AI to predict and minimize the energy consumption of tests. The carbon savings achieved by the QA team are reported directly in the company’s annual sustainability report (ESG). The challenge is maintaining innovation and leading standards in the industry.

Aspects such as the “circular economy of data,” where test data is intelligently reused to avoid generating new loading processes, begin to be taken seriously in order to consolidate green goals.

Strategy and methodology

The strategy is the decision-making framework in which the elements needed to address GQA in practice are defined, aligned with all the framework layers described above.

The methodology describes how we implement the strategy we have defined and is responsible for defining how to execute GQA.

In the context of GQA (or sustainability in the software lifecycle), these tools do not only measure emissions, but also integrate into the quality process to ensure that software is efficient and complies with environmental regulations (ESG).

Once a strategy aligned with objectives has been established, the tools and frameworks that will be used for its implementation are selected. Below are some examples.

Measuring software efficiency (Green Testing)

This is where QA has direct control. The energy consumption of a process or test suite is measured. These measurements are used to establish the baseline.

Before optimizing a single line of code, QA needs to know how many grams of CO2 the hardware running the application generates. Without that, we cannot measure improvement after an optimization.

Tool: Scaphandre (energy metrology)

An open-source power consumption metrics agent designed for Kubernetes and bare-metal servers.

• What it is used for

It measures exactly how many watts a specific process consumes (for example, your Selenium suite or a microservice under load).

• Setup and use

1. Installation: it is installed as a binary or Docker container on the server where tests run.
2. Usage: it exposes metrics in Prometheus format.
3. Green QA Step: configure a Grafana dashboard that crosses “CPU consumption” with “Watts consumption.” If, after a code optimization, the tests take the same time but consume fewer watts, Green QA has succeeded.

Tool: Eco-Code / SonarQube (Green Rules)

• What it is used for

Static code analysis focused on energy efficiency.

• Setup

1. Installation: add the "Green IT" or "Eco-Code" plugin to your SonarQube instance.
2. Usage: QA defines quality gateways. If the code contains patterns that wake up the CPU unnecessarily (inefficient loops, redundant API calls), the quality test fails.

Tool: SimaPro and GaBi

These are industrial standards that can be adapted to the QA ecosystem in the following way:

• What they mean for IT environments

They allow us to model the impact of our digital infrastructure (servers, test mobile devices, or networks). They do not only measure energy expenditure, but also the “carbon debt” of the hardware supporting our software.

• Their strategic use in Green QA

They are used to establish the baseline. Before optimizing a single line of code, QA needs to know how many grams of CO2 the hardware generates. Without this, we cannot measure improvement after optimization.

• Setup and data sources

To control the environmental footprint of our applications, Green QA maps:

• Hardware inventories: CPUs, RAM, and storage systems used in staging and production environments.
• Environmental databases: sources such as Ecoinvent are integrated to calculate the impact of the energy mix (it is not the same to run a test on a server in Norway powered by hydroelectric energy as in a coal-dependent region).
• Practical decision example

Thanks to these tools, the QA team can make comparisons based on real data:

Case study: is it more sustainable to run our regression suite on old on-premise servers or migrate testing to a cloud instance with Energy Star certification and auto-scaling? Green QA uses LCA to demonstrate that migration reduces carbon footprint by X%.

Measuring Cloud Carbon Footprint (CCF)

If you do not want to rely on native tools (which are sometimes opaque), Cloud Carbon Footprint is the open standard.

Tool: Cloud Carbon Footprint (CCF)

• What it is used for

To visualize emissions from AWS, Azure, and GCP in one place with a transparent calculation methodology.

• Setup

1. Connection: you need read permissions for billing files (CUR in AWS, Billing Export in GCP).
2. Usage: it allows the QA team to compare regions.
3. Technical decision: QA can demonstrate that moving the staging environment from a coal-based region (for example, Virginia, US-East-1) to one powered by cleaner energy (for example, Sweden or France) instantly reduces carbon footprint without changing a single line of code.

Tools: Watershed, Persefoni, Plan A

These are SaaS platforms for measuring corporate carbon footprint.

• What they are

They automate the calculation of Scope 1, 2, and 3 emissions.

• Usage in Green QA

Software falls under Scope 3 (indirect emissions). These tools collect data from your electricity bills and cloud providers.

• Setup

They connect via API to your inventory systems. The QA team reports the energy consumption of test server farms here so the company has real data on IT department impact.

Measuring sustainability in the Frontend

GQA also measures the impact on the end-user device.

Tool: GreenFrame.io or Lighthouse (Carbon Indicator)

• What it is used for

To measure the carbon footprint of a user session in the browser.

• Setup and use

1. CI/CD Integration: it integrates with GitHub Actions or Jenkins.
2. Usage: every time a visual regression test is launched, GreenFrame estimates the grams of CO2 produced by loading the page (data transfer + JS execution on the client).
3. QA Metric: “this new Home version weighs 2MB more and generates 0.5g of extra CO2 per visit.” This is reported as a Sustainability Bug.

QA and audit: green quality management

This is where you connect data with the testing process.

Jira and TestRail

• Usage in Green QA: they do not measure carbon by themselves, but they are configured to manage green requirements.
• Setup
  • Jira: create custom fields such as Estimated Carbon Cost in User Stories.
  • TestRail: create a “Green Test Cases” section where you validate that the app enters power-saving mode or does not make unnecessary API requests.

ESG data platforms (Environmental, Social, and Governance)

• What they are

Repositories where all evidence for legal audits is stored.

• Usage in Green QA

The result of your green tests is uploaded here as proof of regulatory compliance (for example, to comply with the CSRD directive in Europe).

• Pipeline configuration

For this to be true “Green QA,” the flow must be:

1. Define thresholds: in Jira, set an energy consumption limit per feature.
2. Measure: during execution (Cucumber/Playwright), monitor consumption with tools such as Scaphandre or Intel Power Gadget.
3. Visualize: cross that data with the Azure Emissions Dashboard.
4. Audit: export reports to Persefoni or Plan A for annual accounting.

Conclusions

The transition process within an organization to embrace GQA involves a series of unavoidable steps and an adaptation process at every level.

It requires involvement from both the business and technical sides, beginning with cultural change and continuing through methodological and strategic adaptation.

All these changes will help the company comply with the legal framework already mentioned in the previous post.

My experience

I have been managing projects for almost fifteen years — first under a waterfall methodology, and now I am an agilista (or at least I try), working with Scrum. When humanity took that great leap toward true value delivery, leaving behind endless Project Management Plan documents printed in A3, we also forgot to ensure, through a time-box, this space to understand the project, the client, and the team — to make initial contact, put faces to names, and start getting to know each other.

Defining the rules of the game, understanding needs, feeding the backlog, making initial estimates… all of this is just as important as delivering a Minimum Viable Product (MVP). In fact, it is essential for the MVP to meet the expectations of all stakeholders. Because sometimes — just sometimes — in that first contact, one side realizes the other cannot deliver what was expected, and we avoid discovering this when half the work is already done.

It is true that working in consulting is not the same as working for a final client. Consultants serve clients who have a product to sell, which somehow also becomes our product. But this service has an end date, so generally in consulting we tend to request these time-boxes to align expectations and ensure deliverables with greater reliability. On the client side, where information is more direct and immediate, there is often a tendency to think that these spaces — where the team reflects, plans, aligns, and gathers context — are unnecessary.

This initial phase of the project provides a series of advantages that allow us to start the first Sprint with a higher chance of success, compared to diving straight into it without fully understanding what we are facing:

1. You will get to know your client

And to do so, you will make time — even when there is none — for kickoff meetings where the team presents what has been understood from the agreed scope (the project charter) and the conclusions drawn from this initial phase, where sometimes people only understand what they want (or are able) to understand.

From these meetings, questions will arise that may (or may not) change the product scope and even increase its value — because, honestly, they had not even been considered before. And what better value delivery than adding value to your own product?

2. You will get to know the team and start building relationships

I’m not talking about having “a good team” in abstract terms, but about creating the feeling of moving as one, rowing in the same direction. In those early days, you begin to see — and be seen: strengths, habits, styles, and how each person reacts under pressure or uncertainty.

That knowledge is invaluable because it allows you to anticipate and manage risks and dependencies that are not visible at first: misunderstandings, misaligned expectations, misinterpreted silences, or decisions no one dares to make without a clear framework.

3. You will help the team and the client get to know each other

In those early meetings filled with questions and clarifications (business, technical, and “how do we actually do this?”), the real starting point is built. If mutual trust is established during this period, everything flows better afterward: when the team proposes something unexpected, the client will at least listen; and when business priorities change mid-way, the team will treat it as what it is — an adjustment, not an impossible drama.

4. Together, we establish the rules of the game

This already accounts for half the success of the deliverable: sprint duration, daily stand-up time, planning/review/retro agendas, estimation approach, and how we write user stories. We also set up the basics: repositories, access, tools (Jira or not?), and initial technical decisions to avoid improvisation. With all this, we outline a lightweight initial roadmap to understand where we are starting and what milestones lie ahead.

5. The Product Owner can leave this phase with an initial Product Backlog

A first version — but enough to build an MVP that becomes the foundation for everything else. As Scrum dictates, the backlog will evolve throughout the product lifecycle, but defining initial epics, stories, and tasks gives us a solid starting point to begin building (and learning) from Sprint 1.

6. From all meetings, impressions, ideas, and decisions, an initial risk management can be established

This allows us to create an initial picture of potential scenarios the team may face and try to eliminate or mitigate them before they become real problems.

All of this lays the foundation of the project, from which the path begins — not only toward successful deliverables but toward doing things properly, always, always through alignment.

In real life…

Let me share a real case that reinforced all of this for me. I was assigned to a project with a client we had worked with before — in theory, nothing should have surprised us. A short, urgent project: the client wanted a deliverable by early year, and we received it in mid-November. December in between, with holidays already scheduled… so the margin was tight.

Looking ahead, we realized it was necessary to discover each other to strengthen the product and build as much as possible at the highest possible speed, delivering a quality MVP that could grow incrementally.

We spent two weeks getting to know each other: 10 working days where, based on the project initiation document, we worked closely with the client to resolve requirement doubts, extract all necessary User Stories, estimate them, and therefore estimate the entire project.

Given the impossibility of delivering everything desired by the client’s deadline, the idea was to propose an MVP that would evolve through value deliveries every two weeks, with new features and deployment milestones until completing everything defined in the requirements document.

We started with enthusiasm, determined to do it right. We explained that sprints would be 2-week time-boxes, used every available moment to gather more information, clarify doubts, define how features could be more effective, and build a roadmap with milestones and value deliveries.

The first week went smoothly: committed client, motivated team… what could go wrong? By the second week, the client stopped attending meetings, became vague in responses, and stopped replying. Before we could finalize the roadmap and delivery plan, they canceled the project.

A failure? For me, quite the opposite: it was an early signal that saved us weeks of pressure and wasted effort. Without that initial phase, we would have discovered it much later — with work already done, an exhausted team, and a frustrated client.

What conclusion do we draw?

So, was Scrum wrong for not “inventing” a Sprint Zero? From a strict Scrum perspective, it may not make sense: a Sprint is a Sprint. But real life — especially in consulting — rarely starts under ideal conditions, and that’s where this discovery time-box becomes an ally.

In today’s context, with the growing need for adaptability, it makes sense to go through this discovery phase with the client — something that has existed since the origins of project management.

What would have happened in that project where the client withdrew in week two? Would we have realized so quickly that we were not aligned? Probably not. We would have gone through six weeks of intense pressure, trying to deliver something unachievable, with a stressed team, a frustrated client, and quality and methodology both questioned.

Traditional project management already accounted for something similar: before execution, you needed to initiate and plan — understand the context, align expectations, and define a roadmap.

Call it what you want, but the need to understand the client, the problem, and the project conditions is not new — what has changed is how we do it. Today, we don’t aim for exhaustive waterfall-style planning, but for a lightweight and adaptive start: empathizing with goals, clarifying needs, making assumptions visible, identifying risks, and leaving with a first working vision.

In short: think just enough at the beginning so you don’t pay later for not thinking at all.

At Paradigma, we apply this mindset through Polaris, our framework, where we maintain Agile principles while adapting to each client’s lifecycle:

• We keep the Agile essence, applying the 80/20 rule: 80% is team attitude, 20% is practices, tools, and experience.
• The Scrum Master evolves into an Agile Delivery Leader, ensuring coordination, value focus, and clarity.
• We follow a shared True North, guiding decisions and maintaining direction.
• We work in a 100% adaptive framework with clear phases: pre-project, kickoff (Sprint Zero), iterations, and closure.
• We proactively manage risks from day one.
• We aim for productivity, doing what is necessary first, then what is possible, and eventually what seemed impossible.
• We rely on metrics to make decisions, adapting them to each context.
• Quality is non-negotiable, ensuring superior products.
• We understand that software is about solving business problems, so our approach is always aligned with the client.
• Team experience matters, and relationships with clients are key to success.

And I’ll close with something simple: life gives us the ability to choose — also when managing projects and trusting others with our products. Nothing guarantees 100% success, but if we can choose, I’m clear: better to get to know each other before jumping to conclusions, better to empathize before blaming.

Better to discover things early than end up with a list of “I told you so” that leads nowhere… and certainly not to product success.

The good news is that the industry has already found the solution, and it’s not something invented overnight. The answer, as we have been advocating, lies in applying the most rigorous discipline we have: Platform Engineering. The days of “testing with soda” (the AI preparation phase) are over — now it’s time for the application of AI in production, at scale, with responsibility and speed.

The need for an AI platform is not just a trend — it is the AI-native infrastructure that leading companies, including some of our clients, are already building in the market today.

The industry is already there, and there are reference solutions

The truth is, we don’t need to be guinea pigs. The heavyweights are already clearly stating what we are seeing: AI needs Platform Engineering.

Google and Thoughtworks are just two examples of how the industry’s vision is converging. The message is clear: if you want to scale MLOps consistently, you need Golden Paths and the abstraction that only Platform Engineering can provide. It’s not just about having more GPUs — it’s about making those GPUs consumable without a 300-page manual.

What does this mean? It means that the goal is not just to support current models, but to create AI-native infrastructure. In other words, a platform designed from the ground up to orchestrate the complexity of AI agents, vector data, and the MLOps lifecycle. We are talking about a platform where automation and intelligence are built in.

If industry leaders have already validated this blueprint, the question is not if we should build it, but when we start.

An AI platform is rarely built from scratch using a single product. It is based on an intelligent orchestration of components that reduce friction and provide flexibility. For teams starting this journey, it is crucial to identify the stack that will serve as the foundation. An example of an industrialized Golden Path includes tools such as:

• Pipeline orchestration: Kubeflow or MLflow, to standardize workflows (training, packaging, and model deployment).
• Training data management (Feature Store): tools like Feast, ensuring data consistency between training (offline) and prediction (online).
• Model serving and MLOps core: using Kubernetes for deployment is just the beginning. Specialized solutions like KServe help manage scaling and model monitoring complexity.

The key is not adopting all these tools, but ensuring that the AI Platform abstracts them, so Data Scientists only interact with the simplified Golden Path we define.

Real use cases: tangible ROI

CxOs love the word ROI. How do we evangelize the value of this platform? Simple: with facts — showing where self-service and traceability generate revenue or mitigate risk.

Let’s ground this with three examples where the AI Platform provides the strongest foundation:

• Retail and personalization at scale

A platform that enables deploying a recommendation engine for each customer segment (or even each individual) in a matter of hours. The advantage: if Data Scientists can iterate on recommendations ten times faster thanks to an automated Golden Path, the company sells more. The business focus is on improving the algorithm’s Time-to-Market.

• Dynamic fraud detection

Risk analysis. Here, the AI platform not only deploys the detection model but also ensures auditability and real-time monitoring of model drift. If the model starts to fail, the platform detects it and automatically rolls it back, protecting the company from multimillion losses or regulatory failures.

• Internal IT and automation

We can use the AI platform to enable Data Scientists to build internal AI agents that automate support ticket management or optimize cloud resources. Moving from “we have an AI agent in testing” to “the agent resolves 20% of L1 incidents” is only possible with a platform that reliably manages its lifecycle and state.

There are countless use cases. As experts in your vertical and business domain, you will surely identify many more opportunities to capitalize on.

The CxO roadmap: beyond code and technology

This is where the CxO shifts into strategic consultant mode. Technology is the how, but strategy and people are the what. We cannot talk about an AI Platform without addressing change management.

Strategic alignment: connecting DORA to the balance sheet

We need to translate Feature Store jargon into business language — the language of those who unlock investment.

Using principles from our Platform Engineering series:

• Business KPIs and MLOps metrics: demonstrating that reducing Lead Time for Changes (a DORA metric we should use to measure the platform) directly translates into faster product launches and reduced risk. This is the only way to justify the investment with evidence.

Additionally, for AI and models, we can introduce specific metrics:

• PoC-to-Prod Ratio: the percentage of Proofs of Concept that reach production within 90 days. The platform should increase this ratio from the current 10–20% to over 70%.
• Model Lift: measuring the incremental improvement in business metrics (e.g., conversion increase, fraud reduction) before and after deploying the model through the platform.
• MLOps TCO Reduction: quantifying operational cost savings achieved through self-service and automation, eliminating dependency on TicketOps and manual infrastructure configuration.

Change management: bridging Data Science and engineering

This is probably the hardest part. We need to reconcile and empower both worlds:

• Data Scientists are not DevOps — and they shouldn’t be. That’s why the platform is essential as a bridge. We must establish an internal product culture: the platform team provides services and capabilities, and the Data Science team is the customer.
• Training and new roles: invest in developing Machine Learning Engineers, the glue between Data Scientists and Platform Engineers.

The first step is technological abstraction and addressing real business needs

The industry is doing it. At Paradigma, we are already doing it. We see that the benefits are tangible, and above all, we see that the risk of falling behind is unacceptable. AI is the new competitive battlefield.

So, where do we start?

My recommendation for all C-level executives, decision-makers, and business unit leaders responsible for technology decisions is simple: start with the highest-friction components — those that consume the most effort without directly impacting the business.

Focus on what is most valuable to optimize and industrialize, and what accelerates the journey from idea to production.

• Do not try to build the entire IDP at once. That would be a mistake. Be pragmatic.
• Start with capabilities like a Feature Store to solve data quality issues, or a Model Registry to address traceability and governance of model usage within your organization.

These are just a couple of examples, but those familiar with the process and its pain points will be able to identify “small wins” that gradually build momentum and shape the AI Platform.

Any effort that reduces manual self-service and increases standardization is paving the way toward that inevitable AI Platform. The platform is not built in a day — it is a journey. The best way to evangelize and generate traction is to demonstrate value through small but solid Golden Paths.

I hope this series of posts has sparked your curiosity about why this topic is so important, provided strategic justification through real-world challenges, and most importantly, given you ideas on where to start building a practical roadmap that delivers value and helps lead the AI conversation in your organization.

If you’d like to revisit the previous two posts in the series, here they are:

• 2026 will be the year of AI platforms
• From PoC to production: many proofs of concept, but few in production

Testing everything at all times may not be the most optimal or the most ecological approach. Improving testing cycles and adapting both process quality and product quality to reduce emissions becomes a new challenge for teams.

In this series of three posts about Green Quality Assurance, we will explore this new perspective to understand what it consists of, which frameworks may be most suitable to achieve our goals, and how to establish KPIs and metrics within an organization or project to guide our practices toward greater efficiency and sustainability.

In this first part, we will focus on explaining what it means to be environmentally conscious in the QA world and how this need arises, driven by European regulations such as CSR (Corporate Sustainability Reporting Directive) and concepts like ESG (Environmental, Social, and Governance).

What is Green QA?

Imagine your quality process becoming an “athlete”: faster, stronger, and much more efficient. Green Quality Assurance (GQA) redefines QA, QC, and testing processes so that each one matters, reducing energy consumption and carbon footprint without losing the rigor required.

Integrating sustainability into the quality of the process (QA activities during software construction) and into the quality of the product (QC and testing, validating and verifying the built product) means ensuring that software is not only good in terms of quality, but also efficient in terms of energy consumption and sustainability, and aligned with ESG principles, which we will explore later.

Organizations that integrate social responsibility into their development lifecycle, while maintaining performance and controlling costs, present a competitive advantage to potential clients. This allows those clients to improve their sustainability metrics without sacrificing other objectives.

Aligned with the concept of GQA is GreenCode, which focuses on coding practices that seek energy efficiency through techniques such as lazy loading, microservices instead of monoliths, and lightweight code that extends the lifespan of the devices on which it runs, among other aspects.

Green IT goes hand in hand with the above concepts and serves as their foundation. It refers to the use of hardware with high energy efficiency certifications and the use of cloud infrastructure, since large providers such as Amazon and Google often rely partly on renewable energy sources like solar power to maintain their data centers.

Currently, from a legal perspective, there are regulations that require companies to present CSR reports (or Sustainability Reports). At the European level, this is known as the CARD directive, which in Spain has been mainly integrated through the Corporate Sustainability Reporting Law (LIES). It is important to remember that the CARD directive requires the use of ESRS standards (European Sustainability Reporting Standards). These standards require certain companies to break down their energy consumption and emissions depending on the size and type of company. As you can see, Green QA has legal coverage and, if its objectives are achieved, it helps companies comply with these requirements.

As an example of the use of these regulations and Green QA, a traditional CSR report might say: “we want to be green,” while a report under the CARD directive would require something like: “our Green QA suite reduced CPU consumption by 12%, saving X tons of CO₂ this year.”

ESG as DNA

Continuing with the concepts surrounding GQA, and since we will refer to it frequently, let’s briefly explain what ESG is.

ESG (Environmental, Social, and Governance) is the set of criteria that investors, governments, and customers use to measure whether a company is responsible in terms of environmental impact, social responsibility, and internal governance.

When we talk about Environmental, we refer to the environmental impact a company has on the planet. Green QA plays a significant role here, helping with aspects such as:

• Key topics: carbon footprint, energy efficiency, waste management, and climate change.
• In software: how much energy do your servers consume? Is your code optimized to avoid unnecessarily heating processors?

When we talk about Social, we refer to how the company manages its relationships with people and society.

• Key topics: diversity, human rights, workplace safety, and data protection.
• In software: this includes accessibility (ensuring that people with disabilities can use your application) and ethical data practices (user privacy).

Finally, when we talk about Governance, we refer to how the company is managed internally — the rules and transparency that guide its operations.

• Key topics: business ethics, executive compensation transparency, anti-corruption measures, and legal compliance.
• In software: quality audits, compliance with software regulations, and transparency in development processes.

Now that we understand ESG, we can see how the technical quality role can evolve — from guaranteeing the method and the product to also ensuring ESG compliance, thereby becoming a guardian of sustainability as well.

Understanding the major ESG pillars (environmental impact, social impact, and internal governance), GQA helps achieve objectives in the technological domain:

• 🍃 Environmental: optimizing automated test suites and improving cloud efficiency to directly reduce the software’s carbon footprint.
• 🤝 Social: promoting digital inclusion. Efficient code consumes fewer resources and performs better on older devices, helping combat planned obsolescence.
• ⚖️ Governance: generating technical metrics and transparent reports on energy consumption, facilitating compliance with green audits.

Organizations that align their quality lifecycle management processes with ESG goals without compromising speed, cost, or performance will gain a decisive advantage in a market increasingly saturated with high-performance CSR requirements.

Main objectives

The main objectives of this philosophy are resource optimization, operational efficiency, and profitability. Among the goals pursued are reducing environmental impact by lowering consumption, reducing waste and emissions, and optimizing the use of material and computational resources.

We know that every time a test suite runs (especially in the cloud or on large servers), electricity is consumed, which generates a carbon footprint. Reducing this impact through selective testing and efficient test code should be a key goal.

Another objective of Green QA is alignment with ESG, providing environmental metrics:

• Enabling auditable sustainability reports (test cycle consumption, etc.)
• Providing insights for sustainable data governance (reducing data duplication in TDM test environments), which lowers physical storage requirements in data centers.
• Providing audit trails proving that quality processes comply with the organization’s “Net Zero” policies.

Impact areas: where quality becomes green

To achieve Green QA objectives, we must intervene in key digital assets. It’s not only about verifying that software works — it’s about ensuring it is sustainable. To do so, we must act in the following areas:

Validation of digital products and processes

• Software lifecycle analysis (S-LCA): QA no longer only validates the “Go-Live”; it audits environmental impact from development and testing through deployment and eventual software decommissioning. Its role is to ensure that energy consumption calculations at each stage are accurate and realistic.
• Code sustainability verification: implementing protocols to measure the “energy density” of functions. QA performs efficiency tests to prevent bloatware and ensure the product does not force user hardware obsolescence.

Sustainability audits in infrastructure

• Cloud provider validation: QA verifies that the infrastructure hosting the software complies with renewable energy certifications (PUE – Power Usage Effectiveness). We don’t just test in the cloud — we audit that the cloud is green.
• Optimization of the digital supply chain: reviewing third-party libraries and dependencies. Green QA detects inefficient dependencies that consume resources in the background without delivering value.

Validation of eco-design in software

• Repairability and modularity criteria: validating that code is structured so it can be easily maintained and updated without refactoring the entire system, saving unnecessary computation cycles.
• Data transfer efficiency: specific tests to reduce the weight of API requests and data traffic, directly lowering electricity consumption in data centers and telecom networks.
• Carbon-aware load testing: measuring not only how many users the system supports but also how much CO₂ the server emits under that load.

Ensuring ESG data integrity

For a sustainability report to be valid, the data must be highly accurate. Green QA becomes the technical auditor ensuring the integrity of every metric, which requires proper training for this role to certify the provided information.

1. Validation of emissions KPIs

The QA profile must ensure that calculation algorithms and data sources reflect the real energy consumption of the digital ecosystem:

• Direct emissions: first level. Validation of data from proprietary infrastructure and on-premise servers.
• Purchased energy: second level. Verification of electricity consumption reports from contracted data centers and their energy mix (renewable vs. fossil).
• Value chain: third level. The biggest challenge. QA audits the efficiency of third-party APIs and the energy consumption generated by the software on end-user devices.

2. Accuracy and reliability of reports

Having data is not enough — it must be correct. Techniques are applied to prevent bias in sustainability reports:

• Stress testing of carbon footprint calculation models.
• Validation to ensure there are no duplicated emissions counted across departments.

3. Traceability and auditing (Data Lineage)

Implementation of traceability tests to ensure that every data point in the annual report can be traced back to its technical origin (server logs, CPU metrics, etc.). If an auditor asks where a number comes from, Green QA has the documented answer.

4. Consistency in ESG disclosure

Ensuring that the data published on the website, in the app, and in the legal CARD directive report are identical. Automated cross-validation processes should be implemented to avoid discrepancies that could result in legal penalties.

Application of standards and regulations

Several frameworks and standards support the implementation of these “green” processes. Here we briefly review them; in future articles we will explain how they can be applied strategically and methodologically:

• ISO frameworks (14001 and 50001): ensuring QA processes are documented to pass external environmental and energy management audits.
• CARD (Corporate Sustainability Reporting Directive): the new European regulation ensuring legal sustainability reporting requirements are technically fulfilled.
• EU Taxonomy: validating that company activities are correctly classified as “green” according to EU technical criteria.
• GHG Protocol (Greenhouse Gas Protocol): establishing the standard methodology for calculating carbon emissions derived from the software lifecycle. QA must validate energy consumption data collection in Scope 2 (server/cloud energy) and Scope 3 (third-party cloud services and end-user software usage), ensuring emission factors are accurate for carbon footprint reports.

Conclusion

We have seen how, within the world of software quality, there is an aspect that is rarely considered yet has a significant impact.

Applying GQA not only improves sustainability but also enhances efficiency, which ultimately reduces costs in both processes and product development.

All these processes are supported by a set of European regulations and their transposition into Spanish law, making them even more relevant since non-compliance can result in financial penalties for companies.

Ultimately, Green QA is about doing our part to improve life through quality practices.

All of this has worked relatively well. Beyond the constant change and evolution across the entire technological landscape related to AI, there are no major problems until the moment comes to make it production-ready.

The reality of AI in production

As we already mentioned in the first post of this three-part series, the AI Platform is no longer an option but a necessity. But why is this need so urgent? In my opinion, it’s because we are losing money, time, and opportunities every single day.

Most companies are trapped in a discouraging “Groundhog Day” loop: proofs of concept tend to succeed, but moving them into production is painful. The reality is that Data Scientists perform magic in their notebooks and the results are promising, but when trying to move those models into the real world, they hit a wall of bureaucracy, tickets, lack of standardized tools, missing automation, and security team bottlenecks.

It becomes a nightmare. And that nightmare translates into very concrete bottlenecks and problems that the AI Platform must eliminate.

Problem 1: self-service and the pain of TicketOps

Let’s put ourselves in the shoes of the AI team. They have just trained a model that could save millions, and all they need is surprisingly to deploy it.

What happens next? In 90% of cases, they need to contact an infrastructure team, open a ticket, wait three days to get a namespace assigned, request network permissions, and hope for access to a feature database. This is what we call "TicketOps", and it is a major problem for Time-to-Market.

⚠️ Important: this process is necessary. We should not underestimate the potential security or regulatory compliance issues that could arise.

However, the situation is becoming even worse. With the rise of LLMs, the problem has grown significantly. Deploying an LLM is very different from deploying a simple regression model. It may require GPUs, specialized storage, and APIs that manage the complexity of prompting and memory usage. Without a self-service tool that allows this to be deployed in minutes, it simply does not happen. The democratization of LLMs ends right there.

Previously, a Data Scientist could request a server and that solved everything. Today, it is necessary to deploy a microservice that consumes an LLM, uses a vector database for long-term memory, and also requires dedicated access to a GPU node in the cluster. If that process cannot be reduced to a single command in our IDP, we are creating a technical barrier for every new AI idea — directly impacting the business and, therefore, our customers.

Problem 2: compliance and regulatory requirements

When we talk about AI, the risk is enormous. A model that makes biased decisions or operates with outdated (or private) data can cost a fortune in fines or even destroy a company’s reputation.

Here, the problem is twofold:

1. Quality

The AI Platform must guarantee that training data is consistent. If we do not standardize how data is ingested and versioned, the production model will inevitably drift. It is Garbage In, Garbage Out taken to the extreme.

The consistency problem is caused by the absence of a Feature Store. Data Science teams often calculate the mean or standard deviation of a data column during training, but the code that calculates that feature in real-time in production is different.

A Feature Store, managed by the platform, guarantees that the code used to compute a feature is the same during training and serving (production). It is the only way to ensure mathematical consistency.

2. Security

Who has access to the model? How are changes in code and datasets tracked? Without traceability and security policies by design (integrated into the Golden Paths), auditing becomes impossible.

And honestly, the idea of a Data Science team manually configuring firewall rules gives me chills. It’s a disaster waiting to happen.

Problem 3: Time-to-Market (TTM) pressure

This is the point that matters most to the business. What is the value of having an innovative model if it takes six months to reach the customer? Competitors are not waiting, and Time-to-Market becomes the most critical business metric.

Today, platform teams face enormous pressure to operationalize AI (that is, to make it reliable and fast). They must move at the speed of innovation, not at the speed of infrastructure.

The solution — and this is where Platform Engineering starts to feel almost like science fiction, is moving from TicketOps to Intent-to-Infrastructure.

In other words, giving a Data Scientist the ability to tell the platform: "I want an environment to train a classification model with a specific dataset."

The platform automatically translates that intent into all the required infrastructure (Kubernetes, networking, secure storage) in a matter of minutes.

This removes the biggest bottleneck: friction and dependency between teams. It allows us to move from idea to production at the speed the business demands.

Conclusion

If we combine bureaucracy and rigid processes (often tied to ticket-based workflows), the importance of data quality, and relentless Time-to-Market pressure, we quickly understand that AI without a platform becomes an expensive and frustrating research project, not a competitive advantage.

AI platforms are the only tool that allows organizations to maintain control without sacrificing speed.

We have seen the real problems and bottlenecks that slow down the ability of AI to deliver value to businesses and customers. In the final post of this series, we will stop talking about pain and start focusing on solutions.

We will explore what the industry is doing, with concrete examples and use cases, and define the first steps of a practical roadmap so your team can start building that model factory today.

Before we begin…

Throughout this post we will use some concepts that are very common when talking about digital product development, but that’s okay if you’re not familiar with all of them. Here are a few to make sure we can provide as much value as possible:

Product vision: what we want to achieve with our product and how we see it in the future. It’s an inspiring statement that indicates where we want to go and where we want to be in the future.

Product strategy: the how we will achieve our vision. Strategy includes aspects such as differentiation from competitors, the type of users we are creating the product for, and the value proposition. Strategy aligns what we can do with what we should do.

Product backlog: a prioritized list of the features we need to develop to create solutions for our users’ problems and needs — in other words, the product.

What is a roadmap

A roadmap is the plan to follow in the development of your product in order to achieve the vision and meet the objectives.

Contrary to what some may think, a roadmap and a project plan are two different tools, although both are used in software product management and can complement each other.

While a project plan is very operational and reflects aspects such as scope, budget, dependencies, and tasks in great detail, a roadmap is much more strategic and focuses on how to achieve the product vision.

Here are some of the most significant characteristics of roadmaps:

• It is the plan to achieve the vision. It is not a list of tasks but an action plan that guides the path toward our vision.
• Flexible and adaptable tool. It is dynamic and evolves over time as we receive feedback from users, allowing us to adapt our strategy to achieve the vision.
• A communication tool. It helps align different stakeholders through transparency, ensuring that everyone shares a common vision.
• Connects business goals with the plan to achieve them. The initiatives included in the roadmap, individually or together, aim to achieve the objectives of the product and the company.

We can say that a roadmap is how we present our strategy to achieve our vision.

What a roadmap is NOT

Now that we’ve discussed what a roadmap is, let’s also clarify what it is not:

• It is not a list of tasks. Our roadmap will not include every task we need to develop, but rather a set of initiatives that will guide product or project development.
• It is not a timeline. Although a roadmap may include timeframes and dates, they are more flexible and can change if the strategy evolves based on feedback. A roadmap should always be agile, flexible, and adaptable.
• It is not an execution plan. It does not explain how to carry out each initiative; instead, it focuses on what needs to be achieved.

For example, an initiative in the roadmap could be improving the onboarding process. The tasks required to achieve it might include adding an interactive demo or integrating an assistant to guide users through the process. These tasks might have specific dates, but those would not appear directly in the roadmap.

Steps to create a roadmap

To start working on your roadmap, consider the following:

Product vision

The first thing you need to do is ensure that you clearly understand your product vision. If not, try asking yourself the following questions to help define it:

• Why does our product exist?
• What problems does it solve or what needs does it cover?
• Who will use it?
• What would have to happen for us to consider it a success?

For example, Slack’s vision is: Make work life simpler, more pleasant and more productive.

Here is a template to help you develop your product vision.

Themes

These are initiatives or specific projects that help achieve business goals. These themes will later be broken down into more specific tasks such as user stories.

Example: “Redesign the purchase funnel.”

Choosing the type of roadmap

There are several ways to design your roadmap, which will determine the next steps you need to follow. Here are two examples to help you get an idea — although many more exist.

Now–Next–Later roadmap

If we focus on the flexibility of roadmaps, we can talk about a well-known type: Now, Next, Later.

In this type of roadmap, no specific timeframes are defined. Instead, we focus on what we are currently working on (Now), what we will work on next (Next), and what we plan to do in the future (Later).

Here is a visual example of a Now–Next–Later roadmap 👇

As you can see, each theme is represented, and within each column (Now / Next / Later), projects are shown in the color corresponding to their initiative.

Additionally, below the roadmap we display the product vision, since it is essential to keep it in mind when building the roadmap.

Timeline-based roadmap

These roadmaps use a time scale or timeframe, which can vary depending on the needs of your product or project: 3 months (short term), 6 months (mid term), 12 months (long term), or even per sprint if you work with Scrum.

Our advice is not to plan your roadmap more than six months ahead, because the idea behind a roadmap is agility. You should be able to adapt it based on feedback and new needs that arise.

Here is a visual example of a timeline-based roadmap 👇

In this example, we see a roadmap with four different initiatives that will be developed during Q2. Each initiative or theme has a different color indicating which project or epic it belongs to.

Just like in the previous type of roadmap, the vision is included to ensure it is always considered during roadmap development.

In this case, the months are also included, helping provide transparency and alignment with stakeholders and the team.

Key elements

As you’ve seen, regardless of the type of roadmap that best fits your product or project, its core elements are the same:

• Time scale, whether a timeline or a Now–Next–Later format.
• Themes or initiatives at a high level.
• Projects or epics for each initiative.

And don’t forget to reflect your product vision!

Next steps

Although we haven’t mentioned it earlier in this post, there are other important aspects when creating a roadmap:

• Prioritization. We cannot do everything, and certainly not all at once. That’s why we must make decisions and prioritize initiatives. There are different techniques and frameworks that can help with this, as we explained in this post 👉 Unlocking the potential of prioritization: the most important frameworks.
• Communication. The main value of building a roadmap is that it acts as a tool for alignment and transparency. It helps everyone understand the focus and why certain decisions are made.
• Connection with the business. Every initiative must be linked to a business objective; otherwise, we risk investing time in developments that generate no real value. To achieve this connection, it’s important to stop thinking about outputs and start focusing on outcomes — generating real impact by solving specific problems and needs.

There is still much more to say about this last point, which we’ll cover in future posts 😉.

Conclusion

A roadmap is a tactical tool that aligns product vision with strategy.

Also keep in mind that no roadmap is better than another. You simply need to adapt it to the specific needs of each project and continue iterating until you find the roadmap that best fits your product.

A roadmap is a compass. Build yours!

Today we’ll go one step further: we’ll see how Angular Signals, the new reactivity API in Angular introduced experimentally in Angular 16, makes it possible to improve UI efficiency, update only what is necessary, and simplify state management in Angular components, optimizing the performance of your applications.

The problem with classic change detection in Angular

In the traditional approach:

• Each component has its own change detector.
• Angular traverses the component tree every time an asynchronous event occurs (click, timer, HTTP request).
• In applications with many components or large lists, this creates unnecessary change detection cycles, affecting performance.

For example, in the previous article we created a clock that updates every second and a table of users. The clock update triggered a full Angular change detection cycle, recalculating random values in each row, even though the data had not changed.

Angular Signals: how they improve reactivity

With Angular Signals:

• Each signal represents a reactive value.
• Angular updates only the bindings that depend on that signal.
• Derived values (computed) are recalculated automatically.
• There is no need for ChangeDetectionStrategy.OnPush or ChangeDetectorRef to optimize performance.

This makes Signals a key tool for improving performance in Angular, especially in large applications with lists and complex components.

Signals, effects, and derived values

To better understand it, let’s see how Signals work in Angular.

Create a signal

import { signal } from '@angular/core';

const counter = signal(0);

• A signal represents a reactive value.
• To read it, it is invoked as a function: counter().
• To write to it, .set() or .update() is used.

Effects (effect)

Effects are functions that run automatically when the signals they use change.

import { signal, effect } from '@angular/core';
const counter = signal(0);
effect(() => {
  console.log(`The counter value is ${counter()}`);
});
counter.set(1); // The effect runs and prints “The counter value is 1”

Computed values

You can compute a value from one or more signals without having to rewrite additional logic.

import { computed } from '@angular/core';

const double = computed(() => counter() * 2);

• When counter changes, Angular automatically recalculates double.
• computed is read-only and cannot be modified manually.

Advanced features of Angular Signals

In addition to what we have seen, Angular Signals includes several important features, according to the official documentation:

Computed is lazy and memoized

• It does not execute until someone reads it.
• It memorizes its last value.
• It only recalculates if one of its dependencies changes.

const counter = signal(0);
const double = computed(() => {
  console.log('Recalculando...');
  return counter() * 2;
});

• If you never call double(), the function is not executed.

Dynamic dependency tracking

Angular only tracks signals that are actually read within a computed or effect.

const show = signal(false);
const counter = signal(0);

const conditional = computed(() => show() ? counter() : 0);

• As long as show() is false, conditional does not depend on counter.
• This optimizes performance and avoids unnecessary recalculations.

Signals in templates

{{ counter() }}

• Angular automatically detects that the template depends on the signal.
• The UI updates only when the value changes.
• You don't need async pipe, ChangeDetectorRef, or markForCheck.

untracked(): avoid reactive dependencies

Allows you to read a signal without registering it as a dependency within an effect or computed.

effect(() => {
  console.log(`User set to ${currentUser()} and the counter is ${untracked(counter)}`);
});

• The effect runs only when currentUser changes.
• Changes in counter do not trigger the effect, but we can still read its current value.
• This is useful when you want to read data incidentally without turning it into a trigger for reactivity.

Live practical example: clock and user table with Angular Signals

Instead of showing all the code here, we’ve prepared an interactive example on StackBlitz so you can see Angular Signals working in real time.

In this example you will observe:

• A clock that updates every second.
• A user table where each row depends on a signal, avoiding unnecessary updates.
• How the UI updates only when the relevant state changes, improving performance compared to classic change detection.

Try the live example on StackBlitz.

Visual comparison

Conclusion

Angular Signals represents the evolution of the change detection model explained in our previous article.

Previously, any asynchronous event could trigger a full change detection cycle. Now, Angular updates only the bindings that depend on the signals that change, avoiding unnecessary computations and improving efficiency.

With Signals and derived values (computed), we can build faster, more predictable, and easier-to-maintain applications, especially as the component tree grows.