And there is one thing that often makes a difference: the interface reacting. Feeling that what you do has an immediate response makes everything feel more alive and polished. It is true that adding these kinds of interactions does not always make sense, but when they are used well in the right context and at the right moment, they greatly improve the final result.

One of the simplest and most eye-catching effects is cursor tracking. And although it may seem complex at first glance, it is actually super easy to build.

What Exactly Is Cursor Tracking?

Cursor tracking consists of detecting the cursor position and using it to update the position of an element on the screen.

From a technical perspective, it can be summarized in three steps:

1. Listen to mouse movement (mousemove)
2. Retrieve its coordinates (clientX, clientY)
3. Update the DOM using those values to create the interaction.

Basic Cursor Tracking Implementation

Now let’s see how we can implement a simple cursor tracking effect. In this case, we are going to build a small trail that smoothly follows the cursor using GSAP, since it allows us to manage animations much more easily and efficiently than with pure CSS.

Here is the full example on CodePen:

The HTML: Preparing the Trail Elements

For this effect, we need several elements that will form the trail. Each of these divs will act as a “particle” that follows the cursor position with a slight delay relative to the previous one.

<div class="trail"></div>
<div class="trail"></div>
<div class="trail"></div>
<div class="trail"></div>
<div class="trail"></div>
<div class="trail"></div>

The CSS: Positioning and Styling

Next, we give them a basic style so they behave like small dots. The most important parts here are position: fixed, so they move relative to the viewport, and pointer-events: none, so the circles do not intercept clicks intended for other buttons or links on the page.

body {
  height: 200vh;
  background: #111111;
  overflow: hidden;
}

.trail {
  width: 20px;
  height: 20px;
  background: #d9ed92;
  border-radius: 50%;
  position: fixed;
  top: 0;
  left: 0;
  pointer-events: none;
}

Then we are going to center the particles when the page loads. If we do not do this, the effect would suddenly start from the top-left corner of the screen (0,0) the first time we move the mouse. With gsap.set, we position them directly in the center:

// Center the particles on load to avoid the default (0,0) position
const centerX = window.innerWidth / 2;
const centerY = window.innerHeight / 2;

trails.forEach((el) => {
  gsap.set(el, {
    x: centerX,
    y: centerY
  });
});

It is important to mention that this is not strictly necessary. There are many ways to approach it. For example, you could hide the particles with zero opacity and make them appear only when the user moves the mouse. But in our example, since there is nothing else on the screen, it makes more sense for the elements to already be positioned and ready to react from the center.

Finally, we add an event listener that will detect mouse movement. On every movement, we trigger a GSAP animation for each particle:

// Cursor tracking with staggered delay to create a smooth trailing effect
window.addEventListener("mousemove", (e) => {
  trails.forEach((el, index) => {
    gsap.to(el, {
      x: e.clientX,
      y: e.clientY,
      duration: 0.2 + index * 0.05, // We use the index so each particle is slightly slower than the previous one
      ease: "power2.out"
    });
  });
});

By using the array index to calculate the duration, we make the first particle almost instantaneous while the following ones move with a slight delay. The result is that organic movement feeling that makes the effect much more visually appealing.

Important: for this example to work correctly, we need to include GSAP in our project. We can do so by adding the following script:

<script src="https://cdn.jsdelivr.net/npm/gsap@3.15/dist/gsap.min.js"></script>

Advanced Cursor Tracking: Creating Eyes That Follow You

We have already seen how to make something follow the cursor, but cursor tracking does not always have to involve full movement across the screen. We can use the same coordinate logic to create subtler and more playful interactions, such as eyes that follow the mouse movement.

In this case, instead of moving the elements themselves, we are going to calculate the angle and distance so that the pupils always stay inside the eye.

You can see the result on CodePen:

The HTML: Eye Structure

For this to work, we need a container for each eye and an inner element for the pupil.

<div class="eyes-container">
  <div class="eye">
    <div class="pupil"></div>
  </div>
  <div class="eye">
    <div class="pupil"></div>
  </div>
</div>

The CSS: Constraining the Movement

The trick here is making sure the .eye container has overflow: hidden. This guarantees that, even if our calculations go beyond the limits, the pupil will never leave the white area of the eye (or, if it does exceed its container, we simply will not see it).

body {
  margin: 0;
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100dvh;
  background-color: #f5f5f5;
  overflow: hidden;
}

.eyes-container {
  display: flex;
  gap: 20px;
}

.eye {
  width: 100px;
  height: 100px;
  background-color: white;
  border: 4px solid #1a1a1a;
  border-radius: 50%;
  position: relative;
  display: flex;
  justify-content: center;
  align-items: center;
  overflow: hidden;
}

.pupil {
  width: 40px;
  height: 40px;
  background-color: #1a1a1a;
  border-radius: 50%;
  position: absolute;
}

The JavaScript: A Bit of Trigonometry and GSAP

This is where things get interesting. To make the eyes look toward the mouse, we need to know the angle between the center of the eye and the cursor.

First, we select the pupils, which are the elements we are going to move:

const pupils = document.querySelectorAll(".pupil");

Now we calculate the movement. Math.atan2 gives us the angle, while Math.cos / Math.sin tells us how much to move the pupil on the X and Y axes so it points in that direction:

window.addEventListener("mousemove", (e) => {
  pupils.forEach((pupil) => {


    // Get the parent eye element and its center position
    const eye = pupil.parentElement;
    const rect = eye.getBoundingClientRect();
    const eyeCenterX = rect.left + rect.width / 2;
    const eyeCenterY = rect.top + rect.height / 2;

    // Calculate the angle between the mouse and the eye center
    const angle = Math.atan2(
      e.clientY - eyeCenterY,
      e.clientX - eyeCenterX
    );

    // Define the maximum movement radius for the pupil
    const maxDistance = 25;

    // Measure mouse distance from the eye center and clamp it
    const mouseDistance = Math.hypot(
      e.clientX - eyeCenterX,
      e.clientY - eyeCenterY
    );

    const distance = Math.min(mouseDistance / 10, maxDistance);

    // Calculate pupil offset based on angle and clamped distance
    const moveX = Math.cos(angle) * distance;
    const moveY = Math.sin(angle) * distance;

    // Animate the pupil for a smooth
    gsap.to(pupil, {
      x: moveX,
      y: moveY,
      duration: 0.4,
      ease: "power2.out",
      overwrite: "auto"
    });
  });
});

Important: just like in the previous example, for this to work correctly we need to include GSAP in our project. We can do so by adding the following script:

<script src="https://cdn.jsdelivr.net/npm/gsap@3.15/dist/gsap.min.js"></script>

As you have seen, once you understand how to capture mouse coordinates, the possibilities are almost endless (and I say “almost” because there will always be something slightly impossible). But with this foundation, we can go from a simple trail effect to a much more advanced animation with only a few changes in the JavaScript logic.

And the best thing about using GSAP for these effects is that it takes away the heavy lifting of managing frames and smoothing, allowing us to focus on what really matters: making the interaction feel natural and adding value to the user experience.

I hope this post helped you better understand how GSAP works and inspires you to create your own animations. Time to experiment!

Now that we already understand what this methodology is and how to implement it, the only thing left is to understand how we can measure it. In this final post, we focus on the foundation of the entire process: measurement, addressing the KPIs that can be used to turn requirements into data and to track progress as accurately as possible based on objective information.

It is not an easy task to have all the tools and frameworks required to perform these measurements, which is why the process is progressive and requires commitment from every member of the organization.

In Green QA, metrics are the thermometer of our efficiency. We do not measure for bureaucracy’s sake, but to identify “energy leaks” and “digital waste.”

When defining the KPIs and OKRs needed to evaluate the different aspects of GQA, we grouped them into the following measurement categories:

• Energy and software (technical efficiency)
• Carbon and waste (planetary impact)
• ESG data quality (trust and compliance)
• Operational efficiency and “Digital Waste” (process improvement)

Energy and Software KPIs (Technical Efficiency)

Here, we measure the physical effort hardware performs to run our software. The KPIs used for this area are the following:

Carbon and Waste KPIs (Planetary Impact)

We transform watts into real environmental impact. The KPIs used for this area are the following:

ESG Data Quality KPIs (Trust and Compliance)

If sustainability data is unreliable, the strategy fails. The KPIs used to measure this area are the following:

Operational Efficiency and “Digital Waste” KPIs (Process Improvement)

It is not enough for a test to consume little; the key is not executing what is unnecessary. Digital waste is silent pollution. The data used to measure this area includes the following:

Standards and Compliance

It is not enough to “be green”; you must prove it to international regulators. Green QA is the final filter ensuring that a company does not incur legal risks by reporting inaccurate data.

In the previous post, we discussed legal aspects where applying Green QA within a company is beneficial. Here, we will look at how to ensure compliance through data and how to verify whether the quality process we followed has contributed to regulatory compliance using the KPIs defined above.

CSRD (EU Directive) + ESRS

The CSRD (Corporate Sustainability Reporting Directive) is the European regulation (in force since 2024) that requires large companies and publicly traded organizations to report detailed sustainability information under Environmental, Social, and Governance (ESG) criteria.

In Spain, the Corporate Sustainability Reporting Bill was approved on October 29, 2024, as a transposition of the CSRD. The ESRS (European Sustainability Reporting Standards) are the mandatory technical standards for complying with the CSRD.

From a QA perspective, we can audit sustainability data. Here, Green QA acts as the “Data Auditor.” It must ensure that ESG data (such as server consumption in Staging) is not based on rough estimates but has technical traceability. If reporting software fails, the company may face sanctions for Greenwashing. We can use the following checklist to verify compliance:

• Data traceability. Is it possible to trace emission data from the original sensor/log to the final report without manual alterations?
• ESG API validation. Has the integration with Cloud providers (AWS/Azure/GCP) been tested to ensure consumption data is extracted without loss?
• Auditability. Does the QA metric include verifiable technical evidence for external audits?
• Accuracy vs. estimation. Have generic estimates been replaced with real hardware consumption data whenever possible?

GHG Protocol (Scope 3 - Software)

The GHG Protocol (Scope 3) is the most widely used global standard for measuring and reporting indirect greenhouse gas emissions (GHG) occurring across a company’s value chain, excluding purchased energy emissions (Scope 2).

From a QA perspective, it is necessary to validate that third-party tools (testing SaaS platforms, CDNs, paid APIs) provide real emissions data. Quality Gates can be created to block deployments if the “carbon budget” of a microservice exceeds protocol limits. We can use the following checklist to verify compliance:

• Footprint calculation. Have updated CO2 conversion factors been applied to the energy consumed during deployment?
• Supplier filtering. Has it been verified that partners (testing SaaS platforms, CDNs) hold ISO 14001 or Energy Star certifications?
• Carbon budget. Does the current release remain within the established emissions limit compared to the previous period?
• Formula validation. Have unit tests been performed on emissions calculation formulas to ensure mathematical accuracy?

ISO/IEC 21031 (Software Carbon Intensity - SCI)

This is the Unit Testing of the carbon footprint. It is an international standard for calculating software carbon intensity (SCI).

The role of Green QA here is to integrate carbon footprint measurement into the testing pyramid. Just as we validate response times, QA validates the energy cost per transaction. If a database change increases CPU cycles, QA acts as the gatekeeper preventing that “energy waste” from reaching production.

• Intensity analysis. Has kWh consumption been measured for each test suite execution?
• CPU optimization. Does the code avoid unnecessary cycles or “Green Smells” (infinite loops, redundant API calls)?
• Headless testing. Have tests been run in headless mode to reduce the energy consumed by graphical rendering?
• Idle Energy validation. Has it been verified that Staging environments shut down or auto-scale to zero after execution?

Consumer Empowerment Directive (Anti-Greenwashing)

The EU is banning generic environmental claims without evidence (“100% eco-friendly software”). From a QA perspective, evidence must be certified. If marketing claims the app consumes 30% less battery, QA should have run energy regression tests (using tools such as GreenFrame or Lighthouse) that support the claim with empirical and repeatable data.

Web Accessibility (WAD / WCAG) as Sustainability

There is a direct correlation: an accessible and lightweight website is also a low-consumption website. From a QA perspective, the DOM must be validated for efficiency. Fewer unnecessary elements and redundant requests mean fewer CPU cycles on the client device. Here, QA combines social impact (inclusion) with environmental impact (efficiency).

Carbon Footprint Measurement Table

At this stage, we present a table with useful data commonly used to automate carbon footprint calculations. These values evolve as technologies improve and become more efficient, so they should be considered estimates.

Conclusions

Throughout this three-part series on Green Quality Assurance, we have explored the possibilities within the technology world, and specifically within the software industry, to take action and improve energy efficiency.

This happens mainly because of what we could call a kind of “systemic blindness.” When you look at the company from the Executive Committee table, everything seems like a perfect, clean, and organized org chart. Operational reality, however, is a complex network of human and technical interdependencies. Trying to manage deep change based only on the org chart is, essentially, managing an illusion.

If we truly want to connect strategy with day-to-day execution and protect the benefits of a successful transformation, we need to look at three invisible dimensions that very few people take into account. They don’t appear in financial reports, yet they are the forces that either drive or block a company’s progress:

1. Cognitive dimension: the available mental and emotional capacity of your team.
2. Structural dimension: the real rules of the game (such as incentives and interactions between people and departments) beyond job titles.
3. Flow dimension: the real path that value follows, regardless of hierarchy.

Let’s see how these invisible barriers can block execution through real-world examples.

1 Cognitive barrier: the hidden cost of uncertainty

This dimension refers to the organization’s “mental bandwidth.” Think about it: if professionals spend their energy surviving fear or uncertainty, biologically they no longer have the resources to innovate or think long term.

Let’s take a typical example. Imagine a company announcing a merger or restructuring with the promise of “becoming more agile.” Months go by, and nobody knows exactly what their role is, whether their manager will remain the same, or whether their position is at risk because it overlaps with someone else’s.

Leadership reviews employee profiles and thinks: “We have the best talent in the market, why is there so much resistance and so little proactivity?”

This is not an attitude problem—it’s pure biology. The human brain processes social uncertainty as if it were a physical threat. Different studies and research projects have addressed this issue and reached the following conclusions:

• High performance collapses without psychological safety (as demonstrated by Google’s famous Project Aristotle).
• Living under the stress of uncertainty can reduce functional IQ by around 13 points (according to the research of Mullainathan and Shafir - Harvard/Princeton).

Let’s also add, although we won’t solve it here, the issue of how AI can help or limit human intelligence and the uncertainty this is generating.

How can we overcome it?

By understanding psychological safety as a form of risk management to protect the team’s intelligence—not as a matter of “being nice.” And yes, it can be measured by going beyond classic performance KPIs and starting to use Key Behaviour Indicators (KBIs): indicators that measure real behaviors, such as how often teams report errors without fear (directly linked to psychological safety) or how much collaboration exists between departments. This allows us to visualize what drives success and what needs improvement.

2 Structural barrier: the trap of local optimization

This dimension is about how interactions and incentives are designed between the boxes of the org chart—not about how those boxes are drawn.

Imagine the classic end-of-quarter scenario. Sales leadership has a bonus tied to sales volume. Meanwhile, technology/operations leadership has its own incentives tied to stability and cost reduction. The result? Sales closes contracts by promising highly customized solutions that require massive amounts of work in order to hit quota. Meanwhile, Operations slows down deployments or limits customizations to reduce costs and meet its own targets.

The outcome is that both departments strictly meet their individual goals or KPIs, but customers don’t receive what they expected, the company loses money, teams waste time and effort, and everyone spends an immeasurable amount of time looking for someone to blame.

As Russell Ackoff explained, organizations frequently fall into the trap of local optimization: when you improve the individual parts separately, you often end up destroying the performance of the whole.

How can we overcome it?

By redesigning interactions: as long as incentives reward vertical silos, collaborative ways of working and agile methodologies will struggle to succeed. Here, the role of the C-Level must include, among other responsibilities, redesigning how different areas interact rather than evaluating each area’s performance in isolation.

This requires goals that directly impact the entire company, making Sales and Operations (in this case) work together to achieve them. Shared goals where people win—or lose—together.

3 Flow barrier: what you can’t see is costing you money

This dimension focuses on the difference between “busy people” and “completed work.”

Imagine a scenario where everyone around you is constantly busy, overwhelmed with tasks: every calendar is packed and people are operating at 100% capacity. Yet a key initiative takes 12 months to reach the market. Sound familiar? And then the inevitable question arises: “How can it take this long when everyone is working so hard?”

The reality is that value does not move when people work; it moves when work flows. In most companies, tasks spend a significant amount of time sitting in “invisible queues” (waiting for budget approval, waiting for validation, waiting for a testing environment, etc.).

How can we overcome it?

By using Value Stream Management (VSM). Think of it as an “X-ray layer” that ignores hierarchy and visualizes the flow of work and information until it becomes value. As Mik Kersten explains in Project to Product, by managing flow instead of isolated projects, you eliminate the waiting times that no org chart is capable of revealing.

Conclusion: from control to architecture

There is a traditional inertia in the business world: when something fails, we tend to blame people and try to “fix” them with more pressure or more training. But W. Edwards Deming already demonstrated with his 94/6 Rule that 94% of problems belong to the system and only 6% to the individual.

The organizations leading the market today focus on “architecting the environment.” Taking warm data into account in change and optimization processes can contribute to more robust organizational evolution.

And what does “architecting the environment” mean?

It means deliberately designing a work ecosystem where “doing the right thing” becomes the easiest option. In this way:

• Collective intelligence is protected (Neuroscience).
• Incentives and ways of working are aligned to encourage collaboration (Systems Thinking).
• Obstacles are removed so work can flow (VSM).

As Skelton and Pais explain in Team Topologies, competitive advantage no longer belongs to those who pressure their teams the most, but to those who design better systems.

The question that remains is: are we managing people, or are we designing the system for success?

References

• PMI-The Economist (2013). Why good strategies fail: Lessons for the C-suite.
• CIO Magazine (April, 2026).
• Google re:Work - Project Aristotle.
• Mullainathan, S., & Shafir, E. (2013). Scarcity: Why Having Too Little Means So Much.
• Ackoff, R. L. (1994). The Democratic Corporation. Oxford Univ. Press.
• Kersten, M. (2018). Project to Product. IT Revolution.
• Deming, W. E. (1986). Out of the Crisis. MIT Press.
• Skelton, M., & Pais, M. (2019). Team Topologies.

Despite using a single-threaded implementation, Redis, the high-performance in-memory key-value storage system, is known for its incredible speed.

How is it possible for Redis to handle hundreds of thousands of requests per second? First of all, it is important to clarify that Redis does use multiple threads; it is not a strictly single-threaded system.

Although it is true that it maintains a thread responsible for processing client requests and handling data structures, Redis uses other background threads to execute additional tasks required for its operation.

So why is it so fast?

• Redis keeps all data in memory, enabling extremely fast access.
• The use of a simple key-value data model allows for O complexity in key lookups.
• The use of I/O multiplexing with non-blocking I/O enables efficient handling of multiple I/O operations.
• Use of simple commands that require minimal CPU usage.
• Use of optimized data types for in-memory operations.

Multithreading Optimizations

• Asynchronous Memory Release: starting with Redis 4.0, the lazy-free mechanism was introduced to release memory asynchronously. Memory release when deleting large keys is handled in a background thread.
• Multi-threading: as stated on the Redis blog, “starting from version 6.0, Redis uses I/O threads to manage client requests, including socket reads and writes, as well as command parsing. However, the implementation does not fully leverage the potential performance benefits.”

The use of multithreaded execution helps reduce the pressure on the single-threaded execution of incoming requests in high-concurrency scenarios. This multithreading process only applies to the parsing of the request protocol, while command processing and data manipulation remain single-threaded.

With the release of Redis 8.0, a new multithreaded I/O implementation arrived, promising major improvements in data transfer (between 37% and 112%, according to the data published by Redis) on multi-core CPUs.

Testing the New Multithreaded Implementation

As we already mentioned, Redis processes requests in a single thread, dividing execution into the following 4 steps:

1. Reading the request from the socket
2. Parsing the request
3. Processing the request by executing the required operations on the data
4. Writing the response to the socket

A new request will not begin processing until these 4 steps have been completed sequentially for the current request.

Writing results to the socket in step 4 is typically a slow operation in terms of completion time. This is where we can benefit from the new multithreaded I/O implementation by configuring Redis to execute I/O operations in a separate thread. In this way, Redis is able to begin processing a new request in parallel, thus improving performance.

The Redis io-threads property (which is immutable) is the setting we will use to configure multithreaded socket writes. Remember that this property defaults to 1 and is used to indicate the maximum number of threads that can be created for socket writes.

Redis also provides the io-threads-do-reads configuration property, which enables multithreaded execution for reading and parsing requests from the socket (steps 1 and 2 described above). However, according to Redis documentation, this option does not have a significant impact on performance.

Therefore, we will focus solely on the impact of the io-threads configuration.

Synthetic Tests: How Were They Executed?

Benchmarking Tool

For the tests, we used memtier_benchmark, an Open Source benchmarking tool developed by Redis Labs and integrated into their development processes, mainly for non-regression testing and performance optimization.

memtier_benchmark was introduced in the official Redis blog and the project is available on GitHub.

Our Redis Test Environment

We are going to use a Redis cluster deployed on OpenShift Container Platform (OCP) with the following configuration:

• Cluster nodes: 5
• CPUs per node: 4
• Memory per node: 4Gi

We will use 4 different images to build the nodes, allowing us to compare performance across versions:

• redis.redis-stack-server:7.2.0-v10 (image based on the official redis-stack-server image with some modules enabled)
• redis:7-bookworm (official image)
• valkey/valkey:8-bookworm (official image)
• redis:8-bookworm (official image)

Test Objectives

With these tests, we aim to:

• Determine the optimal value for the io-threads configuration parameter.
• Decide which Redis flavor we should choose: the old and well-known Redis or the fresh and young Valkey.

As we have seen, we can set any value above the default value of one thread for the io-threads parameter. We are interested in understanding the performance impact of changing this configuration.

On the other hand, we know that after Redis announced it would no longer be open source, several forks of the project emerged. After reviewing those with the highest activity and contributor growth, we decided to limit our tests to Valkey.

We are also interested in comparing Valkey’s performance against the latest Redis versions. Redis, in particular, has received very positive feedback regarding performance improvements since the release of version 8.

Test Results

Each test begins with a freshly created Redis cluster in a dedicated namespace within our OCP environment. Likewise, a new pod is created from which the benchmarking tool is executed at the start of each test.

The io-threads values used were: 1, 8, 12, and 16.

The following table summarizes the results obtained in the different tests, showing the average number of operations per second for each image and io-threads configuration.

The same data represented as a chart:

It seems that the optimal point is reached with an io-threads configuration equal to 2 times the number of CPUs configured per Redis node.

Beyond this value, performance degradation can be observed in Valkey 8, while Redis 8 maintains stable performance even when exceeding this optimal point. Therefore, Redis 8 results are more consistent.

As expected, no performance improvement was observed in Redis 7 when increasing io-threads. On the contrary, we were surprised to observe performance degradation.

Redis 8 outperformed Valkey 8 in all scenarios. Therefore, we settled on the 2xCPU rule as the default io-threads configuration, and for now, the balance clearly favors Redis 8 as the image to use for our Redis clusters.

Applying the Knowledge Gained: Resource Optimization in a Real Scenario

The scenario: an application deployed on Kubernetes, making intensive use of a Redis cluster and requiring extremely high request-per-second rates.

The Redis cluster, during peak usage periods, must scale to 100 nodes in order to support the required performance. Currently, this cluster is made up of nodes instantiated from the Redis Stack 7.2 image, with 1 CPU per node.

Our goal is to reduce the number of cluster nodes by half, moving from 100 to 50 nodes using the Redis 8 image. To achieve this, we doubled the number of CPUs per node from 1 to 2 and set the io-threads configuration to 4, as previously determined, in order to benefit from the improvements offered by the new I/O threading implementation.

To validate that the platform with this new configuration is capable of supporting peak usage periods, we used a set of complex tests specifically designed to subject the platform to workloads similar to those expected during those peak periods, thus validating its ability to withstand extreme demand.

These End-to-End (E2E) tests were custom-developed using Spring Framework and the Redis Lettuce client.

Taking advantage of the platform’s maintenance window, the full test suite was executed using the following configurations in order to compare the results:

• Redis Stack 7.2 - 100 nodes (1 CPU)
• Redis 8 - 50 nodes (2 CPU)
• Valkey 8 - 50 nodes (2 CPU)

We also leveraged the Redis Operator developed to manage all Redis clusters (currently released as Open Source), which deploys, alongside the cluster pods, an additional pod responsible for extracting a large number of metrics and exposing them to Prometheus, together with Kubernetes metrics, to be displayed in Grafana dashboards.

Let’s review the results obtained.

Processed Commands

We can see how the cluster built with Redis 8 takes advantage of the io-threads configuration and the new implementation, nearly matching the number of commands processed per unit of time by the reference Redis Stack 7.2 cluster. Each node practically doubles the number of processed commands per unit of time compared to Redis Stack 7.2.

Valkey 8 shows behavior similar to Redis 8. Unfortunately, at the beginning of the test, one node pod was evicted, which explains the small drop visible in the chart.

Hits

The same behavior observed for processed commands per unit of time is repeated in the number of hits. Both Redis 8 and Valkey 8 nearly achieve the reference performance of Redis Stack 7.2 using half the number of nodes.

To provide an idea of the amount of data handled during the tests, the following charts show the number of keys stored per node.

Cache Entries

If we take a look at CPU usage, we see more consistent results in Redis 8 than in Valkey 8.

CPU Usage

To conclude the comparison of the collected metrics, let’s take a look at the network outbound throughput of the nodes.

Network Out Throughput

Final Conclusions

The new I/O threading implementation included in Redis 8 and Valkey 8 truly makes a difference compared to previous implementations. By using multiple threads to write command results to the socket, the load on the main thread is significantly reduced, enabling an impressive increase in performance per node.

From the test data, we can conclude that a performance improvement of 90–95% was achieved.

Using Redis 8, with the improvements it introduces and especially with its I/O Threading implementation, we can achieve a considerable reduction in resource consumption. After the tests, we were able to handle peak periods using half the number of nodes per cluster while increasing CPU allocation from 1 to 2 per node.

If we look only at the Redis metrics presented here (and several others omitted because they were less interesting), Redis 8 and Valkey 8 show very similar performance. However, we also reviewed logs and client application metrics. There we observed that Redis 8 behaved more consistently than Valkey 8. It maintained more stable throughput rates throughout the tests, while Valkey 8 showed some fluctuations.

Redis 8, after returning to the Open Source world, has demonstrated impeccable performance. It has also shown a higher level of optimization, in addition to behaving more stably and consistently under different io-thread configurations.

For all these reasons, we are sticking with Redis 8, at least for now.

References

• Redis 8.0-M03 is out. Even more performance & new features, Redis Blog
• memtier_benchmark: A High-Throughput Benchmarking Tool for Redis & Memcached, Redis Blog
• Github RedisLabs
• Github Redis Lettuce

What changes, for whom does it change, and how will we know it has changed?

When this isn’t clear, what usually happens is that we start with energy, the backlog grows, we deliver things… and a few weeks later someone asks: “okay, and what was this for?” And it’s usually not a problem of effort, but a problem of focus.

For me, a product mindset is not about roles, ceremonies, or tools. It’s about putting the focus on three things before we start building: what problem we want to solve, for whom, and what value we expect to generate.

The most common mistake is starting with the “what.” Early conversations revolve around what needs to be built, expected deliverables, timelines, who does it, and where we track it. These are valid questions. The problem is that if we start there, we risk organizing ourselves around executing something that might not have been the most important thing.

That’s why, before going into execution, it’s worth grounding purpose, user, and value with these questions:

• Why are we doing this? What problem are we trying to solve?
• Who is the real user?
• What improvement do we expect to see and how will we notice it?

If this isn’t clear, jumping into the backlog too early won’t help. This often happens with initiatives that already come framed like this:

• “We need a dashboard.”
• “We need to automate this process.”
• “We want a new screen.”

The risk here is accepting the solution without fully understanding the need. It happens, for example, with requests like: “automate request approvals.” Up to that point, what we have is a solution. The useful conversation starts when you ask: “okay, but for what purpose?” And then the real problem emerges: reducing response times and avoiding errors. From there, you can be more precise:

• User: the operations team managing the requests and the end customer affected by delays.
• Expected value: moving from 5 days to 24 hours and reducing rework.
• Decision: before automating, it might be better to remove redundant validations, clarify criteria, and define exceptions.

The underlying need hasn’t changed. What changes is the quality of the decision.

Product is the combination of purpose, user, and value

When we talk about product, for me there are three elements that cannot be missing: purpose, user, and value. If one of these is missing, it’s easy to fall into a dangerous dynamic where we work a lot but with unclear impact.

• Without a user, value becomes abstract: we don’t know for whom we are improving something or what change we want to create. This also applies when the user is internal. Whether they are in Operations, Technology, Risk, or Finance doesn’t change the core idea: we still need to define who they are, what friction they face, and what improvement would truly be valuable to them.
• Without value, the user becomes an empty description. In this post we won’t go deep into what value means, but when I talk about value, I don’t mean just business value. It can appear at different levels:
  • User value: less friction, more clarity, fewer waits, fewer errors.
  • Business value: more adoption, lower cost, less risk, better conversion.
  • Delivery system value: higher quality, more stability, less rework, fewer artificial urgencies.
• Without purpose, everything sounds reasonable but is hard to prioritize. There’s a useful distinction here that connects with Simon Sinek’s Golden Circle: it’s not the same to talk about the why as it is to talk about the what for. The why refers to the purpose of the initiative. The what for translates that purpose into impact—the change we want to create.

What matters is that something changes in an observable way. If nothing visible changes, we are probably not creating value—we’re just doing things.

A good question to ground this is: What real improvement will the user experience if this works?

How to bring this into daily work

1. Start with the problem and value, not the deliverable.

Before talking about solutions, be clear about what pain you want to solve, for whom, and what improvement you expect. Tools like a well-focused Inception help align purpose, user, value, and how we will know we’re on track.

For this starting point, it helps a lot to write down something as simple as:

• Our objective: we are here to...
• The current problem: today, what happens is...
• Who it affects: this mainly affects...
• What we expect: if everything goes well, it should change...
• How we’ll know: we’ll notice it because we’ll see...

Don’t see it as bureaucracy. See it as a way to align better and prevent the backlog from becoming just a task list.

2. Connect strategy, focus, and backlog.

If an initiative is not connected to a real priority, the backlog ends up full of work—but not necessarily value. That’s why it’s important to connect strategy, prioritization, and roadmap.

3. Translate intention into real tracking.

If you say you’re aiming for impact, you need to review it. It helps to define objectives properly and complement them with observable outcomes, without confusing activity with impact. For this, you can use OKRs, paying attention to their anti-patterns.

Conclusion

Working with a product mindset is about making better decisions from the start. The next time you kick off an initiative, I would pause for a minute on these three questions:

• What specific value do we want to create?
• For whom, exactly?
• How will we know we are achieving it?

Because value doesn’t appear at the end. It’s decided at the beginning and reviewed along the way.

Your backlog shouldn’t prove that you’re working. It should prove that you’re changing something valuable for someone. I’ll read you in the comments! 👇

The future is already here. And it’s full of technical debt.

What the market is revealing in this second quarter of 2026 is not a story of technological promises. It’s a story of execution—and of who is capable of delivering it and who is not. Leading energy companies are not differentiating themselves today by the AI model they have chosen or by the cloud provider they sign contracts with. They differentiate themselves by something far more prosaic and far more difficult: the ability to bring complex systems into production within operational environments that have accumulated patches for decades.

Analyzing market behavior so far this year, five perspectives emerge that will define who leads the second half of this decade. These are not trends. They are diagnoses.

Perspective 1: your agentic AI has a plumbing problem, not an algorithm problem

Until recently, Artificial Intelligence in the energy sector lived in PowerPoint presentations and isolated pilot projects. In 2026, the conversation has matured toward Agentic AI: autonomous systems embedded in critical workflows that not only recommend decisions but execute them—balancing loads in milliseconds, coordinating predictive maintenance, or managing distributed resource portfolios.

The operational reality we’ve observed in 2026 is this: it’s not the algorithm slowing you down. It’s the data architecture you’re trying to run it on.

Organizations that have failed to scale their agents haven’t done so because they chose the wrong model. They failed because they tried to automate on top of a fragmented data ecosystem—legacy silos, undocumented pipelines, and governance that exists in theory but not in production. Automating a broken process doesn’t fix it—it scales it. And failure scales with it.

Industry leaders are being forced to take the step no one wants to take: redesign the foundations. Not patch them—redesign them. That means abandoning cosmetic integration approaches and building truly AI-native architectures: unified data lakes, real governance, pipelines with end-to-end observability. Only from there can an agent reduce downtime in double digits. Only from there does AI stop being a cost and become a driver of financial efficiency.

This is not a science problem. It’s an engineering problem. And engineering is hard work.

Perspective 2: data sovereignty is not a regulatory option, it’s a business condition

The energy transition demands orchestration at a scale no single company can solve alone. Integrating the power grid with electric mobility, HVAC systems, and intraday flexibility markets requires seamless data exchange between actors who are both partners and competitors.

At the same time, attacks on critical infrastructure continue to rise. Digital sovereignty is no longer a legal debate—it is a national and European security imperative.

Initiatives like energy data-X or V2G (Vehicle-to-Grid) projects are proving this in practice: it is possible to connect smart meters, charging points, and flexibility markets without losing control over proprietary data assets. The architecture that enables this separates the control plane (who accesses what, under which conditions, under which contract) from the data plane. Open standards become the condition for interoperability. The connector becomes the mechanism of sovereignty.

The conclusion for decision-makers is straightforward: participating in the decentralized energy economy will require federated infrastructure. Companies that do not build this capability today will not be able to monetize their data assets tomorrow. The sovereign cloud market is not a technological bet—it is the only entry point.

Perspective 3: energy efficiency is no longer reported, it is accounted for

2026 marks the year sustainability stopped being a corporate reputation exercise and became a high-impact financial operation. This is not rhetoric—it is arithmetic.

The Energy Savings Certificates (CAE) system in Spain has reached a level of maturity where verifiable energy savings become liquid, monetizable assets. Every kilowatt-hour saved through infrastructure modernization, industrial process optimization, or efficient technology deployment generates a certificate that energy retailers are required to purchase. ROI is immediate, measurable, and audited.

At the same time, the CSRD directive requires this year carbon accounting as rigorous as traditional financial accounting. This is not a future deadline—it is happening now.

Companies lacking software platforms capable of automating consumption data capture, simulating decarbonization scenarios before committing CAPEX, and integrating environmental decision-making into executive governance will not lose sustainability points—they will lose financial competitiveness. Energy efficiency is no longer managed by the sustainability department. It is managed by business leadership. And it is executed through data tools.

Perspective 4: your grid needs a twin that thinks, not one that represents

Power grids are operating at their limits. Mass electrification, intermittent renewable generation, and the rise of data centers, paradoxically driven by the same AI meant to optimize the grid, have turned transmission and distribution infrastructure into the primary bottleneck of the energy transition.

The market’s response has been the Digital Twin. The reality of 2026 shows that a Digital Twin as a 3D representation is necessary—but not sufficient. What operators need today are Simulation Twins: decision engines that ingest real-time IoT data and enable predictive scenario testing. What happens if a hyperscale data center suddenly demands a massive load spike in four hours? How does the grid respond to a heatwave with unusually high photovoltaic penetration? Where does the system break?

To get there, operators must modernize their legacy platforms—there is no alternative. A rigid infrastructure designed for unidirectional flows cannot process massive bidirectional transactions or interact with the cloud at the latency required by intraday markets. Modernization is not an IT project—it is the only way to manage assets resiliently without relying solely on physical expansion projects that take years and cost hundreds of millions. Those who solve it through platform engineering will gain operational flexibility. Those who don’t will depend on hardware.

Perspective 5: technology that no one adopts does not exist

We can deploy the most sophisticated architecture in the market, but if the organization that must operate it still functions with logic from ten years ago, the value evaporates before reaching production.

April 2026 makes this clear: geopolitical volatility, supply chain bottlenecks, and the speed of AI innovation do not forgive slow organizations. This is not a talent or budget problem—it is an organizational design problem.

Digital transformation in the energy sector is not solved with methodologies—it is solved with operational culture. Multidisciplinary teams where engineering, cybersecurity, and business work in the same sprint, toward the same goal, with shared visibility over data. Structures that prioritize value flow over hierarchy. Organizations capable of absorbing regulatory changes, technological disruption, or supply crises without freezing.

This capability has a name—and it cannot be bought as a tool. It is built by redesigning how teams make decisions, prioritize work, and deliver value. Companies that understand this are systematically reducing technical debt, accelerating time-to-market, and building structures that withstand the next disruption. Those who don’t will continue automating broken processes and calling it digital transformation.

Conclusion: the risk is not technological, it is integration

If 2026 leaves us with one clear lesson, it is this: the right technology, poorly integrated, is worse than imperfect technology that is well executed.

The forces shaping the market today—agentic AI, data sovereignty, efficiency monetization, predictive simulation, and organizational agility—are not independent. They either reinforce each other or cancel each other out. A company with excellent agentic AI on fragmented data will fail. A company with a perfect data platform but no ability to iterate on it will also fail.

Success in this industry no longer belongs to those with the best technology. It belongs to those with the discipline to integrate it, the engineering to sustain it, and the culture to adapt it. There is no shortcut—and no mystery.

It’s time to lead the present to secure the energy of tomorrow.

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.