The Technical Anatomy of an Incorruptible Record

At its strictest core, we are operating with a distributed database that encapsulates information into blocks. The real disruption does not come from this concept itself, but from three non-negotiable architectural properties.

First, immutability. Each block integrates the cryptographic hash of the previous one. This alphanumeric identifier acts as an unalterable mathematical seal that links the entire sequence back to the original block, known in blockchain terminology as the Genesis block. Modifying a single intermediate record would require recalculating the entire subsequent chain. In mature networks with significant volume, this computational effort becomes directly prohibitive and practically impossible to execute.

Second, decentralization. We completely do away with master servers or controlling entities. The network is sustained by thousands of nodes that apply identical rules through what we call a “consensus protocol.” This mathematical mechanism validates each transaction, placing trust exclusively in code and eliminating any single point of failure.

And third, transparency. In public deployments, information is visible to any participant. Although we operate under pseudonyms based on alphanumeric addresses, asset traceability is absolute.

From Wallet to Mempool

To understand its potential, we need to get into the details and observe how information flows. The deployment of an operation does not happen by magic: it follows a logical and auditable sequence.

Everything starts in the wallet or digital wallet. This tool acts as the user’s cryptographic gateway to the network. If I decide to transfer an asset, I sign the request specifying the destination address and the amount. This is where the network of nodes comes into play. When the transaction is launched, a first node intercepts it, mathematically verifies its validity, and propagates it in cascade across the rest of the infrastructure.

Once validated, the request is not executed immediately. It moves into a temporary waiting room called the mempool (memory pool). Transactions wait there until the nodes responsible for assembling blocks select and package them. Depending on the rules of that specific network’s consensus protocol, a particular node will seal the block, recording the operation in the immutable history of the database.

The Threshold of the “Internet of Value”

For decades, we have been comfortable with the “internet of data.” Until now, the network allowed us to send simple copies of digital files. Today, however, we have crossed the threshold into the “internet of value.”

This infrastructure enables the peer-to-peer movement of real assets, eliminating dependency on banks, clearing houses, or traditional validation entities. When the first network, Bitcoin, was launched in late 2008, its only function was to transfer native value. Smart contracts did not yet exist.

The corporate explosion arrived with later operating ecosystems such as Ethereum. Here, the native cryptocurrency does not function as a mere investment. It acts as the technical fuel strictly required to deploy and run decentralized applications. If, as a developer, I want to upload a solution to this infrastructure, I need to pay that operational cost in the network’s currency.

Operational Deployments Beyond the Bubble

The financial impact overwhelms inherited standards. We settle cross-border transfers in minutes compared to the days required by archaic banking pipelines. Decentralized finance (DeFi) already supports complex institutional-grade operations. We operate with algorithmic banks that issue loans or applications that generate yields. From my current company, Merso, we are immersed in this deployment by developing native protocols for installment payments using cryptocurrencies.

But the real qualitative leap for traditional industry happens in supply chains. The ability to audit the origin and journey of products on an immutable foundation solves historical trust deficits. These functional deployments already dominate the market:

• Food traceability: Navidul monitors the full biography of its Iberian cured meats, from the moment the animal steps onto the pastureland to the supermarket shelf. Consumers can audit this unalterable record, including curing processes and factory timelines, by scanning a QR code.
• Industrial auditability: the AIJU technological institute applies this logic to legally prove that toy manufacturing processes meet the most demanding regulatory and safety standards regarding materials.
• Luxury certification: consortia such as Aura Blockchain, promoted by brands like Prada, Cartier, and Louis Vuitton, issue digital passports. These certificates protect authenticity against counterfeiting, tracing the product from raw material extraction to manufacturing, while also enabling a secure secondary market.
• Mechanical guarantees: the second-hand vehicle market suffers from chronic mistrust. Recording maintenance history and mileage on a distributed network neutralizes fraud. Buyers verify the real condition of the car, sellers increase the value of their asset, and the certifying workshop boosts its credibility against competitors.

Roadmap for Executive Teams: How to Bring This Down to Earth

Bringing this infrastructure into your company requires technical strategy. It is not enough to install prepackaged software. Based on my experience, the integration I always propose requires three key steps:

1. Audit the technological foundation

Study the fundamentals. Understanding the technology is a non-negotiable requirement before proposing business hypotheses. Dive into open resources such as the book Mastering Ethereum or subscribe to daily technical newsletters like the one I personally write. If you do not understand the base architecture, implementation failure is guaranteed.

2. Track the industry

Look for pioneers who have validated similar models in your sector. The trial-and-error phase in distributed systems consumes resources at an alarming rate. Validate your idea by observing previous success cases to avoid burning budget on blind experiments.

3. Ground the architecture

Rely on technical profiles capable of analyzing the real feasibility of the infrastructure. Present your business model, design the optimal solution, and make sure to “bring it down to earth” by validating technical feasibility before writing the first line of code.

The paradigm shift has already happened. The only decision left is whether your organization will lead the adoption of this new “Internet of Value” or try to adapt once market standards have changed forever.

In this article, we present an automated benchmark built with Terraform/OpenTofu to compare the real-world performance of these three approaches, measuring sequential read and write operations across different file sizes.

We analyze the IOPS, latency, and throughput of each method, concluding that there is no universally superior solution. Instead, the optimal choice depends on the characteristics of the workload.

Architecture

The test environment is fully defined as Terraform infrastructure-as-code and consists of the following components:

Each component serves a specific role:

• S3 Bucket — Object storage with versioning enabled, SSE-KMS encryption, and public access blocked.
• EC2 Instance — Executes the benchmark automatically at startup through user-data.
• IAM Role — Least-privilege policies: GetObject, PutObject, DeleteObject, ListBucket, and HeadObject on the test bucket.
• S3 Files Mount Target — NFS mount point within the VPC subnet that connects the EC2 instance to the S3 Files filesystem.

Methodology

The benchmark follows a structured design to ensure comparable results across all approaches.

Test Parameters

Measured Operations

For AWS CLI, five sequential operations are measured:

• UPLOAD — Upload 10 files to the bucket.
• LIST — Recursively list the test directory.
• DOWNLOAD — Download the 10 files to local disk.
• HEAD / STAT — Retrieve metadata for each object.
• DELETE — Remove the 10 objects from the bucket.

For s3fs-fuse and S3 Files, benchmarks are performed using oai_citation:0‡github.com (v3.32) with direct I/O (libaio, direct=1), measuring:

• IOPS — Sustained I/O operations per second over 30 seconds.
• Throughput (MB/s) — Effective bandwidth.
• Latency (μs) — Average latency per operation.

The primary metric is the total execution time in milliseconds required to complete each operation (10 files) for the CLI approach, complemented by IOPS and throughput (MB/s) for the FUSE and S3 Files mounts.

Automation

The entire lifecycle—creating the bucket, launching the instance, installing dependencies, compiling s3fs-fuse from source, mounting S3 Files, executing the tests, and generating the results CSV—is orchestrated through a single script executed as user-data during instance startup.

The infrastructure is defined as code using Terraform with two reusable modules:

• modules/s3-bucket — Creates the bucket with the required security configurations.
• modules/ec2-benchmark — Deploys the instance, IAM Role, Security Group, and uploads the benchmark script to the bucket so the instance can download it at startup.

Components

AWS CLI (Native S3)

The native approach uses AWS CLI v2 (aws-cli/2.33.15), which internally performs calls to the S3 REST API. Each invocation of aws s3 cp involves:

• Starting a new Python/CLI process.
• Resolving credentials from the instance profile metadata service.
• Establishing an HTTPS connection to the S3 endpoint.
• Authenticating using SigV4 signing.
• Transferring content (multipart upload for files larger than 8 MB).
• Closing and cleaning up the process.

# UPLOAD — a single file
aws s3 cp "test_10MB_1.dat" "s3://my-bucket/native/test_10MB_1.dat" --no-progress

# LIST — recursive listing
aws s3 ls "s3://my-bucket/native/" --recursive

# HEAD — object metadata
aws s3api head-object --bucket "my-bucket" --key "native/test_10MB_1.dat"

For UPLOAD and DOWNLOAD operations, the benchmark iterates sequentially over the 10 files while measuring the total execution time of the entire block.

s3fs-fuse

s3fs-fuse (v1.97, compiled from source from oai_citation:1‡github.com) mounts an S3 bucket as a oai_citation:2‡en.wikipedia.org (Filesystem in Userspace), allowing objects to be accessed using standard POSIX operations such as cp, ls, stat, and rm.

# Build from source (Amazon Linux 2023)
dnf install -y fuse fuse3 fuse3-devel fuse-devel libcurl-devel \
libxml2-devel gcc-c++ make openssl-devel autoconf automake libtool git

cd /tmp && git clone https://github.com/s3fs-fuse/s3fs-fuse.git
cd s3fs-fuse && ./autogen.sh && ./configure
make -j$(nproc) && make install && ldconfig

# Mount using temporary IAM Role credentials
eval $(aws configure export-credentials --format env)

s3fs "my-bucket" "/mnt/s3" \
-o access_key_id="$AWS_ACCESS_KEY_ID" \
-o secret_access_key="$AWS_SECRET_ACCESS_KEY" \
-o session_token="$AWS_SESSION_TOKEN" \
-o use_cache=/tmp \
-o use_path_request_style \
-o enable_noobj_cache \
-o sigv2

Note: s3fs-fuse is not available as a package for Amazon Linux 2023, so it must be compiled from source during instance initialization.

The mount options are critical for performance:

Internally, s3fs-fuse translates each POSIX operation into the corresponding S3 API call. For example, copying a new file becomes a PUT Object request, while a stat operation maps to a HEAD Object request.

AWS S3 Files (mount.s3files)

AWS S3 Files is Amazon’s native service for mounting S3 buckets as filesystems, available through mount.s3files on Amazon Linux 2023. Unlike s3fs-fuse, S3 Files does not connect the EC2 instance directly to S3. The actual data path is as follows:

The EC2 instance mounts a filesystem via the NFS protocol from an EFS-backed mount target that acts as a high-performance cache. This cache serves local copies of files and synchronizes changes back to the S3 bucket.

# Installation (Amazon Linux 2023)
dnf install -y amazon-efs-utils

# Mounting — OpenTofu creates the File System and Mount Target in the VPC.
# The benchmark script mounts it using the File System ID:

mount_file_id=$(cat /root/benchmark-results/s3files_fs_id)
/usr/sbin/mount.s3files "${mount_file_id}" /root/s3files-mount

# Verify mount
mount | grep s3files

# Example output:
# fs-0bbbd1d66142be171 on /root/s3files-mount type s3files ...

Key characteristics of S3 Files:

S3 Files is designed to provide strong consistency and simplified operations, but its performance characteristics can differ significantly from s3fs-fuse depending on the workload.

Environment Setup

The full deployment is executed with three commands:

# 1. Initialize OpenTofu
tofu init

# 2. Review the plan
tofu plan -var-file=terraform.tfvars

# 3. Deploy
tofu apply -var-file=terraform.tfvars

After apply, OpenTofu returns the instance's public IP.
The benchmark starts automatically in less than one minute:

Outputs:

instance_public_ip = "<EC2_PUBLIC_IP>"
results_location = "/root/benchmark-results/"
ssh_command = "ssh -i <ssh_key>.pem ec2-user@<EC2_PUBLIC_IP>"

Results are stored in /root/benchmark-results/ with the following files:

• results.csv — Raw benchmark data (test_name, operation, file_size, bw_mbps, iops, lat_us).
• fio_*.json — Detailed fio logs per method and file size (latency percentiles, I/O distribution).
• benchmark.log — Complete execution log.
• summary.txt — Configuration summary and commands for downloading results.

Results

The complete dataset is collected in CSV format. CLI results are measured as the total time required to perform 10 sequential operations, while s3fs-fuse and S3 Files results are measured using fio in sustained mode (30 seconds, direct I/O with libaio).

Sequential Read — IOPS

Sequential Read — Average Latency (μs)

Sequential Write — IOPS

Sequential Write — Average Latency (μs)

Read Throughput (MB/s)

Write Throughput (MB/s)

AWS CLI Operations — Total Times (ms, 10 files)

Results Analysis

1 AWS CLI Has a Fixed Overhead of ~7–10 Seconds

Regardless of file size (1 KB or 10 MB), AWS CLI operations show a constant floor of 7 to 10 seconds to process 10 files (meaning it cannot go below that value). This is because each aws s3 cp invocation runs an independent process that:

• Initializes the Python runtime.
• Loads AWS configuration (~/.aws/config, environment variables, metadata service).
• Establishes a new TLS connection with the S3 endpoint.
• Calculates the SigV4 signature (which includes payload hashing for uploads).

File size has little influence because the setup cost dominates over the actual transfer cost, especially for small files over a sufficiently capable network connection.

2 s3fs-fuse Takes Advantage of the Kernel Page Cache

The most dramatic performance difference (up to 750x in DELETE) is explained by the in-memory cache. With the use_cache=/tmp option, s3fs-fuse stores downloaded files in tmpfs (RAM). On Amazon Linux 2023, /tmp is a tmpfs mounted in memory, not on disk. This means the cache competes directly with the available memory of the instance. When the test downloads the same files that were previously uploaded, the kernel satisfies reads from the page cache without generating network traffic.

This is not “cheating”; it reflects a real usage pattern: in production, the same files are often read more than once, and the s3fs-fuse cache eliminates network latency on repeated access.

3 S3 Files: Consistency in Exchange for Performance

AWS S3 Files behaves fundamentally differently from s3fs-fuse. Benchmarks with fio in direct mode (direct=1, libaio) show that S3 Files presents read latencies 7x to 53x higher and write latencies 8x to 115x higher than s3fs-fuse:

For large files (10 MB), the gap narrows but remains significant:

The main cause is s3fs-fuse userspace caching. Even with the fio direct=1 option (which bypasses the kernel page cache), s3fs-fuse maintains its own cache in /tmp at the FUSE process level, while S3 Files performs each request through NFS toward S3 without an intermediate cache, prioritizing strong read-after-write consistency. This double-hop architecture (EC2 → EFS → S3) explains part of the additional latency observed with large files.

4 UPLOAD with s3fs-fuse Shows Variable Results

UPLOAD times with s3fs-fuse fluctuate (35–55 ms) without direct correlation to file size. This happens because the cp operation to a FUSE mount is asynchronous by default: the kernel returns success when data enters the buffer, while s3fs-fuse performs the PUT to S3 in the background. The subsequent sync forces the full write, but the measurement captures only the initial return of cp.

5 LIST Is Extremely Fast with s3fs-fuse

The LIST operation with s3fs-fuse (2–3 ms) is notably faster than with AWS CLI (721–738 ms) because the directory is already cached after previous operations. AWS CLI, by contrast, runs paginated ListObjectsV2 on each invocation, traversing all bucket prefixes.

6 HEAD/STAT: The Metadata Cache Advantage

The enable_noobj_cache option allows s3fs-fuse to also cache negative HeadObject responses. With a constant 15 ms for any file size, s3fs-fuse resolves STAT operations from local cache, while AWS CLI must perform 10 independent HTTP calls (one per file).

7 S3 Files Latency Scales with File Size

A distinctive characteristic of S3 Files is that its latency grows proportionally with file size, both for reads and writes. This is expected in a system without local caching where each I/O operation must complete synchronously through the NFS Mount Target toward S3: EC2 → Mount Target (VPC) → File System → S3. Unlike s3fs-fuse, where per-operation latency remains low thanks to local in-memory caching (tmpfs), S3 Files does not have that intermediate layer:

• Read 1 KB → 686 μs; read 10 MB → 67,888 μs (99x slower)
• Write 1 KB → 4,553 μs; write 10 MB → 80,100 μs (18x slower)

By comparison, s3fs-fuse shows much smoother growth:

• Read 1 KB → 34 μs; read 10 MB → 8,761 μs (258x, but starting from a much lower base)
• Write 1 KB → 42 μs; write 10 MB → 9,496 μs (226x)

8 At 100 MB: S3 Files Throughput Gets Closer to s3fs-fuse

The 100 MB data reveals a key pattern: the s3fs-fuse advantage decreases significantly for large files. For reads, S3 Files throughput (210 MB/s) approaches s3fs-fuse throughput (1,496 MB/s), reducing the gap from 54x (1 MB) to 7.1x (100 MB). For writes, the trend is similar: S3 Files reaches 216 MB/s compared to 1,027 MB/s for s3fs-fuse, a difference of only 4.8x.

This behavior is consistent with the S3 Files architecture described by AWS: for large files (≥ 1 MB), reads are streamed directly from S3, bypassing the cache layer. Since S3 provides high throughput for large sequential transfers, performance converges toward the available network bandwidth.

However, s3fs-fuse read throughput for large files (1,496 MB/s for 100 MB) suggests that its local cache is still serving data from the kernel page cache, since 1.5 GB/s exceeds what a typical network connection can provide. This confirms that fio tests with direct=1 do not fully bypass the s3fs-fuse cache at the FUSE process level, unlike what happens with S3 Files.

9 S3 Files vs. s3fs-fuse in Scalability

The following table summarizes how write latency evolves with file size:

The advantage of s3fs-fuse decreases convergently: from 108x at 1 KB to only 4.7x at 100 MB. This has important practical implications:

• For small-file workloads (metadata, configs, logs), s3fs-fuse is unavoidable: 100x faster.
• For large-file workloads (videos, datasets, backups), the difference shrinks to ~5x, and S3 Files offers strong consistency in exchange for lower performance.
• For massive transfers where throughput matters more than per-operation latency, S3 Files at 216 MB/s write throughput may be sufficient for many pipelines.

Advantages and Challenges

Advantages of AWS CLI (Native S3)

• Operational simplicity — Requires no additional installation or compilation. It comes preinstalled on all Amazon Linux AMIs.
• Strong consistency — Each operation queries S3 directly, ensuring up-to-date data.
• Granular control — Full support for all S3 options: multipart tuning, storage class transitions, tagging, and lifecycle policies from the CLI.
• No local state — Does not depend on cache or persistent mounts. Ideal for ephemeral pipelines (CI/CD, Lambda with containers).
• Auditable — Each operation leaves an explicit record in CloudTrail with the CLI user-agent.

Advantages of s3fs-fuse

• Dramatically higher performance for repeated access thanks to local file and metadata caching.
• Transparency for legacy applications — Any application that works with a POSIX filesystem can work against S3 without modifications.
• Interactivity — Manual bucket exploration with standard tools (ls, cat, less, grep).
• Integration with existing tools — rsync, tar, find, and Bash scripts that operate on file paths.

Advantages of AWS S3 Files

• Guaranteed strong consistency — Each read reflects the latest write without the risk of stale data. Ideal for workloads where data integrity is critical.
• Simplified credential management — Automatically resolves the instance profile IAM Role without needing to manually inject temporary credentials.
• NFS protocol with managed Mount Target — S3 Files uses NFSv4.1 to communicate with a Mount Target in the VPC without going through FUSE. AWS manages the S3 connectivity endpoint, avoiding the kernel/userspace context-switch overhead introduced by FUSE.
• Official AWS support — Maintained by Amazon, with native integration in Amazon Linux 2023 and technical support.
• Simple installation — Available as a system package (amazon-efs-utils) without needing to compile from source.

Challenges of s3fs-fuse

• Eventual consistency — The local cache may serve stale data if the bucket is modified from another source. Manual invalidation is required in multi-writer scenarios.
• Mounting complexity — Requires compiling from source on Amazon Linux 2023 (dependencies: fuse3-devel, autoconf, automake, libtool). Temporary IAM Role credentials must be injected explicitly because s3fs-fuse does not always resolve iam_role=auto correctly.
• POSIX limitations — Does not support atomic renames, hard links, or operations that require file locking. Directory operations can be slow in buckets with millions of objects.
• Mount lifecycle management — Reconnections after network failures require monitoring scripts or systemd mount units with x-systemd.automount.
• Memory overhead — The s3fs process consumes memory proportional to the number of cached objects, which can be significant on resource-constrained instances (such as the t3.micro used in this benchmark).

Challenges of AWS S3 Files

• Lower performance than s3fs-fuse — Without local cache, each I/O operation incurs network latency against S3. In our benchmark, S3 Files shows 7x to 115x fewer IOPS than s3fs-fuse, and latencies 7x to 108x higher.
• Latency proportional to file size — Without intermediate caching, each operation’s duration scales linearly with object size, especially affecting large files (62 ms per 10 MB read vs. 8.7 ms in s3fs-fuse).
• Limited availability — AWS S3 Files is not available in all regions. If the region does not support S3 Files, the option simply does not exist.
• Limited IOPS for small files — With only ~1,400 read IOPS for 1 KB files, S3 Files is far below the ~30,500 achieved by s3fs-fuse, making it unsuitable for metadata-intensive workloads.

Challenges of AWS CLI

• Per-file performance overhead — Each file involves a full process execution. For massive transfers of small files, overhead dominates over actual transfer time.
• No native cache — Every aws s3 cp download requests the data from S3 again, even if the file has not changed.
• Limitations for legacy applications — Applications expecting POSIX file paths cannot use the CLI directly without a wrapper or adapter layer.

Production Use Cases

Beyond the benchmark numbers, these are the scenarios where each method fits best:

ML Training with Datasets in S3

With S3 Files, we can mount petabytes of training data directly as a filesystem without duplicating them onto EBS volumes. Training workers (up to 25,000 simultaneously) access the data as local files, and large training batches are streamed directly from S3.

Recommendation: S3 Files for shared accessibility; s3fs-fuse if epoch-level latency is critical and eventual consistency is acceptable.

Collaborative Workspaces for AI Agents

Multi-agent systems where each agent reads and writes logs, state, and memory into a shared S3 directory. Up to 25,000 resources (EC2, Lambda, EKS pods) can connect to the same filesystem simultaneously.

Recommendation: S3 Files — strong consistency for concurrent writes and bidirectional S3 ↔ NFS access.

Batch ETL Pipelines

Processes that download files from S3, transform them, and upload them back. They do not require a persistent mount.

Recommendation: AWS CLI — simplicity, no local state, and no mounts to manage.

Interactive Bucket Exploration

Data scientists and DevOps teams that need to browse a bucket using ls, cat, grep, or find without mounting anything permanently.

Recommendation: s3fs-fuse — local caching provides instant responses for repeated access, and POSIX interactivity is unmatched.

Large File Processing (> 100 MB)

Videos, image datasets, and backups where throughput matters more than per-operation latency.

Recommendation: S3 Files or s3fs-fuse — at 100 MB, the throughput difference narrows to 5–7x. Prefer S3 Files if strong consistency or simultaneous access from multiple instances is required.

Conclusion

This benchmark shows that the choice between native AWS CLI, s3fs-fuse, and AWS S3 Files depends fundamentally on the access pattern, file size, and consistency requirements:

1. For single-use batch workloads (ETL, backups, one-off migrations), AWS CLI is the simplest and most predictable option, with strong consistency and no local state.
2. For frequent interactive access or applications expecting a filesystem, s3fs-fuse delivers 7x to 115x higher IOPS than S3 Files, and 7x to 108x lower latency, thanks to local caching, in exchange for managing eventual consistency and mount lifecycle.
3. For workloads requiring strong consistency with concurrent writes and filesystem access, S3 Files provides read-after-write guarantees without the need to manage caches, but with significantly lower performance for small files: 1,452 read IOPS for 1 KB files compared to 30,546 with s3fs-fuse, and write latencies of 4.5 ms compared to 42 μs.
4. For large file transfers (100 MB+), S3 Files converges toward s3fs-fuse throughput: at 100 MB, S3 Files reaches 210 MB/s read throughput (7.1x lower than s3fs-fuse), which may be acceptable when strong consistency is the priority.

A key point to consider is that s3fs-fuse results benefit significantly from the read cache. In first-read scenarios (cold cache), download times will be comparable to AWS CLI and S3 Files, since all three approaches must transfer data from S3 over the network.

Adding S3 Files to the benchmark reveals that there is no universally superior solution: s3fs-fuse sacrifices consistency for performance, S3 Files sacrifices small-file performance for consistency and operational simplicity, and AWS CLI offers operational simplicity without filesystem mounting. The choice must align with the specific requirements of each workload.

The complete infrastructure for this benchmark is available as a reusable OpenTofu module in this repository, ready to deploy in any AWS account with minimal configuration.

Have you run similar benchmarks in your infrastructure? What strategy do you use to access S3 from your applications? Share your experience in the comments.

References

• AWS S3 Files Documentation — Complete service guide, architecture, synchronization, and performance.
• AWS News Blog: S3 Files GA Announcement — General availability announcement (April 7, 2026).
• AWS Terraform provider: Release v6.40.0 - Terraform provider version with S3 Files support.
• S3 Files Performance Specifications — Throughput, latency, and limits specifications.
• S3 Files Pricing — Cache storage, data access, and synchronization costs.
• s3fs-fuse GitHub Repository — s3fs-fuse documentation and mount options.
• fio — Flexible I/O Tester — I/O benchmark tool used in the tests.
• Tutorials Dojo: Amazon S3 Files — Conceptual analysis of the S3 Files architecture.

We are currently on WCAG 2.2, published as a recommendation on October 5, 2023, and until now the approach behind these guidelines has remained fairly stable.

Up to this point, the model has been relatively straightforward to understand: on one hand, there was a set of technical criteria defining which aspects a website needed to meet in order to be accessible, and on the other, different conformance levels (A, AA, and AAA) indicating the degree of accessibility achieved.

But this is changing, and that is precisely why I wanted to write this article.

It has now been more than five years since the publication of the first draft of WCAG 3.0, and although it is still exactly that—a draft—the proposal is beginning to take shape and giving us a glimpse of where digital accessibility is heading.

Before continuing, I want to clarify that this is not yet an official standard and should not be used as a legal or compliance reference. For now, organizations should continue working with WCAG 2.2.

How Accessibility Evaluation Changes in WCAG 3.0

I think the best way to understand what I mean by “this is changing” is to analyze how accessibility will be evaluated in WCAG 3.0. Because beyond new criteria or small technical adjustments, what is truly changing is the way we understand accessibility.

Conformance

From WCAG 1.0 through to WCAG 2.2, the system for determining whether a website was accessible has remained almost unchanged: there was a set of success criteria, and depending on which ones were met, a given conformance level was achieved.

These levels were:

• A. This is the minimum conformance level and is achieved when the website complies with all Level A success criteria.
• AA. This level is the minimum legal requirement for most websites that are required to be accessible. It is achieved when all Level A and AA criteria are met.
• AAA. This is the highest accessibility level and is achieved when all A, AA, and AAA criteria are met.

However, WCAG 3.0 proposes abandoning this traditional model and replacing it with a new level system:

• Bronze. This would become the minimum conformance level. To achieve it, all pages, views, and processes included within the evaluation scope must meet all core requirements plus a portion of the supplemental requirements and assertions defined within each Functional Performance Statement.
• Silver. To achieve this level, all core requirements must be met along with a greater proportion of supplemental requirements and assertions than in Bronze.
• Gold. This would become the highest conformance level within WCAG 3.0. It would require meeting all core requirements and nearly all applicable supplemental requirements and assertions.

You can read more about the WCAG 3.0 conformance requirements in the draft.

Later in this article I’ll explain in more detail what core requirements, supplemental requirements, and assertions mean in WCAG 3.0. For now, the important thing to understand is that the current model works in a binary way: a criterion either passes or fails.

However, this new version (WCAG 3.0) aims to move away from that approach and proposes a much more flexible and progressive system based on scoring, outcomes, and real accessibility experiences.

Functional Performance Statements

This new version introduces the concept of Functional Performance Statements, which broaden the way accessibility is understood. You can read more about Functional Performance Statements in the draft.

These statements are not technical criteria as in previous versions, but rather descriptions of how a person can interact with technology based on their functional capabilities, regardless of a specific disability.

The goal is not to produce a list of disabilities but to describe functional limitations that may occur in different contexts and may affect anyone, whether permanently, temporarily, or situationally.

For example, a person with a visual impairment may need “use without vision,” but someone using a mobile phone under bright sunlight with poor visibility may encounter a similar situation.

Types of Provisions

Finally—at least within the scope of this article—version 3.0 also introduces a new concept called Types of Provisions, which defines how different requirements are evaluated and weighted within the conformance model.

These provision types include:

• Core requirements. These are the aspects considered essential for an accessible experience. If any of these requirements fail, conformance cannot be achieved regardless of the total score obtained.
• Supplemental requirements. These are aspects that enhance the accessibility experience but whose absence does not completely invalidate conformance. They help measure the overall quality of the accessible experience.
• Assertions. These are additional declarations made by the organization itself to demonstrate accessibility practices that cannot always be validated automatically.

Each of these has a different weight and purpose within the new evaluation system proposed by WCAG 3.0.

Conclusions

WCAG 3.0 is still in draft status, but it already points to an important shift in the way we understand digital accessibility.

Beyond new levels, new terminology, or new metrics, what truly changes is the approach: we move from a model based on strict technical compliance to a model more focused on outcomes, context, and real user experience.

This does not mean WCAG 2.2 becomes irrelevant—quite the opposite: it remains the current standard and the active reference for web accessibility. But understanding where WCAG 3.0 is heading helps us anticipate how digital product design and development will evolve over the coming years.

That said, I hope you enjoyed this article and that it helped you better understand what we can expect from the new version of WCAG. I’d love to hear your thoughts in the comments!

In engineering, we have reflected deeply and worried a great deal about how to properly manage and address this structural problem. Good technical debt management tends to make it emerge, be identified, and enable agile mechanisms to deal with it, so that it becomes sustainable over time and does not block our deployments.

However, there is another type of debt that has a much larger and deeper impact on organizations and, paradoxically, we talk about it much less: organizational debt.

While our technical teams refactor code and optimize infrastructures, our corporate structures often accumulate inefficiencies, obsolete processes, and departmental misalignments that threaten organizational health.

The Silent Origin: When the End Justifies the Means

Just like financial debt, taking on debt can be a good thing when it serves a strategic purpose and, at the same time, we are able to build a reasonable framework over time to repay that debt. Accepting temporary friction in the organization to capture a market opportunity is a perfectly valid business decision.

Organizational debt occurs when there is a decision, whether explicit or implicit, that creates an unmanaged future cost. This debt accumulates and behaves like a small virus that gradually enters organizations and slowly spreads over time.

Sometimes it begins as a small decision justified by a greater good, whether operational efficiency, the unavoidable urgency of time to market, or the conscious choice of the lesser evil to save a critical milestone. And this is not necessarily wrong. Just as we must be able to generate and assume technical debt responsibly when developing a product, exactly the same must happen with organizational debt in business management.

The problem comes when, at an organizational level, we are unable to identify the debt we are generating and tackle it continuously. That is when “temporary exceptions” crystallize and become the norm.

The Impact on Culture and Proactivity

Organizational debt can take many forms, and if you work in a large company, all of this will probably sound familiar.

It may be a workflow between departments that simply does not work and creates constant bottlenecks, a bureaucratic procedure that was defined with the best intentions but was never successfully implemented in operational reality, a lack of clear role and responsibility definition that leaves critical tasks orphaned, or even a way of organizing internal knowledge that is not structured, forcing us to reinvent the wheel in every new project.

You have probably seen these things a thousand times in every organization. And it is also very likely that, if you have tried to ask about them, you have received automatic responses such as: “we’ve always done it this way,” “we all know it doesn’t work, but it doesn’t hurt anyone,” or “this is the usual way of doing things in our culture.” These responses are a clear reflection of our cognitive biases applied to corporate inertia, where the mind prefers to maintain the familiar status quo rather than face the effort of restructuring.

Often, the most toxic aspect of this organizational debt is not the inefficiency of the process itself, but the example set by the fact that the debt is not managed and remains exposed, in front of everyone and visible every single day.

When it begins to spread, debt is like a poison that gradually paralyzes action, brave decision-making, and team proactivity. The underlying message implicitly being sent to employees is: “it doesn’t matter if we don’t do things well.” This creates rust that slowly settles into the gears of the company, eroding motivation and turning innovation into a path full of unnecessary friction.

Action Patterns for Sustainable Management

In these situations of stagnation, the question we should ask ourselves is: what can we do from our side to help solve the problem of organizational debt?

There are no magic solutions or infallible frameworks, since every company has its own context, maturity, and idiosyncrasies. But we can apply some patterns, inspired by principles of process optimization, Lean, and software engineering, that can help us move toward truly sustainable debt management. I propose the following four pillars:

1 Identify Organizational Debt

The first step in solving a problem is, invariably, bringing it to light.

Identifying and “declaring” that debt exists is, in itself, a vital statement of intent for company culture. First, because we give it a specific name and define a clear perimeter. Second, because we publicly acknowledge that there is an improvement area and that solving it matters to us.

This alone, which is fundamentally a matter of attitude and psychological safety, can represent a radical shift in the negative impact trend of organizational debt.

Ideally, there should be some kind of register or backlog (ideally public, transparent, and collaborative) for organizational debt, similar to how we manage user stories. Through this backlog, we can assign an owner, track progress, and measure impact. This can be done at the large department level, at the technical team level, or even at a personal level for day-to-day work management.

2 Define Priority, a Preliminary Effort Estimate, and Expected Benefit

Not all debt has the same impact, nor does all of it need to be repaid with the same urgency. It is important to be able to size the volume of debt we have on the table in order to measure and identify the topics with the greatest direct impact on the business (the ROI of solving them) and on people’s well-being. Without this quantification, we risk wasting energy on organizational refactorings that do not generate real value.

3 Establish an Action Plan with Realistic Time Boundaries

Once prioritized, it is time to define the steps to follow.

When establishing this action plan, we must be extremely pragmatic and realistic, clearly identifying the pain points. How many times have we tried to solve a problem by reinventing the approach from scratch, without first analyzing what the real failure was, only to end up building a completely different new process that suffers from the same problems as the previous one?

The reasonable approach is to apply a progressive approximation, just as a wound heals little by little. Sometimes we may not be able to fully solve the systemic problem on the first attempt. And that is okay. What matters is that the plan we define can be executed, is viable, and helps us take tangible steps in the right direction. If we do not completely eliminate the debt but manage to mitigate it or reduce its daily impact, we have made progress and learned valuable lessons. In the next iteration, we will be able to take the next step with much more context.

4 Reserve Organic Capacity to Manage Debt

Finally, and perhaps most importantly for leadership: managing organizational debt should not be understood as an exceptional crisis situation, a one-off “audit,” or an exhaustive radical transformation process. It should be conceived as a continuous improvement activity embedded in our organizational DNA.

Just as development and engineering teams proactively allocate a percentage of their capacity to managing technical debt in order to keep platforms sustainable, organizations must do exactly the same for organizational debt, in an orderly, systematic way and sponsored from the top.

For this to work, leadership must be involved. A CEO, just as they evaluate the profitability of a business line or the adoption of new innovations, should naturally ask in the quarterly Board meeting: what organizational debt have we managed and resolved this quarter?

Conclusion

Dealing with entropy is part of growth, but ignoring it is a risk that no innovative organization can afford in the long term.

What do you think of these recommendations? Do you see them as viable in your company? Tell us what measures you have tried and which ones have truly worked.

If you are not managing that debt yet, the best time to start is today. Identify it, estimate its cost, and define that first step to reduce it. And remember: if the challenge exceeds your team’s current capacity, seeking external support is a brave and strategic decision.

Leave us your thoughts in the comments!

In this post, I wanted to focus on something that always creates problems and drives up costs: customer requirements and building a product backlog with real substance.

I always remember one project where we received some initial guidelines and a few technical definitions, but without any real clarity about the intended outcome.

The goal was to build a website with a “modern” frontend and an API underneath to manage a certain type of order. Time passed, and once the client finally had a clear idea of what they wanted, they said: “I want this in 3 weeks.”

Obviously, it wasn’t possible in 3 weeks. We had to do much more refinement work because, although they knew what they wanted, there were undefined use cases and the actual effort required was closer to 3 months (with all the extra pressure that created both for development and for managing the situation).

This also impacted project billing, leading to several misunderstandings based on “you told me”, “I told you”.

As we learn from everything, that experience completely changed the way I approach these kinds of situations and, reflecting on it now, I see AI as a huge opportunity.

What do teams really need? How can AI help them?

To avoid situations like this, we need clear requirements and the inputs received by the team must be well defined. If that’s not possible (for whatever reason), there should at least be traceability so they can be refined later.

So the question I ask myself (and I already suspected the answer was yes, but let’s see how far we can take it) is: Can AI generate a backlog from customer meetings? How?

Yes. If you have AI attending customer meetings, listening and transcribing requirements, it can help generate a product backlog with:

• Requirements identification. From transcripts, it can detect customer needs, expected functionalities, and technical or business constraints.
• User story generation. Transform detected requirements into user stories using the standard format:
  • As a [user type],
  • I want [functionality],
  • so that [benefit or goal].
• Suggested prioritization. Propose an initial development order based on what the customer emphasizes, technical dependencies, or expected impact.
• Acceptance criteria inclusion. Include acceptance criteria or completion conditions when mentioned (or suggest them when implicit).
• Continuous updates after each meeting. As more meetings take place, it can keep the backlog updated, marking items as “ready for development,” “under review,” and so on.

And the next question I ask myself is: Do we still need a Product Owner acting as an intermediary if AI generates the backlog, etc.?

The answer is YES. Even though AI can automate a lot of work, it does not replace the Product Owner (PO), who:

• Makes business decisions: the PO deeply understands business needs and prioritizes the backlog accordingly.
• Negotiates and communicates with stakeholders: makes decisions when priorities conflict or when ambiguities require human judgment.
• Knows the customer: interprets intentions beyond what is explicitly stated in meetings.
• Validates deliverables: accepts or rejects delivered functionality based on business value.
• Works closely with the agile team: helps clarify requirements during development and answers questions quickly.

AI can process information quickly, organize requirements, draft user stories, detect inconsistencies or ambiguities in requirements, and help keep the backlog clean and organized. AI can collaborate with the PO, but it cannot replace their judgment and leadership.

In short: you can automate a large part of the PO’s mechanical work with AI (such as generating and updating the backlog), but you still need a human role providing leadership, judgment, and strategic vision.

Collaborative workflow between AI and the Product Owner

Here are some practical examples of how AI can work together with both the PO and the team, reducing repetitive tasks and saving time:

Before the customer meeting

• AI: prepares a smart agenda based on previous topics and pending items.
• PO: reviews the agenda and adjusts it according to the product’s strategic priorities.

During the meeting

AI:

• Transcribes in real time.
• Automatically detects and tags requirements, ideas, issues, dates, etc.
• Suggests draft user stories.

PO:

• Facilitates the meeting.
• Makes decisions when ambiguities or conflicting priorities arise.
• Clarifies details with the customer when AI cannot infer them confidently.

After the meeting

AI:

• Generates an executive summary.
• Converts requirements into user stories with acceptance criteria.
• Creates and/or updates the product backlog.
• Suggests priorities and technical dependencies.

PO:

• Validates and adjusts user stories.
• Refines the backlog with the development team if needed.
• Communicates important changes to key stakeholders.

During development

AI:

• Monitors backlog progress.
• Suggests story refinement based on progress or blockers.
• Summarizes team questions or feedback for the PO.

PO:

• Answers team questions.
• Prioritizes tasks.
• Accepts or rejects deliverables.

Tool integration architecture

This is an example of how we could assemble this whole setup, keeping in mind that tools may vary.

1. Meeting capture:

• Zoom / Meet / Teams + Otter.ai or Fireflies.ai.

2. Automatic transcription:

• Otter.ai, Fireflies.ai, or Whisper.
• Output: text or JSON.

3. AI processing:

• AI to transform transcripts into user stories.
• Automation using Zapier, Make, or n8n.

4. Backlog updates:

• Jira / Trello / Azure DevOps (REST API).

5. Team communication:

• Slack / Teams / Discord for automated notifications.

Conclusion

AI promises to transform professional relationships between customers and providers by bringing more certainty, reducing misunderstandings, minimizing risks, and focusing efforts on what truly matters. Its ability to detect blockers and suggest priorities increases both efficiency and reliability in decision-making and collaboration.

Although we are still in an exploratory phase and widespread implementations are not yet common, its potential to become a turning point in this space is significant.

Pixar revolutionized animated filmmaking because its leaders, such as Ed Catmull, built an environment where “anyone could tell anyone else that their idea wasn’t working” without fear of repercussions.

NASA turned the Apollo 13 crisis into an extraordinary achievement because the flight director reframed the challenge through catalytic questions: “What’s still working?”, “What do we need to bring them home alive?”, “How can we improvise with what’s available onboard?” leading to the famous instruction: “Find a way to fit a square peg into a round hole”, in order to build CO₂ filters using the materials available.

And Apple, in its iconic recruiting campaign, connected purpose and creativity by appealing to transcendence: “It’s not just a job, it’s leaving a mark on the world.”

In terms of creativity with organizational impact, these examples show that creativity drives innovation, but only with the support of leadership can it generate sustainable transformation.

“Creativity is just connecting things.” — Steve Jobs

The Enemies of Creative Leadership

Creative leadership depends not only on what we do, but also on what we avoid doing. Marshall Goldsmith, in his book What Got You Here Won’t Get You There, explains that many successful leaders end up blocking their teams’ creativity through unconscious habits.

Among the most common are:

Wanting to Add Value to Every Idea

A classic. Some leaders hear a proposal and, almost automatically, add their personal touch: “That’s good, but do it this other way instead.” Although it may seem helpful, the real effect is demotivating: the team feels that their ideas are never enough. As a result, people stop proposing ideas because they know their work will eventually be “improved.”

The antidote: acknowledge ideas without adding anything else.

Always Having the Last Word

Some leaders believe their authority is reinforced by expressing an opinion at the end of every conversation. The problem is that this interrupts creative flow: the implicit message is that the decision is already made.

The antidote: practice active listening and create space for the team to close conversations with their own conclusions or next steps.

Holding On to Past Successes

“We’ve always done it this way” is one of the greatest enemies of innovation. Leaders who rely on past achievements tend to block disruptive ideas because they threaten the way of working that once made them successful.

The antidote: unlearn. Recognize that what brought us here will not necessarily take us into the future.

Overcoming these habits does not happen overnight, but it is possible. The first step is awareness; the second is replacing them with practices that activate motivation, creativity, and shared vision.

This is how the creative leadership cycle emerges: a continuous process that transforms intention into action and, like continuous improvement, is not a one-time event but an iterative journey where each step reinforces and enables the next.

The Creative Leadership Cycle

Creative leadership can be understood as a four-step cycle that continuously reinforces itself:

1 Motivate: The Hidden Engine of Innovation

What makes someone wake up eager to work? It is not only salary, but also the passion they feel for what they do.

Psychologist Teresa Amabile summarizes it clearly:

“Intrinsic motivation is at the heart of creativity.”

In other words, although creativity also requires knowledge, skills, and an environment that stimulates new ideas, intrinsic motivation is the force that activates them.

Leaders who awaken passion and help people love what they do are leading through creativity. Pixar and IDEO demonstrate that creativity flourishes in environments where experimentation is encouraged and intrinsic motivation is protected.

2 How Defining Problems Drives Innovation

Creative leaders do not limit themselves to giving quick answers. Their greatest contribution is asking powerful questions.

Apollo 13 illustrates this perfectly: the famous “Houston, we have a problem” became more than an alarm—it became a clearly framed challenge that allowed the team to focus all of its creative energy on finding the solution.

IDEO, a global reference in innovation, insists that “a well-defined problem is half solved.”

And if someone asked what exactly makes a good problem? As IDEO explains, “it is one that invites the team to think creatively and connects innovation with real human needs”—which means that, in a way, it is already halfway solved once it is properly framed.

3 The Value of Self-Awareness in Leadership

Creativity flourishes when leaders operate from their strengths and align with their values.

As Peter Drucker wrote in Managing Oneself:

“Most people think they know what they are good at. They are usually wrong.”

This is where personal reflection comes in: What legacy do I want to leave? What truly motivates me?

Stephen Covey proposes a powerful exercise: imagine your own funeral and think about what others would say about you. It may sound extreme, but it connects with something essential: leading creatively means living and acting in alignment with the impact we want to leave.

Leaders should dedicate time to understanding themselves, exploring their possible identities (who they could become), and aligning their role with what truly gives them meaning. That self-awareness is what conveys authenticity and gives strength to leadership.

4 Visions That Inspire and Mobilize

Creativity needs collective direction.

Creative leaders not only define challenges and reinvent themselves—they also articulate a vision that brings people together.

Examples such as Apple’s campaign “It’s not just a job, it’s leaving a mark on the world” or Kennedy’s speech at Rice University “We choose to do these things not because they are easy, but because they are hard” show how shared vision ignites motivation and innovation.

To communicate that vision, both content and form matter: consistency between verbal and non-verbal language, clarity of message, and storytelling.

A vision is not imposed—it inspires.

Self-Management: The Root of Creative Leadership

Peter Drucker warned that, in the knowledge economy, success depends less on the position we hold and more on our ability to manage ourselves internally.

Creative leaders who do not understand or manage themselves will struggle to inspire others.

“Success comes to those who understand their strengths, their values, and how they work best.” — Peter Drucker

Strengths and Values

Creative leadership flourishes when practiced from our strengths and in alignment with our values.

Drucker proposed questions that remain relevant today:

• What can I contribute that others cannot?
• Under what conditions do I perform best?
• Are my decisions aligned with my core values?

The Mirror Test

Drucker recalled the story of a German diplomat who rejected an opportunity because he did not want to see himself as someone who compromised integrity or acted without ethics every time he looked in the mirror.

The lesson is clear: creative leadership is not only about innovating, but about doing so with ethics and personal coherence.

From Self-Management to Inspiration

Self-management also means asking the key question:

“What can I contribute?”

In digital transformation contexts, this question allows leaders to connect their individual contribution with collective purpose.

Only then does creativity become organizational impact.

Vision: From Idea to Action

Creativity generates ideas but, without a vision to guide them, those ideas fade.

Creative leaders do not simply accumulate proposals: their real role is to give them shared meaning and mobilize people toward a possible future.

Jobs captured this perfectly when he said:

“Innovation distinguishes between a leader and a follower.”

A vision is not merely an inspiring speech: it is a narrative that connects ideas with concrete objectives and transforms creative energy into coordinated action.

AI as a Mirror of Creative Leadership

Artificial intelligence has fully entered organizations.

It can generate solutions, analyze data, and automate processes. Even models like Google Gemini or OpenAI’s ChatGPT surprise us by generating text, images, or code that appears creative.

But what is truly at stake is not the ability to produce more content—it is the direction, purpose, and authenticity that only human leadership can provide.

AI opens possibilities, but only a leader can decide what is worth pursuing and with what purpose.

Final Reflection

“Innovation distinguishes between a leader and a follower.” — Steve Jobs

In a world accelerated by technology, only creative and inspiring leadership enables organizations not merely to survive, but to set the direction.

To achieve this, it is essential to unlearn habits that inhibit creativity and begin with deep self-management and purpose.

And if you would like to explore how creative leadership connects with real transformation, I invite you to read three essential analyses by Paradigma Digital developed by Carmen Portillo, José Antonio González, and Javier Navarro.

• People management processes: key to evolving toward adaptive organizations
• Lead through coaching and achieve maximum performance
• The power of effective leadership in technological transformation

Leading today is not about managing what is already known—it is about connecting people, purpose, and transformation through creativity.

Are you ready to do it?

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