Beyond the individual announcements, the developments of recent weeks reflect four underlying trends:

• The emergence of a new generation of models with advanced agentic capabilities.
• The integration of AI into mass-market consumer platforms.
• The convergence of infrastructure and AI-assisted software development.
• The growing importance of digital identity and regulatory compliance.

Claude Fable 5: when an AI model becomes a matter of national security

Anthropic launched Claude Fable 5 as a commercially accessible version of Mythos 5 — the model many analysts regard as the most advanced AI system built to date.

According to the company, Fable 5 shares the same core architecture and capabilities as Mythos, with additional safeguards to restrict certain use cases and support public deployment.

Early benchmarks and independent testing point to significant improvements in coding, complex reasoning, and — most notably — agentic capabilities.

The step forward from previous generations doesn't appear to lie solely in output quality. What stands out is the model's ability to plan, execute, and monitor tasks autonomously over extended periods.

The launch, however, was immediately overshadowed by an unexpected development. Just days after release, the US Government issued an export control directive requiring Anthropic to suspend access to both Fable 5 and Mythos 5 for non-US users.

Unable to implement the restriction quickly and selectively, the company chose to temporarily disable both models for all users while it worked on compliance mechanisms.

The official justification centred on concerns about jailbreak techniques capable of circumventing some of the model's protections.

Anthropic has publicly disputed the severity of these vulnerabilities, arguing that the scenarios presented by the government are not unique to Fable 5 — they reflect behaviours that can be observed across other advanced models already on the market.

Apple reimagines Siri with a little help from Google

Two years after announcing its AI ambitions, Apple has unveiled the next generation of Siri. What makes the move particularly interesting is that it confirms a hybrid strategy: Google's models running on Apple's privacy infrastructure.

According to published reports, Apple is paying approximately one billion dollars a year to licence a customised version of Gemini. But the company isn't simply integrating an external chatbot and calling it done.

Instead, it uses distillation to produce optimised versions capable of running locally on iPhone and Mac, while maintaining compatibility with its Private Cloud Compute architecture.

From a technical standpoint, the approach is significant because it shows that differentiation no longer rests solely on training the most powerful model. Apple has chosen to leverage Google's research capability while retaining control over user experience, hardware, and privacy.

The new Siri capabilities reflect this evolution. The assistant can interpret on-screen context, coordinate information across apps, execute multiple actions in parallel, and draw on personal data to handle complex tasks without requiring detailed instructions.

In practice, Siri is moving away from being a glorified search interface and towards something closer to a contextual digital assistant.

Apple's approach also highlights a broader market reality: foundation model development is concentrating in a shrinking pool of players, while other tech giants compete on integration, distribution, and user experience.

SpaceX acquires Cursor and accelerates vertical integration

Another significant move has been SpaceX's acquisition of Cursor.

Cursor had become one of the most widely adopted coding agents on the market, competing directly with tools like Claude Code, Codex, and Antigravity. Like many companies working in applied AI, however, it depended on third-party infrastructure to run and train its models.

The deal gives SpaceX three strategic assets under one roof: compute infrastructure, model development, and developer productivity tooling.

This kind of vertical integration is becoming an increasingly visible pattern. Companies that simultaneously control compute capacity, models, and distribution hold real advantages in cost, iteration speed, and end-product optimisation.

For Cursor, direct access to compute removes one of the main constraints on its growth. For SpaceX, it means absorbing a product with strong traction among engineering teams and a well-established position within the software agent ecosystem.

Digital identity comes to AI models

Anthropic has also announced a meaningful change to how users access Claude: certain advanced features will now require verification via a government-issued ID and a selfie.

Although the company states that this data will not be used to train models, the decision marks an inflection point for the industry as a whole. For years, access to the most capable models has been effectively anonymous.

The introduction of verification mechanisms suggests that AI labs are beginning to treat digital identity as a necessary component of risk management — particularly as the systems themselves grow more powerful.

This approach is likely to spread over the coming years, especially for capabilities tied to advanced automation, acting on a user's behalf, or accessing high-impact tooling.

The shift echoes patterns already seen in digital banking and financial services: as platforms gain operational power, the demand for robust identification mechanisms grows with them.

Switzerland backs an open-source alternative built for European regulation

While the United States continues to lead large-scale commercial model development, Europe is still working out how to combine technological innovation with regulatory compliance.

The Swiss AI Initiative — led by EPFL and ETH Zurich — has stepped into that gap with Apertus Mini, a family of sixteen open models developed specifically to align with the requirements of the EU AI Act.

What makes the initiative particularly noteworthy is that it publishes not just the model weights, but also the training datasets and associated documentation. That level of transparency is a direct response to the regulatory requirements now taking shape across Europe.

While Apertus Mini's current capabilities appear primarily suited to RAG systems and lower-risk enterprise applications, the project offers a clear picture of how the European AI ecosystem might evolve: smaller models, fully auditable, and designed from the ground up to operate within strict regulatory frameworks.

Conclusion

The developments of June 2026 show an industry entering a new phase of maturity.

Models are no longer competing solely on benchmark performance — they're competing to become agents capable of executing complex tasks autonomously.

At the same time, AI is embedding itself ever more deeply into mass-market products, while infrastructure, digital identity, and regulatory compliance are moving from background concerns to front-and-centre priorities.

If 2024 and 2025 were the years of racing to build ever more powerful models, 2026 is shaping up to be the year the industry figures out how to turn that power into systems that are useful, governable, and scalable for millions of users.

Imagine replacing the delivery of a dashboard with twenty charts with a conversational interface connected to your data. This is not about eliminating dashboards, but about breaking that endless cycle of manual modifications. However, there is a catch: without a solid semantic layer and well-defined metrics, we will simply be accelerating the speed at which we obtain the wrong answers.

What If the Next Report Wasn't a Report? Conversational Analytics

This scenario will probably sound familiar: a business stakeholder needs to understand why sales have dropped over the last week. They open a Data Studio dashboard, start combining dimensions, apply several filters, and eventually end up calling an analyst—either because they do not trust the number they see or because an unexpected question arises, such as a sudden change in campaign performance, causing the entire workflow to break down.

The dashboard has evolved from a democratization tool into a technical barrier that requires constant interpretation.

Conversational analytics completely changes this paradigm. It is not about deploying a ChatGPT clone and giving it unrestricted access to your databases. Instead, it is about building natural language interfaces capable of understanding business context. We move from exploration based on clicking visual filters to a model where the data source is governed, an agent processes the question, returns a structured answer, and suggests the next steps. Visual dashboards will continue to be useful for monitoring recurring KPIs, but they will no longer be the only gateway for querying data.

Why You Need a Semantic Layer Before Talking to Your Data

Placing a language model directly in front of a database without any intermediary is a recipe for operational disaster. AI models do not inherently understand your business logic. If a query asks for the number of users from the last month, the system may execute a technically perfect query against a table while still producing a result that is conceptually wrong from a business perspective.

AI is not a mind reader; it is a context processor. If we ask about last month's revenue, the agent must know whether we mean placed orders, paid orders, or revenue net of returns. Without a semantic layer acting as the official business dictionary, the system will mix incompatible dimensions and drag us into an operational nightmare of decisions based on inaccurate data. The challenge is not the chat interface itself, but the governance behind it. A semantic layer acts as a universal translator that standardizes business definitions before they reach the model.

Tools such as Looker build their value proposition around this principle. Looker Conversational Analytics does not query storage directly; instead, it interacts with its shared semantic layer. When you ask how the conversion funnel performed, the technology translates that request using rules, dimensions, and metrics already centralized and audited by the data team. If your organization lacks a unified definition of what constitutes an active customer or a net sale, the analytics agent will not magically solve the problem—it will simply propagate the error faster.

Whats Under the Hood of an Analytics Agent?

What truly differentiates a FAQ bot from a genuine analytics agent? A traditional chatbot simply predicts the next word based on static training data. An analytics agent has execution capabilities that allow it to connect to APIs, analyze data schemas, generate real-time visualizations, and strictly enforce user access permissions.

Today's ecosystem already shows clear movements in this direction:

• The MCP Server for Google Analytics 4

The Model Context Protocol enables external LLM systems to connect directly to the GA4 API. At present, this integration is limited to read-only operations, allowing access to behavioral data and dimensions without any risk of altering property configurations.

• Looker Conversational Analytics and Dashboard Agents

This Google Cloud infrastructure combines foundation models with BigQuery to enable multi-turn exploration. Users can ask why revenue has declined and then continue the conversation by drilling deeper into the returned data, all while preserving row-level and column-level security restrictions associated with their role.

When the Chatbot Hallucinates Your Conversion Funnel

The biggest enemy of conversational analytics is not processing cost—it is the loss of trust among business teams. If a stakeholder identifies even a single inconsistent figure in a report generated by an agent, they are likely to abandon the system entirely and return to the traditional Data Studio dashboard—or worse, to spreadsheets.

The risks in this environment are both technical and operational:

• The Ambiguous Terminology Trap

The term "user" could refer to a GA4 cookie, a unique CRM record, or a customer with active backend transactions. Without strict mapping, the agent will combine incompatible sources and produce inaccurate figures.

• The Illusion of a Coherent Answer

A language model will always present its responses in a convincing and professional manner, even when it has misinterpreted a time range or a geographic filter.

• The Permissions Nightmare

If the agent does not inherit corporate security policies, a marketing user could end up querying salary data or restricted profit margins simply by asking a well-crafted question.

How Is the Role of the Digital Analyst Being Redefined?

Now for something important: with the rise of analytics agents, the role of digital and data analysts is being fundamentally transformed. Analysts are no longer spending their days rearranging charts on dashboards; they are becoming functional architects of the information ecosystem. Their value is no longer measured by the number of dashboards they build, but by the quality and robustness of the context they provide to machines.

The priority tasks of this new analytical profile shift toward designing detailed data dictionaries, continuously auditing agent-generated responses, and turning frequently asked business questions into reusable analytical assets.

Analysts become the final validation layer, ensuring that attribution rules and conversion goals are properly documented so that models do not operate blindly inside an algorithmic black box.

Where Do We Start Building This New Ecosystem?

Before connecting any AI model to your information repositories, you must establish a solid foundation. If you try to automate access to a disorganized data ecosystem, you will simply automate chaos at scale. Use the following checklist to assess your organization's maturity:

1. Build a unified metrics catalog. Document every KPI in writing, including its exact calculation formula and source systems.
2. Ensure naming consistency. Establish strict naming conventions for events, URL parameters, and data warehouse columns.
3. Implement a semantic layer. Deploy tools that act as intermediaries between model queries and production databases.
4. Define a validation question set. Create a collection of critical queries with known answers to regularly audit agent behavior.
5. Set consumption and action limits. Restrict agents to read-only environments and limit consecutive requests to avoid excessive costs.

Conversational analytics is not here to replace human judgment; it is here to free teams from the repetitive work of extracting reports. The success of these agentic AI systems will depend directly on the quality of the architecture and governance that support them.

Is your organization ready to build a reliable semantic layer, or will you keep sending emails every time a KPI deviates from expectations?

References and Links

• Anthropic Model Context Protocol
• Official Looker Semantic Layer Documentation
• Google Analytics 4 API

One of the areas where its impact is most immediate is document validation. Many organizations review files, contracts, payslips, identity documents, supporting evidence, bank statements, or forms on a daily basis. These processes are necessary, but often repetitive, time-consuming, and difficult to scale as volumes increase.

The idea for this article emerged from a conversation with a friend who faces exactly this kind of work: reviewing documentation, checking that everything is correct, identifying missing information or inconsistencies, and repeating the same process file after file. From that real-world need came a practical question: could we build a solution capable of performing an initial automated validation and simplifying part of this tedious work without removing professional oversight?

Starting from that question, this article presents a specific use case: applying document intelligence, generative AI, and asynchronous processing within a cloud architecture to automate part of the document validation process in administrative workflows. It is not conceived as a chatbot, but rather as a business solution designed to transform scattered documents into structured, verifiable, and actionable information for decision-making.

The problem: the hidden cost of administrative work

In many organizations, a significant portion of the workload is not about making major decisions or solving complex problems, but about checking that everything is in order.

A case file arrives with multiple documents. Someone must open them, verify that they are complete, check dates, amounts, and data, identify inconsistencies, and determine whether the case can move forward. Viewed in isolation, this may seem simple, but the problem emerges when the process is repeated dozens, hundreds, or thousands of times.

In rental or real estate transactions, mortgage assessments, invoice accounting, or internal operations, this review may include ID cards, residence permits, payslips, employment contracts, tax returns, bank statements, supporting documents, and other complementary paperwork. Every document requires attention, every case requires context, and every exception forces someone to stop and investigate.

This is where operational friction appears: lost administrative time, missing documents detected too late, unnoticed errors, duplicated reviews, poor traceability, and difficulty understanding the real status of each case.

The challenge is not only deciding whether a file can proceed. Often, the real bottleneck lies in getting to that decision: organizing documents, classifying them, searching for relevant information, identifying missing elements, detecting inconsistencies, and reconstructing the actual state of the file.

The goal is not to introduce AI for the sake of it. The goal is to identify the points in the process where repetitive work, risk of error, and time loss are highest. Those are precisely the areas where AI can create the most value: classifying documents, extracting information, identifying warnings, and preparing an initial structured review.

Improvement percentages should always be measured in real-world scenarios, but as a working hypothesis, one could expect a significant reduction in mechanical review tasks and late-stage error detection. Not because AI is infallible, but because it helps review documents earlier, more effectively, and with greater context.

Paperwork rarely seems urgent until it becomes a bottleneck

And this is where artificial intelligence can add value. Not by replacing professional judgment, but by changing the starting point. Instead of facing a folder full of unprocessed documents, people can receive an initial structured assessment: which documents are present, which are missing, what information has been extracted, what inconsistencies have been detected, and which cases require immediate attention.

AI does not eliminate review, it organizes it

It is no longer necessary to review everything from scratch. The person responsible can focus on exceptions, questionable cases, and decisions that genuinely require human judgment.

What does generative AI contribute in this context?

Generative AI is particularly useful when information does not arrive as clean, structured data, but rather as heterogeneous documents, free text, PDFs, images, or forms with different formats and structures.

Many organizations do not suffer from a lack of information. They have too much information, but it is scattered.

In a document-processing application, the value of generative AI lies in its ability to interpret content, classify documents, extract relevant fields, generate standardized outputs, and highlight warnings that can later be reviewed by a person.

The key, in my view, is not to treat AI as an infallible source of truth, but as an assistance layer. A tool capable of preparing the ground: reading, organizing, flagging, and prioritizing.

The objective is not to remove people from the equation, but to prevent them from having to start from scratch every time.

From idea to solution

Up to this point, the idea is simple: use artificial intelligence to reduce part of the manual effort associated with document validation.

However, for that idea to deliver real value, it is not enough to connect a generative model and wait for a response. A useful solution must integrate into a complete workflow: receiving documents, storing them, processing them securely, extracting information, interpreting it, storing results, displaying issues, and allowing a person to review the file's status.

And this is critical. In a project like this, AI is only one part of the solution. We also need components capable of fitting into the process: a document upload interface, a backend orchestration layer, secure storage, asynchronous processing, extraction services, models capable of interpreting content, and a clear way to present results.

The objective is not for AI to make the final decision, but to handle the heaviest preparatory work. The idea is for the person responsible to stop dealing with a disorganized collection of files and instead work from a clear, traceable, and prioritized summary.

From there, the solution can be understood from two complementary perspectives: the functional architecture, which explains what the system does and how the process flows, and the cloud architecture, which shows how it is technically implemented on AWS to ensure security, scalability, and maintainability.

Functional architecture: from scattered documents to a reviewable case file

The system's functional workflow can be summarized in a single idea: transform scattered documents into a structured and reviewable case file.

To achieve this, the solution is designed as a chain of responsibilities. Each component fulfills a specific role within the process.

The user interacts with a simple interface to create case files, upload documents, and monitor validation status. Underneath, the backend acts as an orchestrator: registering each document, linking it to the corresponding file, creating processing jobs, and coordinating the rest of the workflow.

From that point onward, the system avoids one of the most common mistakes in these types of solutions: processing everything during upload. Instead of blocking the user, it delegates analysis to an asynchronous processing layer. This allows text extraction, content interpretation, and result generation without turning the user experience into a waiting game.

AI enters the workflow only once the document is ready to be analyzed. First, text and structure are extracted; then generative intelligence helps classify the document, extract relevant fields, detect inconsistencies, and produce a normalized output.

The final result is not an isolated model response, but a traceable view of the case file: received documents, processing statuses, extracted data, warnings, incidents, and elements requiring professional review.

The key is that AI does not replace the workflow; it integrates into it.

Cloud architecture: bringing the functional workflow to AWS

Once the functional architecture has been defined, the next step is to ask how to bring that workflow into a real-world environment that is secure, scalable, and maintainable.

A solution like this requires a solid technical foundation. Documents must be stored correctly, resource-intensive processes must not block users, results need to persist, components must communicate in a controlled way, and permissions must be managed without exposing unnecessary credentials.

This is where the cloud architecture comes into play.

In this solution, the functional workflow is implemented on AWS through a combination of containers, managed services, serverless processing, asynchronous messaging, a relational database, and generative AI services.

I will not go into the internal cloud networking configuration, Terraform, Kubernetes, or every AWS service involved. The goal here is different: to understand the workflow, the role of each component, and how the architecture enables AI to transform scattered documents into useful information for professional review.

From there, the architecture can be understood as a technical chain of responsibilities serving the validation process.

The user interacts with a web application to create files, upload documents, and review results. React and Nginx power the frontend, while FastAPI running on EKS orchestrates the backend workflow.

When a document is uploaded, the backend stores it in Amazon S3, registers the job in PostgreSQL on Amazon RDS, and publishes an event to Amazon SQS. AWS Lambda consumes the event and performs the analysis in the background, ensuring the user is not blocked.

Once Lambda retrieves the document from S3, the most distinctive part of the system begins: transforming a file into useful information. To achieve this, the solution separates two responsibilities. The first is content extraction; the second is content interpretation.

Amazon Textract handles extraction. Its role is to obtain text and structure from documents that may arrive in different formats: PDFs, images, forms, or scanned documents. In other words, it transforms visual or semi-structured files into processable content.

But reading the document is not enough. In a validation process, it is not only important to know what the document says, but also what it means within the context of the case file.

This is where Amazon Bedrock comes in as the generative intelligence layer. Based on the extracted content, it helps classify document types, locate relevant fields, normalize information, detect potential inconsistencies, and generate reviewable warnings.

The concept can be summarized as follows:

• Textract transforms documents into content. Bedrock transforms content into context.
• Textract answers a technical question: What text and structure exist in this document?
• Bedrock helps answer business questions: What type of document is this? What relevant information does it contain? Is anything missing? Are there inconsistencies? What should a person review?

In this way, AI does not act as an absolute truth or a final judgment. It acts as an assistance layer that prepares the case file so the responsible professional can review it more effectively, more quickly, and with greater context.

What does this solution really deliver?

Beyond the technologies involved, the value of the project lies in changing the way people work with documentation:

• Reduces repetitive manual review.
• Enables earlier detection of missing documents and inconsistencies.
• Improves case-file traceability.
• Separates document upload from resource-intensive processing.
• Allows professionals to review issues instead of navigating disorganized folders.
• Turns AI into an assistance layer rather than a black-box decision engine.

The benefit is not only saving time. It is improving the starting point from which people work.

Project source code

The source code is available on GitHub. The repository contains the complete implementation of the solution: frontend, backend, asynchronous processing, AI integration, and cloud architecture.

Conclusion: less paperwork, more judgment

The implemented solution demonstrates a simple idea: AI creates the most value when it stops being an isolated demonstration and becomes part of a real process.

In this case, artificial intelligence is not used to replace professionals, but to prepare the work: extracting information, classifying documents, identifying warnings, and transforming scattered files into a structured case file.

The cloud architecture supports the workflow. Textract extracts the content. Bedrock interprets the information. But the final decision remains where it belongs: with the person who understands the context, and that is the interesting balance.

This is not about automating for the sake of automation or delegating sensitive decisions to a model. It is about reducing noise, eliminating repetitive work, and allowing professionals to spend more time reviewing what truly matters.

AI is not coming to take your job away just yet. However, if it is properly designed, it can certainly take a lot of paperwork off your hands. And perhaps that is the real short-term impact of AI in many organizations: not the sudden replacement of entire professions, but the elimination of repetitive work that prevents professionals from delivering greater value.

This article starts from an important premise. AI brings us tremendous benefits and has become an indispensable tool, not only for software developers but also for other technical roles, including QA professionals like myself.

By now, there are countless articles discussing the advantages of using AI. However, I find it much harder to come across content that addresses some of the issues that are increasingly emerging due to a “less-than-conscious” use of this technology.

Apparent Productivity vs. Real Quality

AI has multiplied our ability to generate code and deliver features at a speed that would have seemed impossible just a few years ago. In most cases, that is undeniably a positive development.

The problem arises when we start measuring productivity based on the number of closed tickets, commits, automated tests, or even AI prompts executed without considering the quality of the output.

Speed has increased, but that does not necessarily mean quality has improved as well, or even remained at the same level.

Sometimes we rush, even when nobody is explicitly asking us to. If Real Betis could wait six months for Isco Alarcón to recover from injury, surely a software feature can be delivered two days later.

Just as a football player can relapse if they return before fully recovering, code that is delivered prematurely will likely require rework if it has not received the necessary attention throughout all development phases.

In fact, many projects are beginning to experience something concerning. More issues are being detected in later stages, regressions are increasing, and maintenance is becoming more complex, even though it appears that teams are "moving faster."

The Problem and Its Possible Causes

Although this article reflects my personal opinion, naturally shaped by my own experiences, I must admit that my motivation for writing it comes from conversations with several colleagues in the industry.

After speaking with them, we all identified a common issue that, to a greater or lesser extent, was affecting our projects:

The number of bugs has increased significantly since AI entered our lives.

I do not want anyone to misunderstand me. This is by no means a criticism of AI. We are simply capable of producing much more code in much less time, and not only the positive aspects get amplified.

That is why, as I mentioned earlier, I want to make one thing clear:

The problem is not AI. The problem is how we are using it in some cases.

Requirements Definition

Requirements are the foundation of every software project. They were important before, and they are even more important now.

Having well-defined requirements has always been necessary, although it is something that still does not happen as often as we would like. This is not a new problem. Naturally, neither humans nor AI can perform miracles and deliver software without a clear understanding of what is actually needed.

AI has one major characteristic: it dramatically amplifies the quality of the information it receives. When requirements are clear and well defined, AI can become an incredible asset:

• It accelerates development.
• It generates useful and maintainable structures.
• It proposes valid solutions.
• It significantly reduces repetitive work.

However, when requirements are ambiguous, incomplete, or constantly changing, the effect can be the exact opposite.

That opposite effect is becoming increasingly noticeable. Generally speaking, we have not improved the quality of our requirements, yet we are delivering a greater volume of AI-generated code. The result is predictable: a considerable increase in the number of bugs over recent months and years.

The Deprofessionalization of Software Quality

More and more frequently, test automation is being delegated to people whose primary expertise is not quality engineering. This often happens under the assumption that "anyone can automate tests."

Personally, I believe there is an important confusion here between knowing how to use a tool such as Cypress or Playwright and truly understanding how to ensure software quality.

Automation is not simply about generating and executing automated tests. The truly difficult part lies in making decisions such as:

• What is actually worth testing.
• What risks exist.
• What impact each change may have.
• Which scenarios are critical.

This is where the expertise of quality specialists remains essential.

AI can help tremendously when generating tests or even entire test suites much faster than a human could. However, that does not guarantee that those tests are useful, meaningful, or strategically valuable. Just like application code, tests must be analyzed and understood.

In fact, a new risk is already emerging. Many teams are developing a false sense of coverage and security. They see plenty of tests, extensive automation, and green pipelines, but in reality there is little meaningful validation of critical business behavior.

Ultimately, this leads back to the same issue that should already sound familiar:

Bugs are increasing because many automated tests are failing to fulfill their purpose when validating new developments and preventing regressions.

Conscious Development

Earlier, I said that requirements are the foundation of every software project, but I must admit that is not entirely true.

For me, people are and always will be the true foundation.

One of the biggest risks we are starting to see is how some people’s relationship with the code they produce is changing.

A conscious developer (fortunately, most are) is not simply someone who manages to make a feature "work." It is someone who takes the time to understand the requirement, challenge it when necessary, analyze impacts, think about alternative scenarios, and care deeply about the final quality of the software being delivered.

AI dramatically accelerates code generation, but developers remain responsible for the code produced. That means it is equally important that they analyze it, understand it, and test it before delivery.

Unfortunately, we are increasingly seeing situations where AI-generated code is delivered without being properly analyzed, understood, or tested, and even cases where an AI-generated pull request is approved without sufficient review.

In the long term, this can create several problems:

• Poorly maintainable code.
• Developers who become technically stagnant.
• Developers who no longer fully understand their own applications, either functionally or technically.

My experience tells me that developers who were engaged before AI remain engaged today, while those who were not engaged before simply have their shortcomings exposed more clearly because they are now producing significantly more code.

AI can help us become dramatically more productive, but it should never replace something fundamental: technical responsibility for what we deliver.

What Can We Do?

AI is here to stay, and who knows how far it will go. It would be absurd to reject all the value it brings.

The goal should not be to use it less, but to use it better. Generating code has never been easier, and we should embrace that opportunity.

Regardless of our role, I believe many of the solutions are common to everyone, and they all share one thing: the passion and professionalism with which we approach our work.

We must continue insisting on high-quality requirements, and if they are not provided, we should help define them, because no one understands an application better than the people who build it.

We must also continue emphasizing the importance of assigning each task to the appropriate specialist, while clearly explaining the real consequences of failing to do so.

Finally and perhaps most importantly we must maintain genuine involvement and enthusiasm throughout every phase of the product lifecycle, without forgetting that AI should be a support tool, not a replacement for our commitment and engagement.

“The real problem is not whether machines think, but whether men do.” — B. F. Skinner.

The way text is written and structured can make information easier or harder to access. Accessible content benefits everyone, but it is especially important for people who use screen readers, have reading difficulties, attention-related challenges, low vision, or any other permanent or temporary limitation that affects how they interact with the web.

In addition, many accessibility practices also improve the overall reading experience: they make content clearer and easier to understand for any user.

That is why, in today's article, I want to share five best practices you can follow to improve your writing and make your content much more accessible. It is not just about writing well—it is about writing for everyone.

1 Organize Content with Clear Headings

Headings are essential for structuring an article. They not only help visually divide content, but also allow users to quickly understand what each section is about.

People who use screen readers often navigate a page by jumping between headings, so headings should accurately describe the content that follows.

For example, a heading such as "Important Information" is too generic. By contrast, a heading like "How to Write Alternative Text for Images" immediately communicates the topic of the section.

It is also important to maintain a logical and consistent structure, as a well-organized article makes reading easier and reduces the effort required to find information.

In addition, headings should follow a hierarchy. This means content should follow a clear structural order: there should be a single H1 representing the main topic of the page, followed by H2s for major sections, H3s for subsections, and so on.

The proper use of headings is related to Success Criterion 1.3.1 "Info and Relationships", which states that the structure and organization of content must be programmatically identifiable, for example through titles and hierarchical headings.

2 Add Useful Alternative Text to Images

Alternative text, also known as alt text, allows us to describe images for people who cannot see them and rely on screen readers.

How to Write Good Alternative Text

The best way to know whether your alternative text is effective is to ask yourself: "If I were reading this article to someone over the phone, how would I describe this image?"

• Poor: "Image of a dog."
• Good: "A Golden Retriever running across the grass with a ball in its mouth."

Images are often used to illustrate or reinforce the main message of the text. Therefore, alternative text should not simply describe what appears in the image—it should communicate the message the image is intended to convey.

Do not start descriptions with phrases such as "Image of..." or "Photograph of...". Screen readers already announce that the element is an image, so it is better to get straight to the point.

When Should You Add Alternative Text?

Not every image requires a description. Knowing when not to use alt text is just as important:

• Informative images: charts, photographs of people speaking, contact icons (e.g., an envelope representing email), and similar elements require alternative text.
• Decorative images: divider lines, abstract backgrounds, or images used solely for visual decoration do not require alternative text and should use an empty alt attribute (alt=""), indicating that screen readers should ignore them.

Important: if the image already includes a caption that communicates exactly the same information, the alternative text can be shorter or even treated as decorative to avoid repeating information for users.

The correct use of alternative text for images is related to Success Criterion 1.1.1 "Non-text Content", which states that all non-text content (such as images) must have a text alternative that serves the same purpose or conveys the same information.

3 Use Descriptive Links

Many people who use assistive technologies navigate using lists of links automatically extracted from a page. Therefore, links should make sense on their own, even when read out of context.

A good link should stand on its own. Users should know exactly what they will find when they activate it, without having to read surrounding text.

• Poor: "To learn about our offers, click here." or "To read the full article, click this link."
• Good: "Explore our seasonal offers." or "Read the full accessibility article."

Avoid generic phrases such as "Read more," "View content," or "Learn more." If several links on a page use the same text, screen reader users will hear a repetitive and confusing list of identical options.

For a link to be truly useful, it is not enough for the destination to be clear—it should also communicate what type of interaction will occur next. These three recommendations can help:

• Set expectations: if the link starts a download or opens a specific format, include that information. For example: "Download the budget as a PDF" or "Watch the event video on YouTube."
• Avoid raw URLs: do not paste web addresses directly (e.g., https://www.example.com/downloads/final-file-01.pdf). Screen readers will read every letter and symbol aloud, which can be frustrating. Instead, use: "Download the style guide in PDF format."
• New windows: if the link opens in a new tab or window, it is good practice to indicate this briefly, for example: "Open transparency portal (opens in a new window)."

If you use an icon to communicate this, make sure it is also accessible to screen readers.

In addition to improving accessibility, descriptive links also enhance the overall navigation experience.

The use of descriptive links is related to Success Criterion 2.4.4 "Link Purpose (In Context)", which states that the purpose of each link must be identifiable from the link text itself. This allows users to understand where a link will take them and decide whether they want to activate it.

4 Be Careful with Emojis and Symbols

Emojis can add personality and warmth to content, but overusing them can negatively affect navigation and comprehension for people who use screen readers.

Screen readers translate every emoji into words, so what appears visually as decoration becomes an audible interruption for assistive technology users.

• Text: "Hello everyone! 👋✨ We are very excited 🤩 to announce..."
• Screen reader output: "Hello everyone! Waving hand, sparkles. We are very excited star-struck face to announce..."

When too many emojis are used in succession, the main message becomes buried beneath a list of image descriptions, making the text harder to understand.

The best approach is not to rely on symbols or emojis to communicate important information, and if you use them, do so sparingly.

5 Avoid Content That May Trigger Photosensitive Seizures

Certain types of visual content, such as flashing lights or rapid blinking effects, can affect people with photosensitive epilepsy and other seizure disorders.

The Three-Flashes Rule

For content to be considered safe, it should not flash more than three times per second. If a visual element exceeds this frequency, it could potentially trigger a seizure.

• Poor: an advertising banner with rapidly flashing neon colors designed to attract attention.
• Good: a smooth, slow animation without abrupt brightness changes or extreme contrasts.

How to Create Safe Visual Content

To ensure your website is safe for everyone, follow these guidelines:

• Avoid autoplay for flashing videos. Never automatically play videos containing strobe lights or flashing effects.
• Allow animations to be paused. Any element that moves or flashes for more than five seconds should be pausable or stoppable by the user.
• Be careful with geometric patterns. High-contrast moving stripe patterns can also cause discomfort. Smooth transitions are generally a safer option.

Compliance with these recommendations is related to Success Criterion 2.3.1 "Three Flashes or Below Threshold", which states that web content must not be designed in ways known to cause seizures. This ensures that accessing information does not put users at physical risk.

This section is also related to Success Criterion 2.2.2 "Pause, Stop, Hide". This criterion requires that for any content that moves, flashes, or updates automatically (such as carousels or GIFs), users must always have control to pause or stop it. This prevents constant motion from becoming a distraction or a risk for people with attention disorders or sensory sensitivities.

Conclusion

To be honest, even if you read this entire article, you will probably overlook some details from time to time—especially if you write content every day. But what really matters is the intention: keeping these guidelines in mind is the first step toward ensuring your content reaches everyone.

Accessibility is not a goal that can be achieved overnight; it is a continuous process and a shared responsibility. It is not about doing everything perfectly from the start, but about choosing to improve every day so that, eventually, you get there.

Why Does AI Return Noise Instead of Solutions?

We are transitioning from deterministic programming to the probabilistic environments of large language models, and this completely changes the way we approach many tasks.

Interacting with this technology as if there were a human on the other side interpreting our intent is the fastest path to failure. When we provide vague instructions, the system returns noise and empty answers that deliver no real business value. This lack of precision is often unfairly labeled as an incomprehensible "black box."

To avoid this operational nightmare, we must start treating our text requests as pieces of software code—something similar to pseudocode. In this post, we will explain how to reduce the deviations and hallucinations we face when working with any language model.

Why Do We Need to Break Down and Delimit Context?

Plain, unstructured text often causes the model to lose focus and mix instructions with raw data. This jumble of information undermines the reliability of the final result, especially when using medium-sized or small models. The most effective way to address this issue is modular segmentation.

Leading companies strongly recommend separating context, rules, and input data using explicit delimiters. Using XML tags or simple Markdown markers helps the model process each block as clearly as possible. By creating a clear contract between inputs and outputs, we limit the margin of error.

How Do We Control Style and Ensure Integration?

Beyond structuring information, we need to govern the way the system communicates. Based on effective design patterns, assigning a specific role or persona forces the AI to activate a particular subset of its training. Giving it an expert identity transforms a generic response into a deeper analysis tailored to our domain.

It is not enough to ask it to act as a developer or consultant. We should also define the level of formality, perspective, and expected level of detail. If we request a conversational tone without corporate jargon, the content becomes far more digestible.

Likewise, if we want to connect the response with an external application, enforcing a structured output format is non-negotiable. Requiring rigid formats such as JSON ensures interoperability with other components of our software. Models respond far better to positive, imperative instructions that specify exactly what they should do rather than long lists of prohibitions.

What Are Examples Really Useful For?

Expecting a model to solve complex problems correctly on the first attempt and without references is often too optimistic in enterprise environments. Providing a small set of input/output examples is the fastest way to calibrate system behavior without touching a single line of code. By explicitly showing what we consider correct and incorrect, we define the scope of the task.

This strategy standardizes the output format and reduces unpredictable responses. You will find that this guided context acts as a highly effective safety net for classification and data extraction tasks.

Breaking Down the Anatomy of a Good Prompt

Below is what I consider an ideal baseline prompt structure:

### ROLE ### (role): Don't let the AI guess how it should communicate. Assign it a role (e.g., "You are an expert Python developer" or "You are a creative advertising copywriter"). This automatically adjusts the tone and vocabulary it will use.

### CONTEXT ### (context): The AI cannot read your mind. Explain the "why" and the "for whom" (e.g., "I am preparing an investor presentation for a new mobile app"). This provides the context required to avoid generic answers.

### TASK ### (task): Place your request here in a direct manner. It should be expressed as an action verb (write, summarize, analyze, translate). There is no need to say "please." Doing so only increases token consumption.

### RULES & CONSTRAINTS ### (rules and constraints): This is where you define boundaries for creativity and reduce the risk of hallucinations. Specify exactly which rules must be followed (e.g., "Do not use technical jargon" or "The text must not exceed 200 words").

### CHAIN OF THOUGHT & SELF-CHECK ### (reasoning and self-review): It is often useful to instruct the AI to think step by step and review its answer before delivering it. This reduces logical errors, especially in tasks that require more advanced reasoning.

### FEW-SHOT EXAMPLES ### (examples): The best way to teach is through real input/output examples. This helps the model calibrate the final result.

### INPUT ### (input): The raw data, text to analyze, or specific question.

### OUTPUT FORMAT ### (output format): Do you want a table? JSON? Markdown?

Conclusions

Mastering basic prompting techniques is the prerequisite for scaling any generative AI product. With these best practices as a foundation, we can move on to more advanced architectures such as agents, orchestration frameworks, and recursive optimization techniques.

References

• Promptware Engineering: Software Engineering for Prompt-Enabled Systems
• The Architecture of Cognitive Steering
• Advanced Prompt Engineering
• Top 10 Prompting Techniques That Instantly Improve AI Output in 2025

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.