Ditching free-form text generation to focus on probabilistic determinism changes the rules of the game completely in enterprise architecture. That's exactly the premise behind Jev, the new "System One" model TypeSafe AI unveiled on September 15, 2026, an AI that completely abandons text writing to focus on evaluating information in parallel and returning strictly typed decisions in milliseconds.

If you already know what an LLM is and you're tired of using an expensive reasoning engine for conditional-logic tasks, this is the context you need to understand how to optimize your automations.

Why do we keep forcing LLMs to structure data?

Asking a generative network to return a structured object is like using a cannon to kill a fly. Autoregressive architectures calculate the next token based on a sequential history of prior words. When we try to automate routing support requests into our database, we usually instruct the model with endless rules, asking it to respect JSON quotation marks and not add noise. We end up building very fragile parsers that try to interpret completely unpredictable algorithmic responses.

When the model fails to close a tag, the system falls into an endless retry loop. Reacting to this kind of formatting failure breaks any transactional flow. We're talking about inference latencies that scale from three seconds all the way up to three hundred seconds of waiting. No commercial platform would accept keeping a user waiting half a minute to execute simple conditional logic. This approach turns the company's analytics layer into a black box.

When should you use Jev, and when your classic LLM?

Kahneman's psychological theory defines fast, intuitive thinking versus slow, deliberate reasoning. TypeSafe AI's Jev model brings this concept to life by eliminating the neural capacity to generate language. This architecture evaluates input states against a static schema using parallel sampling. Understanding this taxonomic split lets you design much more agile composite systems.

Let's look at exactly where Jev shines and where it falls short compared to a traditional generative engine.

• For mass ticket routing or triage, Jev is the clear winner. Corporate support systems receive messy information where text-analysis teams fail spectacularly and prove far too slow. Send a message about a duplicate charge and ask the algorithm to assess urgency, and it returns an exact typed classification in milliseconds. Using a frontier generative model here would be a waste of compute budget.
• Robotic interface control (RPA) and web agents require instant, iterative decisions. Community experiments integrating Jev into autonomous browsing projects show full flight-booking cycles in around seven seconds. Median operational latency drops to the 150-millisecond range, enabling reactive loops where a classic model would cause the system to collapse.
• Big Data processing demands this kind of architecture for strictly economic reasons. Using a traditional autoregressive network for this task would require hours of processing and the subsequent review of thousands of JSON records prone to typographical errors.

There are scenarios where deploying Jev makes no sense at all, because of its own structural blindness.

• If you need to write a summary, take part in a conversation thread, or generate source code, this system is computationally useless. It lacks the iterative decoding phase needed to articulate text. Here, you do need a generative model, and you need to let it reason.
• Regulated industries that demand analytical explainability face a similar roadblock. When you deny an insurance policy or reject a credit application, an auditing body will demand traceable reasoning written in natural language. Jev returns mathematical confidence percentages without arguing why it made its choice. To comply with strict financial transparency rules, you'll inevitably need an LLM's reasoning.

How does this change the way we design infrastructure?

Leaving behind the operational hell of these integrations means rethinking how we design our infrastructure. Instead of putting so much weight and effort into prompting, you'll now need to parameterize strict decision schemas.

The backend team no longer interacts with a character generator. Operating under a parallel-sampling model means configuring binary evaluations that the engine resolves without emitting a single word. Declaring the schema gives us technical determinism that takes costly syntactic-validation routines for text strings out of production.

That said, you do need to account for certain limitations in the original design. The context memory budget caps out at 64,000 tokens per call, and the architecture doesn't natively accept images.

Conclusions

Holding on to monolithic architectures that try to solve every type of use case seriously hurts commercial competitiveness. We've been forcing LLMs to behave like simple routers while paying unsustainable bills.

Bringing architectures like Jev's into our pipeline helps cut these costs, delivers more accurate answers, practically eliminates hallucinations, and shortens deployment times.

References

• Jev System One Model by TypeSafe - AY Automate
• A deep dive into Jev, TypeSafe's System One model - Flavio Copes
• What Is Jev? A Guide to TypeSafe AI's System One Model - LangChain
• TypeSafe AI's Jev: What "System One Models" Actually Are

Among them is a generation that doesn't remember a world without a smartphone: they order dinner from an app, watch the series a platform recommends before they've even searched for it, and have never set foot in a bank branch.

For them, a service that works on its own, remembers who they are, and doesn't make them repeat the same process three times isn't a luxury, it's the baseline.

The competition is no longer the university next door, it's platforms like Amazon or Netflix

For years, a university was compared, experience-wise, with other universities. That comparison is over. Today, students measure their university by the same yardstick they use for Netflix, Amazon, or their banking app: services that know them, anticipate what they need, and solve things without friction.

It's an unfair comparison (nobody expects a university to run like a streaming company), but it's the one students make, and the one that counts. And when the digital experience doesn't measure up, students conclude the university doesn't work. Sometimes they say so where it hurts most: in the satisfaction survey, or in a chat with the friend who's deciding where to enroll next year.

That's why digital experience has stopped being an internal systems matter and become a matter of attracting and retaining students.

Four systems for a single process

Let's follow the student. To check a grade, pay a fee, or request a certificate, they go from the academic management system to the virtual classroom, from there to the e-government portal, and sometimes to the CRM that wrote to them back when they were still a prospect.

Each with its own address, its own look, and its own login. Each asking them who they are, as if they hadn't just told the previous one. Nobody designed it this way — each system was bought at the time to solve a specific problem, and it does solve it.

What wasn't designed was how they would talk to each other. And the one who ends up acting as the link between them all is the student.

From the inside, however, it doesn't always look that way. Three out of four universities consider their level of digital transformation adequate and on par with other sectors (Fundación CYD, 2023).

And it's not for lack of effort: a lot has been invested, but mostly in what's visible (connectivity, equipped classrooms, screens...). As the Higher Education Spaces 2025 report sums it up, infrastructure has advanced, but the model hasn't been rethought.

Why a new app won't fix this

When the experience fails, the natural response is a better app. It makes sense: the app is what people see and what takes the complaints. But the app is just the experience layer, and it can't stand on its own.

If underneath, the academic system, the virtual classroom, the CRM, and the e-government portal don't share data or identity, the new app gathers them on one screen without truly joining them: often, each service shows up as another system's window embedded inside the app.

Students notice right away: the look changes, but they still have to identify themselves again, still can't find their things in the same place, and still get bounced out to another system halfway through a process.

You can redesign the screen as many times as you like, but if the process still runs through four systems that don't know each other, the experience will stay broken. It's the difference between repainting the facade and fixing the wiring behind the wall.

Five signs the problem isn't on the screen

These five signs aren't about architecture or technology: they're about what happens in a normal school year. If you recognize several, the problem isn't on the surface:

1. Students type the same piece of data more than once during the year, in different systems, because some don't know what others have already stored.
2. A routine process forces them to leave the app and log into somewhere else, with a different login, just to finish it.
3. Changing anything on the platform depends on a third party: on their timelines, their priorities, and their budget, not yours.
4. Nobody has the full picture of a student on a single screen: admissions, the registrar's office, and the teaching staff each see different pieces of the same person.
5. The last digital improvement was an app or a redesign, not a change in how the systems connect underneath.

None of these signs, on its own, is serious. The problem is when they pile up, because then they stop being isolated incidents and become the same symptom repeating: the gap between what a student takes for granted and what they actually find.

The urgency isn't about who's arriving today

So when they arrive at university, they want to check their schedule, apply for a scholarship, book a study room… and for the process to be simple, fast, and effective.

Those born from 2013 onward (so-called Generation Alpha) will start arriving at university around 2031. For Gen Z, a fragmented experience is a letdown; for Alpha, who won't have known anything else, it will be a flaw.

Five years may seem like a long time. It isn't for this decision: an academic platform isn't swapped out every two years. It's chosen, implemented, and carried for a decade.

The ecosystem decision a university makes this year is the one that will greet those students. Today the question isn't how to serve the student who's in the classroom right now: it's how to serve the one who's still in primary school.

In the same spirit, as a representative of the upper end of the demographic curve, alongside metaphors, I think it's worth backing up the argument with numbers.

Only 11% of consumers in the United States are willing to let AI decide a purchase for them, even in low-risk categories like personal care or household supplies, according to a Gartner survey published in May 2026. That figure demolishes the narrative that's taken hold in most leadership committees: that the consumer is already ready for autonomous purchasing. They're not. And yet, 58% of customers prefer a generative AI system to recommend products to them, according to Capgemini.

The contradiction isn't a measurement error — it's a clue to how each party involved sees the future, and that's an insight in itself. Shoppers aren't rejecting AI, they're rejecting losing control while using it.

54% of people who've used AI to shop have had to double-check the information the system gave them, and 62% consider that information a waste of time, according to the same Gartner study. This isn't an adoption problem, it's a design problem being attacked from different angles. Platforms are tackling it from availability and accuracy, while managing the actual experience falls on those of us who want to build differentiated value with it.

The symptom: scattered agents, broken experience

Over the last three years, most ecommerce businesses have followed the same script: a chatbot in customer service, a recommendation engine on the catalog, a dynamic pricing system at checkout, maybe a personalization agent in email.

Each piece works fine on its own. Each vendor can show off its own success story. The problem shows up when the customer moves between those pieces and discovers that none of them knows what the other just did — and this doesn't just break the experience, it can also be a source of problems at multiple levels whenever actions get automated across the whole martech stack.

To put it simply with an example: as a customer, I might have just closed a car insurance claim successfully with the tow truck, while at the same time considering canceling my policy for other reasons — and that combination could make me furious if I then get hit with the wrong upsell campaign. Response-time indicators, handling costs, or NPS can all look great in isolation and still completely miss why the problem exists.

Back to my number obsession: only 14% of the more than 20,000 consumers surveyed across 26 countries say they're satisfied with their online shopping experience, according to the IBM Institute for Business Value. Given how much technology has been rolled out over the last decade, that number should embarrass anyone of us sitting on this side of the equation (understanding, designing, implementing).

There's also a structural threat that few leadership committees are prioritizing, that we SEOs haven't managed to communicate properly, and that Gartner has been warning about for a while: back in 2024 it forecast a 25% drop in traditional search volume by 2026, displaced by AI chatbots. If the traffic that reaches you today from Google starts arriving (or not arriving) through a conversational assistant answering on the user's behalf, the question is no longer how to rank a page. It's how to get an external agent to understand, cite, and recommend your catalog. That fight is won with structured data, context, and cross-channel consistency. Not with one more chatbot.

The marketing name for this is zero-click search; the precise business term for it is "I'm losing visibility into my customer's context" (to put it politely).

The thesis: what's missing is a layer that perceives, interprets, and learns

The mistake isn't having too few AI agents — it's having them disconnected. Each agent perceives one slice of the customer (what they buy, what they ask, what they abandon in the cart), but none of them builds a combined picture. And without that combined picture, no real interpretation is possible: recommendations get generated off a fragment of behavior, not the full journey.

The cost of not having it is already measured, and not just by consulting firms: 70.22% is the average cart-abandonment rate in ecommerce, according to the Baymard Institute, which aggregates 50 independent studies published between 2006 and 2025. It's not a new problem, nor one exclusive to AI, but it's exactly the symptom a well-designed cognitive layer should reduce: the customer doesn't abandon because technology is missing, they abandon because nobody connects what every piece of that technology already knows about them.

What's missing is shared context — not one more agent, but the logic that connects the ones that already exist. Picture that customer from the car-claim example earlier: first, someone perceives that they just closed an incident with the tow truck, and, in parallel, that they've spent weeks looking at the cancellation policy. Then, someone interprets those two signals together, not separately, and understands this isn't the moment for an upsell. The system feeds that decision back: if the customer responds well to a different message, it remembers that for next time. And all of that turns into augmented experience at the one moment the customer actually sees: a message that, finally, makes sense given what's happening to them.

That's what, in the physical world, we'd call "breaking out of silos to work toward a shared goal." Here, it's four functions feeding into each other: perception, smart interpretation, feedback, and augmented experience. Without this layer, every agent keeps optimizing its own metric in isolation. With it, agents stop competing for the customer's attention and start building on what the previous one already learned.

This augmented experience no longer lives inside a fixed interface. For thirty years, ecommerce was a screen the product team designed once, and the customer always navigated the same way. That's dissolving: when the purchase happens inside ChatGPT, inside a Copilot assistant, or inside whatever interface an agent controls (what ECDB calls the Interface-First model), the brand no longer has a page to design — it has a conversation to win, different every time, assembled in real time based on whatever that agent decides to show. It's what design circles are starting to call liquid interfaces: there's no fixed layout to memorize anymore, there's a surface that reassembles itself with every interaction based on context, the agent, and the customer's moment.

And this is where Fantasia's broom comes back. If the interface is no longer fixed, and the logic governing it doesn't exist either, every agent not only acts on its own, it also presents itself on its own, with its own judgment about what's relevant to show the customer in that instant. The cognitive layer is optional in a world of fixed interfaces, where the error shows up on a dashboard. It's essential in a world of liquid interfaces, where the error shows up (or doesn't) inside a conversation nobody else is watching.

The point most people skip: governance, not total autonomy

This is where a lot of AI projects in ecommerce aim at the wrong target. The default ambition tends to be "more autonomous," as if autonomy itself were the sign of maturity. The same survey cited at the start disproves that: 72% of users say generative AI shows up in their experience without them having asked for it. That doesn't build trust, it builds rejection.

Kate Muhl's quote sums it up better than any internal report could: consumers aren't looking to hand purchase decisions over to AI, they're looking for AI to help them find better information while keeping final control themselves. That has a direct translation for any ecommerce leadership team: the goal isn't to automate more, it's to decide precisely which parts of the process can be coordinated between systems, which ones need explicit governance (rules, limits, human approval), and which ones can run with real autonomy because the risk of error is low and the cost of review is high.

That distinction (coordinated, governed, autonomous) isn't a technical nuance — it's the difference between a system a director can defend in front of a risk committee and one they can't. It's also why most AI pilots in ecommerce stall out: they're designed to maximize autonomy instead of maximizing trust, and the consumer (and the internal team itself) ends up switching off whatever they don't understand or control.

The market is already moving

Agentic commerce is set to move $8 billion in 2026 and is projected to reach $3.5 trillion by 2031 — a 43.24% growth rate over five years, according to ECDB/Juniper Research. This isn't an abstract forecast: traffic that already arrives from ChatGPT converts at 11.4%, 54% above the average for every other source, direct traffic included. And the infrastructure to capture that value is being built around an aggressive pricing strategy: ChatGPT's referral fees sit well below the take rates Amazon (15.8%), Walmart (15.0%), or eBay (10.9%) charge today — the same "come in cheaper, grab share" play Amazon used to eat traditional retail alive twenty years ago, now aimed at who controls the transaction, not just the catalog.

And there's no irony to spare here: the same firm telling you only 15% of retailers use AI to recommend products is the one rating the 19 vendors already selling it to them.

Gartner's Magic Quadrant for Digital Commerce, published on November 3, 2025, evaluates 19 vendors (Adobe, Salesforce, SAP, Shopify, commercetools, among others) and confirms that investment in AI capabilities and agentic commerce is already part of the roadmap for every major platform in the category. This isn't an early-adopter bet. It's the direction the entire category is moving in.

And the business case for moving now isn't new, it's just gotten more urgent: companies that get personalization right generate 40% more revenue from those activities than the industry average, according to McKinsey — a 2021 figure none of the platforms Gartner evaluated has managed to overturn in four years, precisely because the underlying problem (connecting signals, not stacking up tools) hasn't changed.

Even so, the gap between what the customer expects and what the retailer delivers remains enormous: only 15% of retailers use AI for product recommendations, and only 10% have automated inventory management with AI, according to Quid's State of AI in Ecommerce Report (2025), against 58% of customers who already prefer that kind of recommendation. That gap between demand and delivery capability is, right now, the cheapest competitive advantage in ecommerce. You don't need to convince the customer of anything — you need to build what they're already asking for.

What this means for whoever's in charge, not whoever's implementing

No ecommerce director needs to understand the technical architecture of a conversational agent. They do need to ask themselves three questions before signing off on the next AI project:

• Does this agent share what it perceives with the rest of the systems, or does it just add another silo with an "intelligent" label on it?
• Do we know, precisely, which decisions the system can act on alone and which ones need human governance — or are we figuring that out as we go?
• Does the customer notice a more coherent experience, or do they just notice there are now more chat windows?

If the answer to any of the three is "we don't know," the project isn't ready to scale, no matter how good the demo looks.

The cognitive layer isn't a fancier AI layer, it's the one that decides how the ones you already have coexist, and the one that turns every new agent into an improvement to the whole system instead of one more tool someone has to check by hand.

To wrap up, because you already know I'm a sucker for numbers: this article draws on twelve different sources, and more than a few years of personal bias, which is the polite way of saying experience.

I split them into two camps: the consultancies (Gartner, McKinsey, IBM) see moderate growth and a challenge that's mostly emotional — trust — while the product platforms see explosive growth and a challenge that's mostly technical. Neither side talks much about the conflict the other one clearly sees. And both agree, without ever having compared notes, on the same vanishing point: control, trust, and verified data as the lever that actually matters.

Two ways of seeing the world, one point of connection we believe in.

At Pleg, we're designing exactly this layer for several ecommerce teams who already have agents deployed but no logic coordinating them. If you want to see how we're building it, or just compare notes on where your organization stands on this axis of perception, governance, and autonomy, let's talk.

Thanks to Generative AI, CRO is evolving from traditional A/B testing toward real-time adaptive contextual personalization. AI no longer just assists with content creation — it calibrates the interface based on who's browsing and when. But the real strategic challenge has shifted sides: how do you personalize at scale without tanking latency, hurting SEO, or fragmenting brand identity?

Below, we break down GenAI's impact on every layer of the optimization workflow, and in upcoming posts we'll cover best practices for Safe-UX with Generative AI and the profile of a CRO Specialist working with AI, plus FAQs.

The evolution of CRO: from static A/B testing to hyper-personalization

The limit of traditional A/B testing: "one-size-fits-all" optimization is no longer enough

For years, the reigning methodology in Conversion Rate Optimization (CRO) has been the classic A/B test, where we split traffic 50/50 between a control version and a variant. After gathering enough data volume to reach statistical significance, we declare a single winner.

However, this approach rests on a fundamentally flawed premise: the assumption that a single "winning" design exists capable of satisfying every user equally. The reality of modern web traffic is diverse and unpredictable. We treat the audience as a homogeneous block when, in fact, two users landing on the same page can differ radically in search intent, channel of origin, digital maturity level, and context.

"One-size-fits-all" optimization is hitting a performance ceiling: by applying one fixed variant to the entire audience, we force profiles with opposing needs through the same funnel, losing valuable opportunities within a data-driven CRO strategy for secondary segments.

What changes with Generative AI in the conversion pipeline?

The arrival of Generative AI (GenAI) breaks the bottleneck of the various static A/B testing formats, letting the experimentation cycle scale up to real-time dynamic hyper-personalization.

GenAI doesn't just act as a writing assistant to churn out copy faster — it's an active engine driving this new paradigm of web personalization:

• Contextual variant generation: automatically adapts micro-copy, the tone of the value proposition, and visual elements based on user input signals (search keywords, browsing history, device, or B2B firmographics).
• Adaptive models (Multi-Armed Bandits): instead of waiting weeks with traffic split 50/50, dynamic allocation algorithms continuously evaluate variant performance. If the AI detects that variant C performs better for mobile traffic coming from social media, it redirects that segment to it immediately.

We move from a slow, linear pipeline to a living ecosystem where the interface continuously mutates and optimizes itself in real time.

The main challenge: personalizing in real time without sacrificing brand consistency or technical performance

Implementing Generative AI at the interface layer isn't friction-free. The real challenge of this model isn't the technical ability to generate variants — it's controlling the side effects on user experience and web infrastructure:

• For the UX/Product team: there's a real risk of fragmenting visual and narrative consistency. If AI alters text or design patterns without limits, the brand risks losing its identity, drifting away from its Design System, or, in the worst case, falling into inconsistencies and hallucinations that erode trust.
• For the Technical/Engineering team: modifying content "on the fly" from the browser usually means uncoordinated calls to external models or heavy client-side scripts. This causes the dreaded flicker effect (visual flashing or jumping during load), spiking Cumulative Layout Shift (CLS) and delaying Largest Contentful Paint (LCP). Wrecking Core Web Vitals hurts SEO rankings and destroys conversion itself.

The strategic goal of modern CRO is achieving personalization in milliseconds: applying technical guardrails (Edge/Server-Side architectures) and design guardrails (locked-down Design System components) so AI can alter content safely and transparently to the user.

GenAI in the CRO workflow: 3 layers of impact

Layer 1: mass generation of hypotheses and variants (Copy & UI)

Creating ad-hoc micro-copy based on search intent, traffic source, and user maturity level

In the traditional model, the CRO bottleneck usually wasn't technical implementation, but creative and writing capacity. Designing personalized variants for five different segments meant manually writing dozens of value propositions, calls to action (CTAs), and headlines.

Generative AI transforms this process by acting as a mass, context-based variant generation engine. Industry reports like Gartner's highlight content creation as one of the top use cases for GenAI. By ingesting real-time input parameters (source ad keywords, UTM parameters, device, location, or B2B firmographic data), language models can dynamically generate tailored micro-copy:

• Based on search intent: if a user arrives searching for "cheap accounting software," the headline can emphasize cost savings. If the search is "accounting software to scale my company," the message automatically pivots toward automation and process integration.
• Based on maturity level: a returning visitor who's already read three blog posts doesn't need the same explanatory value proposition as a cold visitor. AI can adjust message complexity and offer type to match the exact stage of the funnel.

This capability isn't limited to text. Integrated with modular design systems, or applied through a practical guide to Multivariate Testing (MVT), AI can select layout variants, adapt images contextually, and even adjust screen information density with no direct human intervention.

Layer 2: dynamic allocation algorithms (Multi-Armed Bandits vs. A/B tests)

How AI redirects traffic in real time toward winning variants, without waiting weeks for statistical significance

One of the biggest drawbacks of conventional A/B testing is the opportunity cost during the testing phase. In a test with a 50/50 traffic split, 50% of visitors keep getting a lower-performing version for however long it takes the experiment to reach statistical significance (often weeks or months).

Bringing AI into the decision infrastructure replaces fixed traffic splitting with reinforcement-learning algorithms known as Multi-Armed Bandits (MAB):

• Continuous traffic evolution: the algorithm initially assigns a small fraction of traffic to each variant. As it gathers real-time conversion data, it dynamically redirects a growing share of users toward the variants performing best for each given profile.
• Lower conversion cost: instead of "wasting" impressions on losing variants for weeks, the system progressively routes traffic toward the most efficient options, maximizing the total number of conversions recorded even during the testing period itself.
• Contextual optimization: while an A/B test tries to determine which variant is best overall, an AI-driven contextual bandit algorithm identifies which variant works best for a specific type of user at a specific moment.

Layer 3: automated qualitative analysis

Synthesizing thousands of survey responses, user feedback entries, and session transcripts into clear friction patterns

Quantitative analysis tells you where users drop off in the funnel, but qualitative analysis explains why. Until now, processing qualitative information was slow and prone to bias: reviewing hundreds of session recordings, reading exit-survey comments, or analyzing user interview transcripts took dozens of hours of manual work.

Generative AI solves this bottleneck by acting as a qualitative analyst at scale, capable of processing huge volumes of unstructured data — even leaning on advanced methodologies like synthetic users in CRO research:

• Real-time friction clustering: models can process thousands of free-text responses (such as intent surveys or checkout feedback) and automatically group them into friction categories (e.g., "uncertainty about shipping costs," "payment method failures," or "unclear warranty terms").
• Sentiment analysis and transcripts: it's possible to analyze customer support transcripts or B2B sales calls at scale to spot recurring doubts or objections that the landing page isn't addressing.
• Automatic hypothesis generation: by cross-referencing these qualitative patterns with quantitative analytics data, AI doesn't just pinpoint the drop-off point — it proposes optimization hypotheses grounded in the exact words and objections users themselves expressed.

Conclusion: CRO shifts from being an event to being a living ecosystem

Bringing Generative AI into the optimization workflow doesn't mean replacing CRO methodology — it means freeing it from its traditional bottlenecks. Moving from rigid A/B testing to dynamic personalization lets you iterate hypotheses at unprecedented speed and eliminate the opportunity cost sitting in unoptimized traffic.

That said, the competitive edge won't go to whoever generates the most AI content variants, but to whoever implements the right brand and technical architecture guardrails. Hyper-personalization only works if the user never perceives the friction: minimal latency via Server-Side/Edge delivery, consistency guaranteed by the Design System, and a strategic vision that puts user experience at the center.

References and bibliography

• CXL. (n.d.). A/B Testing Guide: Beginner to Advanced Methodology.
• Braze. (n.d.). Multi-Armed Bandit vs. A/B Testing: When to Use Which.
• McKinsey & Company. (2023). How generative AI can boost consumer marketing.
• Ideario Digital. (n.d.). Tipos de tests A/B en web: Guía completa.
• Ideario Digital. (n.d.). IA y personalización web: El nuevo paradigma de optimización
• Ideario Digital. (n.d.). Estrategia de CRO y optimización basada en datos
• Persado / Gartner Report. (n.d.). Gartner Identifies AI-Generated Marketing Content as a Top Use Case for Generative AI
• VWO. (n.d.). El algoritmo Multi-Armed Bandit explicado para experimentación web
• Optimizely Support. (n.d.). Run a multi-armed bandit optimization in Feature Experimentation
• Ideario Digital. (n.d.). Usuarios sintéticos en CRO: Investigación con IA
• Ideario Digital. (n.d.). Calculadora Bayesiana para A/B Testing
• Ideario Digital. (n.d.). Guía práctica de Test Multivariante (MVT)

If your supply chain still plans in monthly cycles and signs off decisions in weekly meetings, here’s the bad news: your competitors already make those decisions with AI agents under human oversight. Worse: the data says it works.

Spend on supply chain management software with agentic AI will grow from under €1.8Bn ($2Bn) in 2025 to around €46Bn ($53Bn) in 2030 ^[1], and Gartner predicts that by 2031, 60% of supply chain disruptions will be resolved with little to none human intervention ^[2]. This isn’t a fad. It’s a paradigm shift to autonomous orchestration, combining processes, people and ways of working with AI.

First, let’s bust a myth: automating is not delegating. Automation replaces repetitive tasks; delegation hands over operational decisions (and, increasingly, strategic ones) to systems that can sense, reason and act within defined guardrails.

Traditional plan-review-correct cycles are giving way to near-real-time decision networks run by cognitive agents. In this model, supply chain stops being a cost center and becomes an engine of dynamic resilience: it captures margin in real time by adjusting prices, flows and inventory in volatile markets, instead of documenting the problem three weeks late.

Just another fad? If you’re wondering, here’s why it’s real: 2 in 3 companies plan to make significant progress toward autonomy over the next decade ^[7], and 69% of surveyed operations executives admit that failing to adopt AI will put them at a competitive disadvantage.

The uncomfortable truth: only 28% have a low-touch supply chain today ^[16]. Walk the talk is the next real battleground.

Function by Function: Where Autonomy Already Delivers Value

End-to-end autonomy isn’t something taken for granted. It’s built brick by brick tying every investment to each function’s pain point to address. Here’s what the evidence supports today, function by function, with examples:

• Planning (S&OP, forecasting). Traditional statistical forecasting, as we know it today, is dying: 70% of large organizations will adopt AI-based demand forecasting by 2030, aiming for “touchless forecasting” that removes recurring manual intervention ^[3]. Planning shifts from periodic cycles to continuous demand sensing and daily granular optimization, and product design connects to market signals from day one.
• Procurement and Sourcing. This is where agentic maturity is highest today, precisely in structured, transactional processes (P2P, source-to-pay) ^[15]. Agentic orchestration can free up around 60% of procurement team capacity for strategic work ^[14]: better negotiations, tighter supplier risk management and no more chasing invoices.
• Manufacturing and distribution (IT/OT, warehousing, logistics). Smart factories and hybrid warehouses (robots + people) already deliver measurable results: up to −28.4% operating cost and +21.8% warehouse efficiency in advanced automation deployments ^[8].
• Sales, aftersales and customer service. The emerging frontier is agentic commerce: agents that don’t just handle issues but proactively pick the most profitable, satisfying fulfillment option for each customer. When your customer also buys through an agent, the question changes: you’re no longer designing experiences only for people, but also for the AI agents acting on their behalf ^[13].

The Impact Is Multidimensional: Process, Technology and People

Autonomous tech on broken processes just creates chaos faster. The three lenses don’t change. They’re the three pillars, no exceptions:

• Process redesigned end-to-end to break down silos before agents orchestrate it.
• Technology, where the real differentiator isn’t the control tower but the semantic layer: knowledge graphs that let an agent understand business context, not just correlate numbers.
• People, the most fragile pillar. Here’s the trust paradox: only 27% of organizations trust fully autonomous agents, down from 43% a year ago ^[6]. Yes, you read that right: trust is falling while investment rises. It’s reality catching up with early hype, and it’s healthy if managed well.

Value Levers: What Makes the Business Case

One warning before the table: autonomy without metrics is an act of faith, and acts of faith don’t survive an investment committee.

Each dimension in the table is an agentic improvement lever. Setting direction means turning them into measurable targets, each with a baseline, a target and an owner:

• Pick a few levers you can measure. Cost improvement, inventory reductions, margins enhancement, increase productivity, freed-up capacity, increase resilience, improve sustainability and lower the emissions: that’s the menu. Pick the two or three where the pain is real, baseline them before deploying the first agent, and set targets using the table’s ranges as an order of magnitude ^[7][10][11].
• Measure the P&L, not activity. A lever only counts if it moves EBITDA, ROCE, working capital or service level ^[7][11]. “Tasks automated” or “tickets resolved” are activity metrics: they dress up reports, they don’t justify investments.
• Make measurement your scaling engine. Each validated lever funds the next phase (self-funding) ^[8] and is what defuses the trust paradox: you defend autonomy with proven results, not promises ^[6].

Adoption Challenges: What Nobody Puts in the Brochure

Here’s what the vendor won’t tell you in the demo: Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value or inadequate risk controls.

It also estimates that of the thousands of vendors calling themselves “agentic”, only about 130 really are. It calls the rest “agent washing” ^[5].

The structural obstacles are well known and stubborn:

• Data quality. The number one barrier, according to procurement leaders themselves: without clean, harmonized data, AI can’t make reliable decisions ^[15]. IDC puts a number on it: companies that don’t prioritize AI-ready data will lose 15% in productivity when trying to scale ^[17].
• Trust and governance. The drop from 43% to 27% in trust in full autonomy ^[6] won’t be fixed by evangelizing. It takes transparency, traceability and autonomy earned in stages.
• Security and IT/OT convergence. Connecting the shop floor to the decision layer expands the attack surface and opens the door to “dark operations”: agents making unwanted decisions in unsupervised environments.
• Legacy systems and fragmentation. Integrating agents into legacy systems is technically complex and expensive; Gartner notes it often pays to redesign the workflow from scratch rather than patch the existing one ^[5].
• The human factor. 95% of executives believe they’ve provided adequate training, but only 20% of employees feel like real contributors to the change ^[9]. That perception gap kills more projects than any technical limitation.

Strategic Recommendations: How to Execute Without Getting Burned

None of these is optional if the goal is autonomy in production, not another pilot for the annual report:

1. Make the transformation pay for itself (self-funding). Start with fast-payback operational quick wins (eg. route and load optimization, SKU rationalization, P2P automation) and reinvest the savings in bigger capabilities (semantic layer, control tower, planning agents). It’s the most pragmatic, viable approach.
2. Data readiness in parallel with agents. Non-negotiable. Deploying agentic AI on inconsistent master data is burning budget. The right sequence: harmonize master data with data agents, establish ownership and measurable data quality, and build the semantic layer (knowledge graph) in parallel to give agents business context. Procurement leaders are unequivocal: analytics and AI create no value without good, reliable data ^[15].
3. Agentic governance: autonomy is earned, not granted. Define autonomy levels by decision type (inform → recommend → execute with approval → execute and report) and set mandatory “human release gates” for decisions with high financial or reputational impact. Gartner recommends exactly this: start with low-risk decisions and expand autonomy in a controlled way while building the data and governance foundation ^[2]. Every agent must be traceable, explainable and auditable. If you can’t reconstruct why it made a decision, it shouldn’t be making decisions.
4. Scale by pattern, not by hype. Start where maturity is real: structured transactional processes (P2P, order management, shipment tracking) ^[15]. Measure impact with business metrics (not activity), resolve the trust paradox with verifiable results, and only then replicate the pattern in more complex processes. And apply Gartner’s anti-hype filter: if the use case doesn’t need agentic intelligence, don’t throw an agent at it ^[5]. Cheap, deterministic RPA is still the right answer to many problems.
5. Redesign roles before the vacuum redesigns them for you. 43% of the function’s working hours will be affected: 29% automated and 14% augmented ^[9]. The human role shifts to “human-in-the-loop”: strategic oversight, decision design and exception management. That means investing in new skills (interpreting agents, AI governance, data management) and, above all, closing the engagement gap: make teams co-authors of the change, not spectators of the executive committee ^[9].
6. Set kill criteria as clear as your investment criteria. If over 40% of agentic projects will be canceled ^[5], make sure yours either die fast and cheap or scale on evidence. From day one, set the value, cost and risk thresholds that decide whether a pilot scales or gets shut down. The discipline to kill projects is as strategic as the discipline to launch them.

The provocative but honest conclusion: the autonomous supply chain isn’t here to replace the expert. It’s here to free your time from low-value tasks and decisions that a machine already handles better and faster, and move you up to the ones that need expertise a machine can’t provide.

Technology is no longer the main barrier ^[13]; leadership, process redesign and decision ownership are. The question is no longer whether your supply chain will be autonomous, but whether you decide how… or your competitors will leave you behind.

Acronyms

• P2P — Procure-to-Pay; the transactional procurement process, from purchase requisition to invoice payment.
• RPA — Robotic Process Automation; rule-based, deterministic automation of repetitive tasks, with no decision-making capability.
• S&OP — Sales & Operations Planning; the process that aligns demand, supply and finance in a single plan.

References

^[1] Gartner (2026.04.07). "SCM Software with Agentic AI Will Grow to $53 Billion in Spend by 2030"

^[2] Gartner (2026.03.18). "60% of Supply Chain Disruptions Will Be Resolved Without Human Intervention by 2031"

^[3] Gartner (2025.09.16). "70% of Large Organizations Will Adopt AI-Based Supply Chain Forecasting by 2030"

^[4] Gartner (2025.05.21). "Half of Supply Chain Management Solutions Will Include Agentic AI Capabilities by 2030"

^[5] Gartner (2026.06.25). "Over 40% of Agentic AI Projects Will Be Canceled by End of 2027"

^[6] Capgemini Research Institute (2025). "Rise of Agentic AI: How Trust Is the Key to Human-AI Collaboration" (informe adjunto al proyecto).

^[7] Accenture (2026.07). "Autonomous Supply Chain by Design" (TL Autonomous SC Design Report, documento del proyecto).

^[8] Accenture (2026.03). "Making Self-Funding Supply Chains Real" (documento del proyecto).

^[9] Procurement Magazine / Accenture (2026). "How AI Drives 23% Higher Supply Chain Margins"

^[10] McKinsey (2026.07.22). "Powering Supply Chains with Agentic AI" (podcast/transcripción, documento del proyecto)

^[11] BCG (2026.05). "Executive Perspectives: AI’s New Mandate in Supply Chains" (documento del proyecto).

^[13] Deloitte Canada (2026.04). "The Agentic Supply Chain" (documento del proyecto).

^[14] BCG (2026.07). "From AI Assistance to Agentic Orchestration in Procurement" (documento del proyecto).

^[15] The Hackett Group (2026). "Procurement Executive Insight Report 2026" (documento del proyecto).

^[16] EY (2026). "Autonomous Supply Chain Planning with AI"

^[17] IDC (2025.10.23). "IDC FutureScape 2026: The Rise of Agentic AI"

^[18] World Economic Forum (2025.11.03). "Why Autonomous Orchestration Is the Next Frontier in Supply Chain Management"

The conclusion is uncomfortable for both ends of the spectrum: employees afraid of losing their jobs, and decision-makers who, chasing cost savings, are laying off entire teams. AI is extraordinarily capable.

But there's one thing it's completely incapable of: making the right calls when nobody's steering. As I've said before, AI is our copilot, but the decisions are ours.

The context

I laid out the initial context: "SaaS platform for centralized record management, integration with external channels, subscription model." Working from an architecture PNG and 4 analytics spreadsheets as context, I pulled together a map of the client's current architecture, without much of a clue yet as to what path we'd end up taking.

After 2 meetings to figure out what the client wanted, and following those classic kickoff sessions where we dream up "ideal" solutions, we landed on a 15-microservice architecture. Documented APIs, data models, databases all designed.

Consistent down to every line, with an incredible level of detail.

It included a Transaction Service with Redsys (I steered it toward this solution based on integration level, since I'd spent several years working with payment gateways), an Analytics Service with an ROI dashboard, a Billing Service with Free/Premium/Enterprise tiers. The exact solution any architect would design facing those requirements. Ambitious, coherent, consistent — nothing a specialist could really object to.

Technically flawless.

After presenting the initial sketch, the validation process with the client revealed that the market and the business model called for a more measured approach. Transforming a business model is a complex process that demands moments of reflection to align the technology with day-to-day operational reality.

Strategic decisions get made by the people who live the business. Our role is to support that vision, understanding that technical design has to be an enabler, not an obstacle.

Iterating and adjusting scope

In an iteration-based process, the goal is to surface the possibilities that open up, letting the client decide which battles to fight at each stage. After analyzing the context, we decided to adjust the project's scope:

1. Prioritization: we identified functionality that, while valuable down the road, wasn't critical for the immediate launch.
2. Optimization: the roadmap was simplified, going from 15 services down to 3 essential ones, ensuring a more agile, realistic path to production.
3. The human factor: this decision came out of human judgment and commercial instinct — things technology alone can't replicate.

AI's role as support, not as guide

This case underscored how important direct communication is. AI, while extremely efficient at refining technical solutions, depends entirely on human strategic direction. When we pivoted to the new model, the technology adapted within hours, but the vision for that change was born out of meetings and notes shared between people.

The pattern that keeps repeating: volatility

This course correction isn't an isolated event — it's a constant in building high-level solutions. Over my 20 years in the field, I've seen firsthand that prioritization is a living organism: budget changes, technical challenges, or strategic pivots in the business model are our daily bread. What gets defined as essential today can stop being essential tomorrow, in favor of the project's viability.

In this landscape, the human factor is irreplaceable. Without precise communication of these changes, technology — and specifically AI — is limited to refining the instructions it was given before. AI is a management amplifier: if direction isn't updated with precision when the business throws a curveball, we risk amplifying the mistake instead of the win.

That's why the key to success isn't just technical capability — it's the agility to communicate a change in context and pivot the technology in real time.

The power of asking the right questions

A critical turning point came up in the technical proposal. The AI, working off abstract architecture patterns, initially suggested replacing the central record-management system with a new, independent microservice. The logic made sense from a theoretical standpoint: split off a consolidated system to modernize it.

However, after looking at how mature and stable the current system actually was (a platform with years of iterations behind it and multiple critical integrations), the strategic question shifted: do we actually need to replace what already works, or is it more efficient to evolve it?

The solution: hybridization and a focus on value

Instead of a full replacement that would have meant months of unnecessary risk and cost, we went with a smart-coexistence approach:

• Preserving the core: keeping the current system as the single source of truth, leaning on its robustness and stable APIs.
• Targeted innovation: designing a new, dedicated microservice for the new functionality that was actually the core of this evolution.
• Delivery agility: thanks to this "divide and conquer" approach, we were able to present a solid, validated execution plan even two days ahead of schedule.

This decision shows that AI can produce the textbook architecture, but only human judgment can determine whether that architecture fits the client's actual context. AI churned out the documentation and models for this new scheme in record time, but the strategic call to keep what delivers value and build only what's necessary is what made the proposal a success.

Why mass layoffs are a logic error

Organizations cutting technical teams because "AI does it now" are confusing execution speed with the ability to direct. As productivity rises, where two development roles used to be needed, now one person with good judgment will do. Does that affect us? Of course it does — but like everything in life, I think there's a middle ground.

AI brings speed. But direction is still a human responsibility, or it isn't direction at all.

A team of 5 people with well-directed AI produces more than a team of 20 without it. Cutting that team of five down to zero doesn't multiply productivity. It destroys it.

What disappears when you remove the person who actually understands isn't the code or the academic design — you eliminate common sense. That's the ability to know whether what you're proposing is really what you need.

The real shift

AI doesn't make technical knowledge irrelevant. It makes technical knowledge without judgment irrelevant.

What it amplifies is the capability of someone who:

• Understands the business and its constraints
• Knows what not to do (that's the hard part)
• Can communicate changes to the team
• Recognizes when the context has shifted

That person, with AI, produces what an entire team used to produce. But only if they know how to direct it. What matters isn't proposing components or writing code — it's deciding which components are actually needed, or what code to write. That's simply more visible now. AI executes at a speed that doesn't forgive a lack of direction: an architecture that used to take months to reveal its flaws now reveals them in weeks.

Conclusion

I don't think AI is going to replace people who know what they're doing. I think it's going to make the people who genuinely know what they're doing a lot more visible.

AI is an extraordinary amplification lever, but its real power lies in the fact that it amplifies whatever you feed into it. It's a multiplier of intent: apply good judgment, and you get an augmented, precise vision; apply confusion, and all you'll get is chaos scaled at a speed no human team could ever match.

In the project I described, AI didn't work instead of people. It worked with someone who knew what to ask, when to change course, and how to communicate decisions, at a speed that would have previously required an entire team.

The difference between that and a disaster came down to a handful of human decisions made at the right moment.

Projects move forward, teams keep delivering, steering committees meet, reports come in with positive news. But when you ask where the value is, what the impact is, what return we're getting, which initiatives should be accelerated or which ones should be stopped, the answers are no longer so obvious.

And that's where one of the biggest challenges facing many organizations shows up: it's not just about executing more, it's about improving the quality of the decisions that connect strategy, investment, capacity, and execution.

The traditional PMO is no longer enough

For years, project offices at large companies have played a critical role in helping organizations structure, govern, and professionalize project management. Thanks to them, many companies have managed to increase delivery capacity, improve control over execution, and reduce operational uncertainty.

But today's context demands something more. The speed of market change, digital transformation, new capabilities driven by AI, pressure to show faster results, and organizations juggling more initiatives than they can realistically absorb.

In this landscape, "just managing projects" is no longer enough. We need to be able to decide better. Decide which initiatives create the most value, decide where to invest, decide what to accelerate — and above all, decide what to stop doing. That's why more and more organizations are evolving from traditional project management office models toward value management office approaches. Not because they need a new office, but because they need a new way of connecting strategy, investment, capacity, and execution.

An evolution that means shifting:

• From measuring activity to measuring impact.
• From managing projects to managing portfolios and value chains.
• From tracking deliverables to validating outcomes.
• From rigid budgets to adaptive investment models.
• From static reporting to real-time, actionable information.
• From prioritizing by gut feeling to prioritizing by evidence.
• From keeping everything running to having the maturity to accelerate, pivot, pause, or stop.

Because a project moving forward doesn't always mean value is moving forward.

A project can be on schedule, within budget, with flawless reporting, and still not be generating the impact that justified the investment in the first place. In the same way, an initiative might need to change direction because the context has shifted, because the original hypotheses didn't hold up, or because higher-value opportunities have emerged.

That's where a VMO (Value Management Office) can make the difference.

VMO and its key capabilities

It's not just about knowing whether projects are moving forward. It's about knowing whether they're still the best way to move forward toward the organization's strategic goals.
To get there, a VMO needs to build several capabilities:

1. The first is strategic portfolio management: deciding which initiatives get in, which ones continue, which ones should make room for other priorities. Prioritizing isn't sorting a list once a year, it's keeping the conversation alive about where it's still worth investing.
2. The second is value measurement. It's not enough to measure completed tasks, milestones hit, or percentage of progress. We need to connect outputs to outcomes: what we deliver, what changes because of what we deliver, and how that change impacts the business, customers, people, or operations.
3. The third is capacity management. Many organizations don't fail because they lack strategy — they fail because they have more open initiatives than they can actually absorb. Without a realistic view of available capacity, strategy risks becoming little more than a statement of intent.
4. The fourth is building decision cadences. The difference isn't having better dashboards, it's creating spaces where business, technology, and operations review the information that matters, compare what they're learning, manage dependencies, and make timely decisions.
5. And the fifth is organizational learning. A mature VMO doesn't just watch metrics — it also helps the organization understand what it's learning, which patterns keep repeating, which capabilities need developing, and which ways of working need reinforcing to deliver value more sustainably.

At REV by Paradigma we've spent years helping organizations through this kind of evolution, and there's one thing we've learned over and over: the most resilient organizations aren't the ones executing the most projects — they're the ones that best understand where to create value and can adapt their decisions in time when the context shifts.

That's why our vision of a VMO goes well beyond a tracking or governance office. We see it as an organizational capability that helps align business, people, technology, and execution under one common direction.

And to get there, we don't just build a better PMO with new processes, tools, or governance mechanisms. We help build more adaptable organizations by combining multiple solutions and initiatives spanning everything from portfolio management, value-based prioritization, capacity management, organizational design, leadership development, role evolution, knowledge management, impact metrics, communities of practice, effective use of artificial intelligence, and many other solutions — all with the same core goal: connecting strategy and business.

Conclusion

Evolving toward a value-driven mindset requires building much deeper organizational capabilities and a culture grounded in transparency, shared accountability, data-driven decision-making, and continuous learning. You need a shared language for what "value" actually means. You need to define metrics that are actually useful. You need transparency to see what's happening, and shared accountability to act on it.
You also need to accept an uncomfortable truth: prioritizing means giving something up.

If everything is a priority, nothing really is. If every initiative keeps getting greenlit, if nothing ever gets reviewed, if nothing ever gets stopped, and everything competes for the same capacity, the organization ends up generating nothing but scattered effort, friction, and lost focus. This shift also demands rethinking how we fund initiatives, moving toward more incremental, flexible models that can adapt as the context changes and new information emerges.

A VMO helps precisely by making those tensions visible. Not to replace business judgment, but to improve the quality of the conversations different areas need to have together.

No methodology transforms an organization on its own. It's culture, leadership, and decision-making mechanisms that turn that vision into something that actually holds up over time.

Adaptive organizations have the competitive edge that separates the ones that evolve from the ones that get left behind. In a world where scope keeps shifting, priorities keep evolving, and uncertainty is just part of the day-to-day, the organizations that stand out aren't the ones running the most projects — they're the ones that innovate, prioritize, and decide where to put their time, money, and talent better than anyone else.

The challenge is no longer just having more data — the challenge is turning it into better decisions. And maybe that's the real evolution many organizations still have ahead of them: stopping at just asking how much progress we've made, and starting to systematically ask what value we're generating, what we're learning, and where it's still worth investing.

Moving from managing projects to managing value isn't about renaming an office — it's about evolving the organization's capabilities.

There's a move almost everyone repeats the first time they try building a mobile app with an AI agent: open the chat, ask it for the entire app in one go, and sit back and wait. A few seconds later you've got screens, navigation, and something that compiles. It feels like magic.

That feeling lasts right up until you try to build the second feature on top of the first one.

Because a model never tells you "I don't know." It always hands you something that looks finished, even when it isn't. And if you haven't marked out the path, that "something" comes from what the model assumes you wanted, not from what you actually wanted. It wanders off, goes its own way, makes its own calls. For an afternoon experiment, that's perfectly fine. For an app headed to production, it's where the problems start.

The problem isn't that it fails — it's that it never fails

An AI agent always hands you a solution because that's exactly what it's trained to do: fill the gap with the first thing that lets it deliver something. And that's the risk: it hands back an answer that looks finished but almost never respects what you've already built, and it doesn't warn you about what it made up along the way.

Anyone who's seriously tried this will recognize the example. Throughout this series, we're going to build a shared-expenses app — the kind you use to split what a group spends (a dinner, a trip, a shared flat) and figure out who owes who at the end.

So, we start by asking the agent for the add-expense screen, and instead of following the project's architecture, it takes the fast lane. All the logic — UI, API calls, split calculation, parsing, persistence — crammed into a single giant class.

// A screen that does EVERYTHING at once:

class AddExpenseActivity : AppCompatActivity() {
    private val db = AppDatabase.get()    // data
    private fun save(amount: Double, payerId: String) {
        lifecycleScope.launch { 

        // business rules stuffed into the UI:

            val members = db.groupDao().members(currentGroupId)
            val share   = amount / members.size   // split
            members.forEach { m ->

             // persistence

                db.balanceDao().add(m.id, share, payerId)                          
}
         // and while it's at it, syncs with the backend right here:

            // direct API call

            val res = api.post("$BASE_URL/expenses", body)
            Json.decodeFromString<ExpenseDto>(res) // parsing
            runOnUiThread { showBalance() }        // UI + state
        }
    }
    // ...and below that, 400 more lines drawing the form.
}

It compiles, it works in the demo, but you've just broken one of the most expensive rules to break on mobile (the UI calling the backend directly, with the split baked right into the screen), and the next screen is going to be built on top of it.

If we repeat this on the balances screen, the settle-up screen, and the create-group screen, we'll realize we no longer have an app — we have a snowball, where every new piece drags along the mess from the last one, and untangling it costs more than doing it right from the start.

The first time you run into something like this, it takes a while to sink in, because even though it "works," the solution doesn't hold up. The code is there, it compiles, and the demo goes fine — but the problem was never that one file: it was that every file after it was going to copy its bad example.

That's the trap of asking and waiting: it doesn't break on day one, it breaks on day 20.

Defining is the new craft

Well defined, that same agent gets you moving at a speed that didn't exist two years ago. And the whole difference fits in one word: defined.

The more you break the task down and the more tightly you close off what you're asking for, the less room you leave the model to fill in with what you didn't want. Asking for "the add-expense screen" and leaving it at that is not the same as scoping the request so tightly there's no room left for improvisation:

The same screen, tightly scoped:

• Task: Composable AddExpenseScreen — UI only
• Follows the existing ui/domain/data layer pattern
• No business logic or backend calls from the screen
• The split is calculated by the SplitExpense use case (already implemented)
• Persists to the local DB. Syncing isn't this layer's concern
• States: loading / error / data

One task, one scope, one layer.

If you notice, the second version doesn't leave the agent a single decision it can make up on its own: the split calculation lives in its own use case, persistence lives in the data layer, syncing lives somewhere else. The screen just renders. That same task, directed with this level of precision, usually comes out right on the first try. And when it doesn't, the failure is contained to the UI: there's no need to chase it across five tangled responsibilities.

The concrete difference shows up best when you contrast how it's asked:

// ✖️ Open-ended - the model decides the architecture for you
"Build me the screen for adding an expense to the group."

// ✔️ Scoped - you decide and the agent executes
"Composable AddExpenseScreen, UI layer only.
- Takes an AddExpenseUiState and emits events to the ViewModel.
- The split is resolved by the SplitExpense use case — do NOT calculate it here.
- No backend calls from the Composable.
- States to render: loading | error | data."

The first version invites the mega-class. The second one leaves no room to improvise. That's where the developer's job shifts: the skill isn't just typing code anymore, it's defining things precisely enough that the code coming out of the agent is yours, not its.

They're not using different models. They're defining things differently.

For me, that's the line that separates people who say AI "isn't good for anything serious" from people who actually use it to ship.

Start before the code: let the agent interview you

The first thing to do when starting an app isn't coding, it's specifying. We need to flip the usual script: instead of asking the agent to build, we ask it to interview us.

We give it the context of what we want and let it ask questions. It lays out the possible paths, puts the options on the table, tells us which one it recommends, and we make the final call. That interview brings to light the decisions we didn't even know we had to make — the same ones that, left unresolved, are exactly what turns into the snowball later on.

Example:

- You: "I want an app to track shared expenses."

- Agent: Are groups fixed, or created per event? Is the split even, or by percentage? Do you need offline mode from day one? My recommendation: groups per event, configurable split, no offline for now. Shall we go with that?

- You: Done: groups per event, configurable split, no offline.

In three questions, the agent has locked down three decisions that, left unasked, it would have assumed on its own — almost always the opposite of what we wanted. That's what specifying is: surfacing what you'd take for granted before the code takes it for granted on your behalf.

Out of that conversation comes, almost without trying, the scope of the first version. The shared-expenses app ended up looking like this:

Shared-expenses app MVP

• Create a group per event (a dinner, a trip).
• Add an expense and record who paid.
• Configurable split: even, or by percentage.
• Balance screen: who owes who.
• Settle a debt and mark it as paid.

Deliberately out of v1: in-app real payments, multi-currency, and offline mode.

Saying out loud what's not included is half the work. Three lines ("no in-app payments, no multi-currency, no offline") save the agent from the temptation to build a payment gateway nobody asked for, and save you the time of ripping it back out.

You don't need to lock everything down at once, either. It's enough to close off just enough that the first task has no gaps the model can slip through. The rest gets defined when its turn comes, one piece at a time.

Defining isn't writing a giant document before you start — it's not leaving any important decision to chance. Once those decisions are made, the next step is writing them down where the agent can check them while it codes (we'll get to that in the post about context) and breaking the "what" down into closed specs, which is a topic for another article altogether.

Specifying first isn't bureaucracy — it's moving the moment of thinking to before you write the code, when changing your mind costs one sentence instead of a refactor.

Loose to experiment, tight to ship

It's worth not mixing up two worlds that look alike but aren't. For a prototype, a quick test, or a weekend of tinkering, let the agent run loose: it's disposable, and the speed more than makes up for the mess. Nobody's going to maintain that.

For something headed to production, open-endedness comes at a cost, with interest. Every shortcut the model invents is technical debt someone — you, three months from now — will have to untangle. The difference between the fun experiment and the maintenance headache isn't in the agent: it's in how much discipline you put in front of it.

In the shared-expenses app, that discipline fits into one rule repeated to the point of boredom: the UI never talks to the backend. The screen asks the domain, the domain decides, the data layer saves locally, and the backend only comes in to sync.

Written down like that, the rule is trivial — and respected on every screen, it's the difference between an app that scales and a snowball.

// The layer that decides lives in domain/, outside the screen:
class SplitExpense(private val repo: ExpenseRepository) {
    suspend operator fun invoke(expense: Expense, split: Split) {
        val shares = when (split) {
            is Split.Equal   -> expense.equalShares()
            is Split.Percent -> expense.byPercent(split.weights)
        }
        repo.save(expense, shares)   // to the local DB; sync happens elsewhere
    }
}

The screen just calls SplitExpense and renders the result. It doesn't know how the split is calculated or where it's stored, and precisely because it doesn't know, the day the split logic changes, only this file gets touched. We'll get into how to chain these pieces together with the agent without it skipping layers in another post about development.

Natural language: one more layer, not a threat

A lot of people still resist this, and almost always for the same reason: they'd rather see and touch the code with their own hands. I get it, I come from that world too, but I think that's looking at the shift from the wrong angle.

In the beginning, we programmed the processor directly, in assembly. Then high-level languages arrived, and we stopped fighting with registers and memory. Every leap hid the layer below so we could think at a higher level. Directing an agent in natural language is the next rung on that same ladder: one more layer of abstraction, not the disappearance of the craft.

And just like every leap before it, we still need to know what we're building. Whoever coded in C understood what was happening underneath; whoever directs an agent has to understand the architecture they want, or the agent will make it up.

In the expenses app, if we're not clear that the split logic lives in the domain layer and not on the screen, the agent decides — and decides badly, not because it's clumsy, but because nobody told it where each thing belonged.

Abstraction frees you from the keyboard, not from judgment.

Conclusion

The invitation is straightforward: try it for real, and do it right. Don't ask for everything at once and expect it to turn out well. Define it, break it into pieces, let it interview you, and direct it yourself. Speed shows up on its own once the foundation is locked down.

In the next articles in this series, we'll look at exactly how to lock it down, phase by phase: the context the agent reads before touching anything, the skills you use to teach it to do things your way, the specs that break the work into pieces, and finally, development.

If there's one line to take away from all this, let it be this: with an agent, the bottleneck is no longer writing the code — it's knowing exactly what you want.

The shared-expenses app we'll be building throughout this series isn't going to fall apart because of the model. It'll hold up based on what we lock down before it writes the first line. And that part, fortunately, is entirely up to us.

The effect of problem management on projects is an almost endless chain of decisions that, at times, drives the business, the technical team, and the management profile that arranges and monitors them as a servant leader to distraction. To handle disagreements and bring some order, we usually turn to a prioritization matrix if we're in a sensible, coordinated context. If we're in a different context, we fall back on experience by similarity, and if not, on impulsive decisions based on perceptions, urgencies, or fears.

The problem isn't that problems exist. The problem is treating them all the same. Problems aren't challenges, but they can be challenging. Poorly conceptualized challenges (true need, sponsorship, expected outcome, deviations) turn into problems.

Cynefin: understanding the context first

Almost three decades ago, Dave Snowden taught us about Cynefin and the 5 context domains where problems live:

• Clear/Simple: a stable, obvious, and known cause-effect relationship. Standards exist and no experts are needed.
• Complicated: the cause-effect relationship exists but isn't obvious; you need to analyze it or bring in specialists to find it. More than one correct solution exists once diagnosis is done.
• Complex: the cause-effect relationship can only be understood in hindsight, because the system has many interacting variables that are hard to visualize, with emergent and unpredictable results. Since no established best practices exist, challenges are approached experimentally.
• Chaotic: no cause-effect relationship can be discerned, either before or after, since the environment is in crisis and/or changing too fast. The approach is to first stabilize, then observe, and then try to establish some order toward standardization.
• Disorder: a state in which it isn't clear which domain you're in; there's confusion, and each actor interprets the situation according to their own bias. The goal is to diagnose and classify the situation, moving the problem into one of the four domains above so it can be acted on appropriately.

It's an abstract taxonomy that lets us pinpoint the nature of the challenge. Before solving, it's worth understanding what type of context we're operating in. There are also frameworks and methodologies that define problem typologies more closely tied to a specific area of work.

ITIL: incidents and problems are not the same thing

In ITSM, there's the classic ITIL approach to problems/incidents from a proactive or reactive standpoint, assessing them with the simple and effective impact and urgency matrix.

ITIL reminds us of something basic: putting out the fire and understanding why it started are not the same activity.

Aware that both coexist within a continuous improvement approach, ITIL establishes a framework to reduce the probability of impact and places emphasis on avoiding recurrence by learning from experience. To do this, it distinguishes between incidents and problems:

Incident management

• Objective: restore the service quickly, "put out the fire," even by rolling back changes or using workarounds.
• Horizon: short term, focused on operational continuity and user experience.

Problem management

• Objective: understand why incidents occur and how to prevent them from recurring, through structured root cause analysis.
• Horizon: medium to long term, focused on service stability, reliability, and continuous improvement.

In practice, a serious or recurring incident usually triggers the opening of a problem to investigate its causes. And the findings from problem management usually give rise to change requests to permanently fix the service.

A matrix for executive problems

If what we need is an order of magnitude and logic for executive-level problems, one that isn't purely tied to technology nor as abstract as Cynefin, I'd like to propose a matrix combining two well-known typologies that you might find inspiring.

I base it on combining Peter Drucker's typology with Art Smalley's:

Peter Drucker's generic typology

Peter Drucker distinguished four types of problems that appear in organizations based on how they arise and persist:

1. Truly generic: cases that are symptoms of a recurring pattern within the organization — today we would call them "systemic." Drucker explains that most problems are of this nature, and that although symptoms may vary in how they manifest, they are just adaptations of the original. This clears the path considerably if we're able to find the root cause.
2. Unique: your organization experiences them only once, but the situation is common in other organizations. They aren't anomalous or rare, and you can seek support by looking at similar situations faced by competitors or partners.
3. Truly exceptional, truly unique: singular situations that can't be treated as textbook cases; they usually have complex, multifactorial causes that rarely converge again.
4. Early manifestations of a new generic problem (Earlys): weak signals of a trend that will become recurring if not addressed. Extremely interesting and profitable to tackle before they contaminate the ecosystem.

From my experience in Lean, this classification forces you to decide whether to act with improvement responses (Kaizen), design new policies (Kaikaku), or engage in deeper strategic reflection (Kakushin).

Art Smalley's typology

Art Smalley also proposes four types of problems, but from the angle of how they're approached:

1. Troubleshooting: a reactive response to "stop the bleeding" and return the situation to the known standard as quickly as possible.
2. Gap from standard: using structured problem-solving to eliminate root causes preventing the standard from being met. The measures remain reactive but systematic and planned.
3. Target state: a proactive, continuous-improvement approach aimed at reaching a performance level better than the current one, defining a new standard.
4. Open-ended: proactive, creative exploration of radical solutions or new models that go well beyond current levels of value.

Each type calls for different methods, management cadences, and mindsets. All of them share, as their guiding axis, their relationship to the standard as an ideal.

Crossing the nature of the problem with its method of resolution

What I apply in projects is a combined matrix. Its power lies in crossing the nature of the event (Drucker) with the resolution methodology (Smalley). This avoids the classic mistake of applying "engineering solutions" to "management problems", or vice versa.

Drucker helps you understand the nature and recurrence of the problem within the system, while Smalley points you toward the practical resolution approach from Lean.

How to use this matrix in projects

This matrix lets you categorize any deviation in a project and select the appropriate resolution "style." You can start from the row (Drucker): is this problem generic, unique, exceptional, or an early signal of something that will recur? Then you choose the column (Smalley): should we contain it, tackle a deviation from standard, pursue a target state, or open up a space for innovation?

Consciously using this double classification helps avoid two very common mistakes: treating strategic crises as simple operational incidents, or, the other way around, using "innovation" when in reality it would be enough to standardize and fix a recurring deviation in the project. Both inappropriate actions are forms of Muda: management waste that should be identified and eliminated.

Problem management is a cross-functional effort: it requires participation from development, operations, security, business, and other teams to investigate causes and design effective solutions.
Once the process for approaching problems is established and understood, problems become the cornerstone of growth and adaptation: true treasures of the organization, levers of competitiveness and learning.

At Rev by Paradigma, thanks to our experience in agility, lean, and digital product design, we build simple processes for approaching problems in situational or systemic circumstances, which can be surgical or sustained depending on our clients' needs.

Classifying a problem well doesn't automatically solve it, but it keeps you from starting in the wrong place. And in complex projects, that alone is a huge advantage.

References

• Cynefin Framework
• Snowden & Boone - A Leader's Framework for Decision Making, Harvard Business Review
• Peter Drucker - The Effective Executive
• Art Smalley - Four Types of Problems

This article reviews the scientific literature to test two hypotheses that argue for RAG's obsolescence: the redundancy of retrieval given extended context windows (1M+ tokens), and the displacement of this technique by agent-based systems. The data says otherwise on both counts, and it also explains why ignoring them costs you dearly.

If your system still retrieves information the way it did in 2023, this is for you. The question is no longer whether RAG is dead. It's how much context budget you're wasting without realizing it.

Has RAG really died?

You've probably seen the same headline on LinkedIn, "X," or in some technical newsletters: "RAG is dead." It's said with the same conviction as in 2022, when we were promised that prompt engineering would be the profession of the future, or in 2025, when we were assured that autonomous agents would leave us all jobless. Like every tech prophecy, there's some truth to it, but also a healthy dose of posturing.

Let's do what we do best: debunk the myths with data, not opinions.

In 2023, RAG (Retrieval-Augmented Generation) was a simple architecture: a question, an embedding, a fragment search (with luck, a re-ranker), a prompt, and done. It was a series of boxes with arrows, one after another, that got companies excited just by seeing it on a slide. In 2026 that architecture is history. Models handle context windows of a million tokens or more, agents grep through repositories, run SQL, call APIs, reformulate a search if the first one doesn't work, and carry working memory across steps. The four-box diagram no longer describes almost any real system.

Hence the controversy of the headline. But my position is different: RAG has not died. It has stopped being a closed-off solution to become a basic piece of engineering. The fact that it's just one more tool in the system, rather than the whole system, is proof that the technology has matured.

From an objective standpoint, what part of RAG really has died

Before defending RAG, I want to be honest with those who consider it buried, since they have a point. There are pieces of the 2023-era RAG that make no sense in a serious system today. I'm thinking, for example, of fixed top-k with no justification, of 512-token chunks just because, of using a single embedding as a universal search engine, or of relying on dense retrieval with no lexical component. That linear pipeline of five boxes in a row is, indeed, what has died.

There is a compelling technical reason for this shift. More than a failure of power, we've become aware of limits we used to ignore. When generating embeddings, we face an almost impossible balancing act: capturing a text's overall meaning while also distinguishing very fine-grained nuances. This is the so-called "granularity dilemma." Text encoders systematically fail when two passages share the same semantic field but differ in one specific entity or fact.

The interesting part is that model size doesn't solve this on its own. A recent study shows that a model of just 0.1B parameters, fine-tuned specifically for this task, outperforms 7B models (Xu et al., 2025). The failure isn't one of power, it's one of design. That's why a single vector search channel never was, and still isn't today, a solid foundation.

The exact same thing happens with chunking. Splitting into large blocks mixes different entities into the same vector and dilutes the nuance; splitting into tiny fragments gains precision on the entity but loses the context that gives it meaning. That's why the solutions that work in production don't look for an "optimal chunk size," but instead use schemes like hierarchical chunking: index the small fragment, but retrieve the paragraph or document that surrounds it.

Long context has also genuinely improved, and I won't dispute that with anyone. There are models today that support windows of one, two, or even ten million tokens, and this obviously shifts the rules a bit as to what's worth retrieving as a unit. Before, you had to chop up a document because it didn't fit whole. Now, in many cases, you can fit the whole document in. That's not marketing, it's a real architectural improvement. But this doesn't justify dumping the entire corpus into a prompt, and this is where the "infinite context" narrative starts to collide with the numbers and with reality.

Myth 1: "Giant context windows make RAG unnecessary"

This is the argument that grabs the most headlines: if models already handle windows of one or two million tokens, why bother retrieving anything? Just inject everything. The technical problem is that a model doesn't pay attention uniformly across that entire window. This phenomenon is known as Context Rot (or context degradation): the more information we inject, the more noise we introduce, and the worse the model reasons (Liu et al., 2024).

The RULER benchmark exposed this mirage back in 2024. At that point, although most models claimed to support windows of 32K tokens or more, only 50% maintained acceptable performance under real-world usage conditions (Hsieh et al., 2024).

The result that, in my view, most changes the perspective on this problem is NoLiMa. While RULER usually lets the model find the answer through mere lexical matching, NoLiMa removes that "hint" and forces the model to reason semantically. The results were revealing: of 13 models claiming to support contexts of at least 128K tokens, 11 dropped below 50% of their performance by the time they reached 32K. Even a benchmark model like GPT-4o went from 99.3% accuracy in short context to 69.7% under long-context conditions (Modarressi et al., 2025)*.

*Given the dizzying pace of new model development, it's essential to verify the specific versions and architectures referenced in Modarressi et al., 2025, before generalizing their results.

We should also consider that almost all of this evidence is measured in English. When this capability is tested across 26 languages at once, the performance gap between high-resource and low-resource languages triples as the window grows (Kim et al., 2025; Hengle et al., 2026; Wang et al., 2026; Qi et al., 2025).

All of this evidence points in the same direction:

Just because a model can afford the cost of reading a million tokens doesn't mean that million tokens is useful attention.

That's why I prefer to see retrieval not as a technique competing with long context, but as the manager of our budget. Every call to the model is a finite resource that we must divide between instructions, history, memory, and retrieved documents. Retrieval is the function that decides which part of the world deserves to occupy that space. The bigger the window, the more expensive it is to waste it. Retrieving information precisely is more critical today than ever.

Myth 2: "Agents replace RAG"

This is, in my view, the strongest argument from those who consider RAG dead. Let's examine it closely, though. Most agents decide their next step based on what they just observed, not on a fixed script, and at some point in that loop, the same question almost always comes up: what do I need to know before continuing? That question is retrieval, even if it no longer carries that label.

An agent doesn't follow a linear flow. It must plan, search, evaluate results, decide whether it needs more information, consult tools, and compare before writing a single word. Even when the search strategy becomes multi-level, the operational essence remains data retrieval. What has evolved isn't the act of retrieving itself, but the system's orchestrating intelligence to discern which channels to consult and exactly when to execute each strategy.

Current evidence shows that letting an agent perform exhaustive searches isn't just costly, it's often counterproductive. A recent benchmark, ContextBench, analyzed the behavior of different models (GPT-5, Claude Sonnet 4.5, and Devstral 2) operating as autonomous agents on hundreds of real incidents. The results dismantle the intuition that "more searching equals a better answer."

The analysis is clear: aggressive exploration, where the agent runs excessive rounds of search, drives up token consumption and operational cost, and, moreover, doesn't guarantee higher quality (Li et al., 2026). By contrast, models that adopt a moderate approach achieve a superior balance and reach better performance without needing to saturate the system with redundant queries. The lesson from all this is that aggressive exploration by agents only inflates spend, not accuracy. Reading more doesn't equal retrieving better.

In practice, what we're seeing consolidate in 2026 are hybrid pipelines that optimize resources. A successful pattern usually looks like this:

1. Initial retrieval: combine sparse representations (BM25) with dense embeddings to get a broad set (50-100 candidates).
2. Re-ranking: pass that set through a cross-encoder that computes real cross-attention between the query and each fragment.
3. Selection: keep only the 5 to 10 most relevant blocks before calling the generator model.

This approach is more expensive than a simple embedding, yes, but infinitely more efficient than saturating the LLM with a hundred random fragments. As confirmed by the study by Assadi et al. (2026), in semantic search, a good embedding model beats any combination that tries to use an LLM to re-rank results from scratch. Spending the expensive model where it isn't needed not only increases cost; it often doesn't even improve the result.

Another successful pattern, based on an architecture built around a reflective reasoning loop, usually looks like this:

1. Decomposition and planning: the agent receives the complex query and unfolds a dynamic planning graph to break the problem into sub-tasks, avoiding static sequences.
2. Intent routing: it evaluates the type of data required and routes each sub-task to the appropriate specialized retrieval tools (such as vector engines, structured SQL queries, or knowledge graphs).
3. Execution and retrieval: it runs queries against the selected channels to extract the necessary empirical evidence.
4. Self-reflection: it recursively assesses whether the retrieved evidence is sufficient, accurate, and relevant to resolve the query.
5. Automatic re-planning: if the internal relevance or data-sufficiency metric fails, the system triggers automatic re-planning to iterate or search new sources.
6. Evidential reasoning: it consolidates and adjusts its strategy in real time, using validated evidence to synthesize the final answer.

Obviously, this orchestrating sophistication raises a first-order pragmatic challenge: accumulated latency and cost per query. However, delegating every micro-decision of this loop to a frontier LLM is economically unsustainable. Architectures that scale apply a layered approach: they use embedding models and re-rankers (cross-encoders) to filter context efficiently, reserving the heavy LLM only for the final synthesis phase. This specialized filtering drastically reduces noise and operational cost, ensuring that only the highest-quality evidence reaches the reasoning model.

On the other hand, when a query requires connecting related concepts across multiple documents, vectors fail. This is where knowledge graphs solve the equation, allowing the model to reason over explicit connections.

These have proven superior to pure vector search (Pan et al., 2024; Chen et al., 2024). In the past, the problem was the cost of building the entire graph. But recent implementations like GraphRAG (Edge et al., 2024) and optimized solutions such as LazyGraphRAG (Edge et al., 2024), HippoRAG (Gutiérrez et al., 2024), or LightRAG (Guo et al., 2025) allow complex semantic relationships to be extracted with reduced indexing costs, with GraphRAG-bench (Xiao et al., 2025) serving as a key reference for evaluating reasoning capability in these environments.

Ultimately, this ecosystem of techniques (from hybrid retrieval to orchestration via agents and knowledge graphs) doesn't offer universal solutions. Success lies in the modular composition of these mechanisms according to the complexity and intent of each query.

So the useful debate in 2026 is no longer "RAG or agents?" The right question is: which retrieval mechanism should each agent use, at what point in its reasoning, and with what budget? The agent doesn't replace RAG, it absorbs it as an internal capability.

The metric we tend to forget: latency and cost

In corporate environments, the bottleneck usually isn't the technology, it's the budget. Forcing models to process immense contexts by default wrecks the economic viability of any product. Precision in filtering information isn't just a technical challenge, it's financial discipline so that the cloud bill doesn't eat into the business margin.

A million tokens costs money and time. Meanwhile, an efficient hybrid search filters data in milliseconds. Forcing the model to process the entire repository before writing the first word drives latency up to several seconds. For a conversational assistant, sending hundreds of thousands of tokens per call isn't just expensive, it's a terrible user experience. The goal in production is never to saturate the model with superfluous data, but to deliver, with great precision, the few tokens that actually determine the decision.

The providers themselves confirm this by launching features like context caching (Gemini's or Claude's context cache). These tools are a complement to smart retrieval, never a substitute, designed precisely so you don't have to pay for or wait on the same data over and over.

The data backs up this caution. Assadi et al. (2026) show that, although LLMs achieve competitive results, the cost is disproportionate. Using a model like Gemini 3.1 Pro for retrieval tasks can be up to 1,431 times more expensive than using a specialized embedding model. Moreover, LLM processing speed is drastically lower. In terms of efficiency, tokens devoted to "reasoning" account for between 28% and 81% of the total cost. Often, the model goes back and forth over relevance judgments it had already settled on the first read, inflating the bill without improving the result.

The lesson is clear:

Use embedding models for the bulk of the work and reserve the LLM for the final reasoning that truly needs it.

The question for anyone designing a generative AI system should no longer be "how many tokens does my model support?" but "what is the optimal context budget for each step of my system?"

So, what do we do with our 2023 RAG?

It's time to set aside theoretical debates and be pragmatic. If your current system is still anchored in 2023's assumptions, such as static chunking, blind vector search, and a rigid linear flow, it's only natural that the results fall short.

The problem isn't that RAG has died. The problem is that you're trying to solve today's challenges with an obsolete architecture. Your pipeline needs to stop being a simple search engine and become a decision-making system.

To modernize it, any production solution must answer these six critical questions:

1. What to retrieve? Precisely isolate the exact information that resolves the query, going beyond simple similarity.
2. When to act? Determine the precise moment for the query so as not to saturate the system with unnecessary searches.
3. How to search? Choose the right path (vector, lexical, structured, temporal, hybrid, or agent-assisted) based on the nature of the query.
4. Who has access? Guarantee security filters and user permissions before injecting any data into the context.
5. Is it still current? Validate the temporal freshness of the information to avoid feeding the model outdated data.
6. Where does it come from? Ensure full traceability and exact attribution of sources, a non-negotiable requirement for business decisions.

My hypothesis for 2026/2027

The term "RAG" has lost the spotlight to the agent narrative, but information retrieval hasn't disappeared. It has simply stopped being a standalone component. It no longer needs a name of its own because it is, quite simply, an inherent capability.

Retrieval is the connective tissue of the agent. Whether querying a database, a document, code, or an internal policy, the flow is constant: the agent determines the need, the system validates access, the retriever filters the content, and the model reasons over the selected information.

That's why "has RAG died?" strikes me as the wrong question for 2026. The real unknown we need to solve in every project is more technical and less about appearances: how much context budget are we wasting?

RAG should no longer be understood as a rigid architecture drawn on a slide, it's a basic function of any generative AI system. The bigger the context windows get, the more vital it becomes to execute this function with precision.

So:

What has died isn't RAG. It's your 2023 pipeline.

If you found this review useful, share it with anyone still arguing over whether "RAG is dead" instead of discussing how their system should be retrieving.

References

• Assadi, A. E., Muennighoff, N., & Lee, J. (2026). The Embedder's Dilemma: LLMs Are Better, but at What Cost?. arXiv preprint arXiv:2608.12875.
• Chen, Z., Zhang, Y., Fang, Y., Geng, Y., Guo, L., Chen, X., ... & Chen, H. (2024). Knowledge graphs meet multi-modal learning: A comprehensive survey. arXiv preprint arXiv:2402.05391.
• Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A., ... & Larson, J. (2024). From local to global: A graph rag approach to query-focused summarization. arXiv preprint arXiv:2404.16130.
• Edge, J. L. D., Trinh, H., & Larson, J. (2024). Lazygraphrag: Setting a new standard for quality and cost. Microsoft Blog.
• Guo, Z., Xia, L., Yu, Y., Ao, T., & Huang, C. (2025, November). LightRAG: Simple and Fast Retrieval-Augmented Generation. In EMNLP (Findings) (pp. 10746-10761).
• Gutiérrez, B. J., Shu, Y., Gu, Y., Yasunaga, M., & Su, Y. (2024). Hipporag: Neurobiologically inspired long-term memory for large language models. Advances in neural information processing systems, 37, 59532-59569.
• Hengle, A., Bajpai, P., Dan, S., & Chakraborty, T. (2026, March). Can LLMs reason over extended multilingual contexts? Towards long-context evaluation beyond retrieval over haystacks. In Proceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 6128-6152).
• Hsieh, C. P., Sun, S., Kriman, S., Acharya, S., Rekesh, D., Jia, F., ... & Ginsburg, B. (2024). RULER: What's the real context size of your long-context language models?. arXiv preprint arXiv:2404.06654.
• Kim, Y., Russell, J., Karpinska, M., & Iyyer, M. (2025). One ruler to measure them all: Benchmarking multilingual long-context language models. arXiv preprint arXiv:2503.01996.
• Li, H., Zhu, L., Zhang, B., Feng, R., Wang, J., Pan, Y., ... & Ye, H. (2026). Contextbench: A benchmark for context retrieval in coding agents. arXiv preprint arXiv:2602.05892.
• Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the middle: How language models use long contexts. Transactions of the association for computational linguistics, 12, 157-173.
• Modarressi, A., Deilamsalehy, H., Dernoncourt, F., Bui, T., Rossi, R. A., Yoon, S., & Schütze, H. (2025). Nolima: Long-context evaluation beyond literal matching. arXiv preprint arXiv:2502.05167.
• Pan, S., Luo, L., Wang, Y., Chen, C., Wang, J., & Wu, X. (2024). Unifying large language models and knowledge graphs: A roadmap. IEEE Transactions on Knowledge and Data Engineering, 36(7), 3580-3599.
• Qi, J., Fernández, R., & Bisazza, A. (2025, November). On the consistency of multilingual context utilization in retrieval-augmented generation. In Proceedings of the 5th Workshop on Multilingual Representation Learning (MRL 2025) (pp. 199-225)
• Su, H., Yen, H., Xia, M., Shi, W., Muennighoff, N., Wang, H. Y., ... & Yu, T. (2025, May). Bright: A realistic and challenging benchmark for reasoning-intensive retrieval. In International Conference on Learning Representations (Vol. 2025, pp. 48941-48991).
• Wang, D., Mo, G., Shi, Y., Zhang, C., Zheng, B., Cao, B., ... & Sun, L. (2026, July). All Languages Matter: Understanding and Mitigating Language Bias in Multilingual RAG. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 7441-7455).
• Xiao, Y., Dong, J., Zhou, C., Dong, S., Zhang, Q. W., Yin, D., ... & Huang, X. (2025). Graphrag-bench: Challenging domain-specific reasoning for evaluating graph retrieval-augmented generation. arXiv preprint arXiv:2506.02404.
• Xu, L., Su, Z., Yu, M., Li, J., Meng, F., & Zhou, J. (2025). Dense retrievers can fail on simple queries: Revealing the granularity dilemma of embeddings. Passages, 3024, 8.

First, we understood how Angular was able to "know" when to update the UI thanks to Zone.js, the component tree, and change detection strategies. Then we made the leap to Signals and saw how Angular began updating only what actually depended on reactive state.

• Change Detection Strategy: The Magic of Angular
• Angular Signals: The Evolution of Reactivity and Change Detection

In this third chapter we're going to close the loop. Because if Signals solved what needs to be updated… Zoneless completely changes when Angular decides to run change detection.

And yes: Angular can now run without Zone.js.

From "Angular detects everything" to "Angular detects only what's necessary"

In the first article we saw that Angular used Zone.js to intercept asynchronous operations:

• Clicks
• setTimeout
• HTTP requests
• Promises
• Browser events…

Every time any of those operations occurred, Angular triggered a full change detection cycle. The problem is that Angular didn't actually know whether anything relevant had changed.

It simply assumed:

"Something asynchronous happened. Just in case… I'll check the whole application."

And that worked really well, but it also meant unnecessary work.

The clock example

Let's follow exactly the same example from the previous articles. We have:

• A clock that updates every second
• A list of users.

@Component({
 selector: 'app-root',
 template: `
   <h2>{{ clock }}</h2>

   @for (user of users; track user.id) {
     <app-user-row [user]="user"></app-user-row>
   }
 `
})
export class AppComponent {
 clock = '';

 users = USERS;

 ngOnInit() {
   setInterval(() => {
     this.clock = new Date().toLocaleTimeString();
   }, 1000);
 }
}

In the first article we saw that:

• Every second, Angular traversed the entire tree
• Recalculated bindings
• Executed expressions
• Checked every component

Even though the users hadn't changed.

OnPush was the first patch

Then came ChangeDetectionStrategy.OnPush.

@Component({
 changeDetection: ChangeDetectionStrategy.OnPush
})

With OnPush, Angular stopped checking components "just because," and only checked them when:

An @Input changed

• An event occurred inside the component
• An observable emitted via async
• Or we manually called markForCheck()
  It was much more efficient, but we still depended on Zone.js because Angular still needed a global mechanism to say:

"Hey, something asynchronous just happened."

Signals changed the rules of the game

And this is where the big revolution arrived. With Signals, Angular no longer needs to "wonder" what changed, now it knows.

clock = signal('');
setInterval(() => {
 this.clock.set(new Date().toLocaleTimeString());
}, 1000);

In the template:

<h2>{{ clock() }}</h2>

Angular automatically registers which parts of the UI depend on each signal, and when the signal changes:

• Angular marks only the affected components
• It avoids traversing unnecessary branches
• It updates only the dependent bindings

This already meant a huge performance leap, but there was still an important question left: if Signals already knows exactly what changes… why do we still need Zone.js?

This is where Zoneless comes in

The short answer is that we don't need it as much anymore. Angular started introducing support for "zoneless" applications, that is, applications without Zone.js, and that completely changes the mental model.

What does Zone.js actually do?

Zone.js patches browser APIs to intercept asynchronous tasks:

• Timers
• Events
• Promises
• XHR
• Fetch
• etc.

Whenever any of those tasks finishes, Angular runs global change detection. The problem is that this comes with costs:

• More unnecessary work
• More detection cycles
• Worse startup
• Harder-to-read stack traces
• And more internal complexity

In fact, one of the main goals of Zoneless is to improve performance, Core Web Vitals, compatibility with modern APIs, and the debugging experience.

How does Angular work without Zone.js?

In zoneless mode, Angular stops "spying" on the entire browser. Instead, it only updates the UI when it receives explicit notifications. For example:

• A signal changes,
• An AsyncPipe emits
• An Angular event occurs ((click))
• markForCheck() is called
• An @Input receives a new value

In other words: Angular no longer does implicit polling of state. Now the framework itself knows exactly when something relevant has changed, and here lies probably the most important idea of this whole shift: Angular moves from an implicit reactive model to an explicit one.

Enabling Zoneless

Currently, Angular lets you enable it via:

bootstrapApplication(AppComponent, {
 providers: [
   provideZonelessChangeDetection()
 ]
});

And removing:

npm uninstall zone.js

Back to the clock example

Now, our example changes quite a bit.

@Component({
 selector: 'app-root',
 template: `
   <h2>{{ clock() }}</h2>
   @for (user of users(); track user.id) {
     <app-user-row [user]="user"></app-user-row>
   }
 `})
export class AppComponent {
 clock = signal('');
 users = signal(USERS);

 ngOnInit() {
   setInterval(() => {
     this.clock.set(
       new Date().toLocaleTimeString()
     );
   }, 1000);
 }
}

What happens now every second?

• Only clock changes
• Angular marks only that binding
• The user table doesn't even enter the cycle.

That "check the whole application just in case" no longer exists.

So… does Signals replace OnPush?

Not exactly. Signals and Zoneless greatly improve how Angular schedules change detection, but OnPush is still important.
Because Zoneless doesn't change how Angular traverses the component tree; what changes is when it decides to trigger change detection.

So:

• OnPush still helps limit checks
• Signals still marks specific components
• Zoneless avoids triggering unnecessary global cycles.

The three pieces complement each other, and in fact, the official documentation itself recommends OnPush as a natural step toward zoneless compatibility.

Something important: Angular still detects events

There's a very interesting detail here. Even if we remove Zone.js, this still works:

<button (click)="increment()">
 Increment
</button><br>

counter++;

Why? Because events registered through Angular still notify the framework automatically.

But be careful: this does NOT happen with APIs outside the Angular ecosystem. For example:

element.addEventListener('click', () => {
 this.counter++;
});

Here, Angular no longer knows that something changed, and we would need:

markForCheck()

Or use Signals.

What starts to "break" in Zoneless

This is where the theory gets interesting, because most current Angular applications indirectly depend on Zone.js's automatic behaviors.
And when we remove it… certain surprises show up. For example, this classic pattern stops working correctly:

this.userService.users$
 .subscribe(users => {
   this.users = users;
 });

If we then display users directly in the template, Angular might not notice the change, because the subscription happens outside any reactive mechanism Angular can observe.

The modern solution involves:

• Using the async pipe
• Converting observables to signals
• Explicitly calling markForCheck().

For example:

users = toSignal(this.userService.users$);

Here you can clearly start to see where Angular wants to go: less implicit magic and more explicit reactivity.

Another important detail is Reactive Forms. Operations like form.patchValue(...) still update the form's internal state… but no longer automatically force change detection.

Since which version has Zoneless existed?

Angular has been evolving this capability over several versions.

The real paradigm shift

Angular is leaving behind a "check just in case" model to move to a model based on explicit reactivity.

Much more predictable, much more efficient, and quite a bit closer to how modern frameworks like Solid or Vue Signals work.

Is it ready for production?

As of today, Zoneless is already part of Angular's official strategy, and the framework is clearly oriented toward this reactive model, but that doesn't mean any application can just remove Zone.js tomorrow without further thought. It's worth carefully validating:

• Third-party libraries
• Manual DOM integrations
• Legacy code
• Reactive forms
• SSR
• Testing
• Patterns based on implicit side effects

In fact, Angular strongly emphasizes that the future lies in Signals, the async pipe, OnPush, reactive APIs, and explicit notifications to the framework.

Conclusions

For years, Angular relied on Zone.js to detect any possible change in the application. Then came OnPush to reduce unnecessary work. Later, Signals appeared to enable much more precise reactivity.

And now Zoneless finishes closing that evolution by removing the need to constantly monitor everything happening in the browser.

The combination of Signals, OnPush, and Zoneless lets us build much more efficient, predictable, and easy-to-reason-about applications.

But it also requires a much better understanding of how the framework's reactivity actually works. Because Angular no longer tries to guess what's happening; now it expects us to be explicit, and that's probably the most important change of all.

References

Previous articles in the series

• Change Detection Strategy: The Magic of Angular
• Angular Signals: The Evolution of Reactivity and Change Detection

Official Angular documentation

• Angular Zoneless Guide
• Angular v18 Experimental Zoneless Guide
• provideZonelessChangeDetection API

Technical articles and analysis

• Angular 20 y el futuro sin ZoneJS: la revolución zoneless ha llegado a developer preview
• Zoneless Angular: What Works, What Breaks, and Why It Matters
• What Does Zoneless Angular Mean?

It's a well-known document. Obviously, its content isn't set in stone and it doesn't have the context of the Spanish market as such, but it does provide an overview of the state of the art and its trend, since if you follow it across its different volumes, you can see how the concepts it includes evolve.

I believe that at this moment of brutal change and uncertainty in the industry, consulting documents of this type and quality is of vital importance to know what is becoming a proven reality and what should be taken with caution.

The knowledge source: the Thoughtworks Radar

As I mentioned in the introduction, the Thoughtworks Radar is well known. You've probably checked it out more than once, but if not, I encourage you to do so because I find it very interesting, especially in these times of so much change and uncertainty.

Roughly every six months, they publish a volume with what they consider relevant. The volumes are extensive, detailed documents, about 45-50 pages each, organized around four fundamental pillars:

• Techniques
• Platforms
• Tools
• Languages and frameworks

For each pillar, a series of "interesting things or items" ("blips" in their terminology) are analyzed and classified into four levels:

• Adopt: the industry should adopt these items. They are items already consolidated in the sector.
• Trial: worth trying because it's important to understand how to develop these capabilities. Companies should test this technology on projects where the risk can be managed.
• Assess: worth exploring these items with the goal of understanding how they will affect the company.
• Hold: proceed with caution when implementing them.

What's really interesting isn't so much which blips are in each block, but the trend: which blips appear, which ones are "promoted" to trial or adopt, and which ones need to be treated with caution, either because their maturity indicates so or because risks or shortcomings have been detected that need to be taken into account.

The medium for the interview: an advanced RAG

As could hardly be otherwise these days, I relied on AI to conduct the interview, but not in the way you might initially think, using ChatGPT, Gemini, NotebookLM, or similar to analyze the radar and issue conclusions, but instead building a system that I tried to give as "human" a way of thinking as possible so that this would feel like a real interview.

The system is based on a 100% serverless architecture on AWS (Cloudfront, API Gateway, Lambda, Bedrock, Opensearch, DynamoDB, S3), which can be spun up and torn down via IaC.

The "core" basically consists of an advanced RAG with hybrid search (BM25 + vector embeddings) over a series of indexed sources (hierarchical chunking) in an AWS Bedrock Knowledge Base on Opensearch.

When a question is asked, the most relevant fragments of the corpus are retrieved and injected into the model's context together with a cumulative summary of the conversation (automatically generated by a lightweight model after each turn and persisted in DynamoDB), thereby maintaining the thread of the interview without relying on the model's native memory.

To try to give the system "a certain human behavior" and make it feel like a real interview, the system prompt is designed so that it acts as a person who works on producing the radar, a member of the Thoughtworks Technology Advisory Board (TAB), who is being interviewed.

For this PoC I decided to set the knowledge base within a roughly two-year time range, analyzing the last four volumes:

• 📊 Volume 31 (October 2024)
• 📊 Volume 32 (April 2025)
• 📊 Volume 33 (November 2025)
• 📊 Volume 34 (April 2026)

The UI, to which I tried to give a journalistic editorial style, allows you to configure both the most important query parameters (model, tokens, retrieved fragments, or even the system prompt) and to explore the radar by ring, quadrant, and edition.

It also allows you to export the full transcript as a PDF in a two-column newspaper-style format. At the end of the session, if needed, a second model generates a structured executive report (summary, key themes, trends, and recommendations) based exclusively on what was discussed during the interview.

I won't go into much more detail about the project in this article because that's not its purpose (the purpose is the interview itself), and I'll publish a more technical article soon with all the details.

Now, the interview

Now that I've laid out the context in which the interview takes place, let's move on to conducting it and asking the questions. I have to say that, in my opinion, it produced some very significant insights:

• Hello, let's begin this long-awaited interview. Let's start with the first question. This year, 2026, has been a dizzying one in terms of technology's impact, but from your point of view, how would you describe the evolution of the tech industry over the last few years, up to this current point?

Good question to kick things off. If I had to sum it up in one sentence: we've gone from enthusiastic experimentation to responsible engineering, but with a lot of noise along the way.

What we've observed across the last few editions of the Radar is an unprecedented acceleration, but with a recognizable pattern. Every technology cycle follows a similar curve: euphoria, saturation, and then — if the technology has real value — consolidation. With generative AI we've lived through that curve in fast-forward.

Three or four years ago, the debate was whether LLMs were anything more than a sophisticated toy. Then came the explosion of the ecosystem — RAG, vector databases, guardrails, agent frameworks — which in the 2024 Radar we already described as a "Cambrian explosion." It was chaotic, but it made sense: the initial simplicity of the text prompt was giving way to real software engineering.

This is the point we most want to emphasize: technology matures when it stops being magic and becomes discipline. And that's exactly what we're seeing now in 2026 with agents, with context engineering, with LLM evaluation patterns.

But we've also seen what didn't work as expected. We were initially optimistic about full autonomy for coding agents, and we've had to be honest: the supervised approach is still essential. Complacency with AI-generated code is a real, documented antipattern, backed by data.

One of the patterns we keep seeing is that the speed of the tools outpaces the maturity of the practices. And that has a cost: cognitive debt, AI-accelerated shadow IT, architectures that drift out of control.

The industry is in an exciting moment, but engineering fundamentals — testing, observability, architectural design — have never been more relevant than they are now.

• I find it very interesting what you said about "engineering fundamentals having never been more relevant than now." Why are they a key piece now? Haven't they always been?

Yes, they always have been. But there's a crucial difference between something being important and its absence being immediately catastrophic.

Before, if a team had low test coverage or a mediocre architecture, the damage accumulated slowly. There was friction, technical debt, but the system degraded gradually and visibly. Now, with coding agents generating massive changesets in minutes, that same lack of discipline can destroy a system's coherence within hours. Speed amplifies everything, the good and the bad.

This is where things get interesting. What we're documenting in the Radar as codebase cognitive debt isn't simply traditional technical debt. It's something more subtle and more dangerous: it's the loss of the collective mental model of how the system works. When the code is generated by AI and no one reviews it in depth, the team starts operating on a black box that they themselves built without understanding it. The GitClear data is fairly telling on this: more duplicated code, more churn, less refactoring.

And here's the paradox that worries us most: coding agents work best on well-structured, well-tested codebases with clean design. In other words, the practices that some teams were tempted to relax because "the AI will fix it" are exactly the ones that make the AI work well. Good design for humans is also good design for agents.

That's why in the latest Radar we put things like DORA metrics, context engineering, zero trust, and OpenTelemetry in Adopt. They're not new. They're reminders that without that foundation, the speed AI promises turns into compound debt.

What has changed isn't the importance of the fundamentals. It's the cost of ignoring them.

• Looking at how things have evolved over the last few years, what points do you consider key for the adoption of AI to be a success today in a company?

The first thing I'd say is that the most common failure we see isn't technical. It's organizational. Companies that are failing with AI don't fail because they chose the wrong model or the wrong framework. They fail because they tried to layer AI on top of a foundation that was already fragile.

That said, there are several patterns we've documented as critical.

First, treating context as an engineering asset, not an implementation detail. Context engineering is in Adopt in the latest Radar precisely because we've seen that organizations that do it well — that design context as a dynamic, managed pipeline — get qualitatively different results. Those that ignore it end up with agents hallucinating or behaving inconsistently.

Second, invest in feedback signals before scaling. DORA metrics in Adopt isn't nostalgia. It's a reminder that if you don't measure lead time, deployment frequency, and rework rate, you won't know whether AI is generating real value or just more code. And rework rate specifically is the canary in the coal mine for detecting accumulated cognitive debt.

Third, govern agents from the start. Zero trust architecture in Adopt for agents isn't optional. The "lethal trifecta" that Simon Willison describes — private data, untrusted content, external action — describes most useful agents by default. If you don't have least privilege and continuous monitoring from day one, you're building on sand.

And fourth, and this is perhaps the most counterintuitive part: the most successful companies are the ones that first invest in cleaning up their codebase and their engineering practices, and only afterward bring in agents. Not the other way around.

What we repeatedly observe is that AI amplifies whatever already exists. If you have discipline, it amplifies that. If you have chaos, it amplifies that too. And at a speed that leaves no time to react.

• In terms of technologies, over these last few years, which ones have fully settled in and which ones have fallen by the wayside or are fading out?

This is a question I love because the movement between rings is where you really see whether something has substance or was just noise.

The ones that have truly settled in:

OpenTelemetry is perhaps the cleanest example. It moved from Assess to Adopt almost inevitably, because it solved a real problem — observability fragmentation — with the right abstraction. When Datadog, New Relic, and Grafana all adopt the same protocol, you know something has won. That's not hype, that's genuine consolidation.

RAG — Retrieval-Augmented Generation — reached Adopt in record time. What surprised us wasn't the speed, but that the technique survived the scrutiny of production. It keeps evolving — GraphRAG, Corrective RAG, Self-RAG — but the core pattern held up.

And in tooling, things like Renovate or Vite: no glamour, no keynote talks, but in Adopt because they simply work and teams don't want to live without them.

The ones that are fading out or never took off:

SAFe is still in Hold, and with every edition the language gets harsher. It's not that it isn't used — it's used too much — but we still aren't seeing the results it promises.

Local coding assistants is an interesting case: they arrived with a lot of expectation for privacy reasons, but we put them in Hold because local models simply don't compete with cloud-based ones in agentic capabilities. Technical reality beat organizational desire.

And the most telling one: "Replacing pair programming with AI" in Hold. This is almost a statement of principle on our part. Not because AI doesn't help, but because it confuses individual speed with team health. Those are different things.

The pattern I see: what settles in solves real friction with durable abstractions. What fades out is usually either a solution looking for a problem, or a local optimization that ignores systemic consequences.

• What do you think are the main risks or antipatterns that have been detected over the last few years and that can do a lot of damage if no action is taken?

This is perhaps the most important question we can ask ourselves right now, because we're at a point where the speed of adoption clearly outpaces the speed of understanding the consequences.

The first and most dangerous one: complacency with AI-generated code. It's not new — we've had it in Hold for several volumes now — but it's getting worse. What used to be a developer reviewing Copilot suggestions is now an agent modifying dozens of files in parallel while the developer supervises at a high level. The risk of automation bias multiplies exponentially. And what you get isn't bad code — it's code that works but that no one fully understands. That leads us directly to the second antipattern.

Codebase cognitive debt. We recently introduced this term into Caution, and I think it's one of the most important concepts we've articulated in years. It's not classic technical debt — it's the gap between what the system does and what the team understands it does. With agents generating changes at high speed, that gap silently widens until one day a small change breaks something unexpected, and no one knows why.

Third: MCP by default. We explicitly put this in Caution. The pattern we see is: "I have an API, I turn it into an MCP server, done." Without thinking about the security model, without analyzing toxic flows, without asking whether you really need MCP or whether a CLI script solves the problem just as well. The naive conversion of APIs into MCP is an attack surface that most organizations aren't managing.

And fourth, one that worries me especially at the organizational level: AI-accelerated shadow IT. Non-coders building agentic workflows that process sensitive data, with no governance, no audit trail, without IT even knowing. The difference from classic shadow IT is the scale and the speed. What used to take months to become a critical problem now takes weeks.

The common pattern across all these antipatterns is the same: AI amplifies speed before the organization has built the necessary control mechanisms. And when something fails, it fails fast and at scale.

• I find these points very interesting, especially when there's talk of the disappearance of the developer role. And yet, you're detecting many risks associated with automatically generating most of the code without review, increasing technical debt. How does this really affect the developer role? Will this role end up disappearing, or will it become more important than it is now?

The narrative that "the programmer is going to disappear" is, frankly, one of the most irresponsible ones circulating right now. And I say that with conviction because the data we see in the Radar points in exactly the opposite direction.

What we're observing is a transformation of the role, not its extinction. And that transformation makes it, if anything, more critical and harder to do well.

Think of it this way: when an agent generates hundreds of lines of code in seconds, who decides whether that solution is architecturally correct? Who catches that the agent solved the problem with thirty nested conditionals instead of applying the Strategy pattern? Who understands the hidden coupling that change introduces? That requires more technical judgment, not less.

What does disappear — and this is important — is the developer who only knows how to write mechanical code, without understanding design, without understanding systems, without understanding trade-offs. That profile was already declining before AI. What's emerging is a developer who acts more like a systems engineer and technical director of agents: someone who knows how to specify intent precisely, who can evaluate output at a high level, who maintains the mental model of the whole system.

And here's the paradox that concerns us deeply: AI is lowering the barrier to entry at the same time as it's raising the bar for what it means to do it well. That creates an enormous gap. You'll have more people generating code, but fewer people capable of understanding what's been generated. And that gap is exactly what feeds the codebase cognitive debt we mentioned earlier.

**What the Radar consistently reinforces — pair programming, TDD, fitness functions, rigorous code review — aren't relics of the past. They're the mechanisms that let a team maintain collective understanding of the system while the speed of generation skyrockets.

The developer role doesn't disappear. It forks: those who deeply understand systems become exponentially more valuable; those who delegated that understanding to AI become dispensable. AI doesn't eliminate the need for technical judgment. It makes it more expensive when it's missing.

• On another note, you also mentioned "MCP by default," and I find that very interesting since there was, or still is, a boom around this concept, with MCPs popping up out of nowhere. What real risks does it carry to overuse this concept or use it when it's not really needed?

The MCP boom is a textbook case of what happens when a technology solves a real problem but the industry overextends it until it becomes a hammer looking for nails.

MCP has genuine value. When you need structured tool contracts, OAuth authentication boundaries, and governed multi-tenant access, it's the right solution. The problem is that we're seeing teams and vendors use it as a default integration layer, even when a well-designed CLI with decent --help output and structured JSON responses would achieve exactly the same thing without the protocol overhead.

The first real risk is what we call the "abstraction tax". Every protocol layer between an agent and an API loses fidelity. For simple APIs that's tolerable; for complex APIs, those losses accumulate. The agent receives an impoverished version of the original interface, and that translates into degraded behavior or increasingly elaborate prompts to compensate.

The second risk is a security one, and this is the one that worries us most. Internal APIs typically expose sensitive data or allow destructive operations. When a human developer consumes them, there's architecture, code reviews, and organizational context that mitigate those risks. When you do a naive API-to-MCP conversion and hand it to an autonomous agent, you remove those safeguards. There's no deterministic way to prevent the agent from misusing those endpoints. And here the lethal trifecta shows up again: private data, untrusted content, external action. Most useful MCP servers meet all three by default.

The third risk is unnecessary operational complexity. MCP introduces maintenance, versioning, and governance overhead. If you adopt it without needing it, you're paying that cost without getting the benefit.

What we recommend is a mandatory question up front: does your system really require protocol-level interoperability? If the answer isn't a clear "yes," a well-designed CLI or a direct function call is the better option. MCP has its place, but that place isn't "everywhere."

• I'd also like to talk about the last risk you mentioned, "AI-accelerated shadow IT." How does this actually affect an organization? What implications does it have in every sense, including costs or security?

This is one of the risks that worries us most precisely because it doesn't look dangerous until it's already too late.

What we're observing is a turbocharged version of something that already existed. Spreadsheets that "silently run the business" have been a problem for decades. But now, with tools like Claude Cowork, n8n with AI API integrations, or simply a product manager with access to a coding agent, the jump from "informal automation" to "ungoverned critical system" happens in days, not months.

The organizational impact is multidimensional.

On security, the core problem is that these systems are built with no threat modeling, no permissions review, no secrets management. An n8n workflow that connects Slack to a CRM via OpenAI could be exfiltrating customer data without anyone knowing. And here's the lethal trifecta again: private data, untrusted content, external action. That workflow meets all three by default.

On costs, the problem is invisibility. Finance teams don't see the calls to model APIs piling up on corporate cards or personal cloud accounts. We've seen organizations with dozens of parallel integrations making redundant calls to GPT-4 because no one knew the team next door had already solved the same problem.

On technical debt and governance, what starts as a throwaway prototype turns into critical infrastructure. No one documents it, no one tests it, and when the original creator leaves, no one knows how it works. It's exactly the Excel-macro pattern, but with the ability to execute actions on external systems.

What we recommend isn't banning it, but channeling it. Instrumented internal sandboxes where non-developers can experiment with visibility. A shared catalog of existing workflows to avoid duplication. And clear criteria for determining when a prototype needs to become a production application with real engineering behind it.

AI democratizes software building. That's genuinely valuable. But democratizing without governing is simply accelerating chaos.

• Thank you so much for all this valuable information you've given us. To wrap up the interview, in a few words, what do you think both industry professionals and companies need to keep in mind in order to survive this tsunami that's already here?

What we've learned from all these Radar cycles can be condensed into something that might sound paradoxical: the best way to adapt to AI's speed is to invest in what doesn't change.

Engineering fundamentals — clean code, testing, deliberate design, short feedback loops — aren't nostalgia. They're exactly what allows AI to amplify value instead of amplifying chaos. We've seen it over and over.

For professionals, the message is clear: don't compete with AI on code-generation speed. Compete on judgment. On the ability to ask the right questions, to spot when an agent is heading down the wrong path, to understand the whole system. That's what AI can't replace yet, and it's what holds the most value right now. Invest in deeply understanding the systems you build, not just in building them faster.

For companies, the costliest mistake we can see is treating AI as an individual productivity initiative instead of a systemic transformation. If you introduce agents on top of broken processes, undisciplined codebases, teams with no feedback culture, you're simply going to reach disaster faster.

And there's something I think is critical for both: learning to distinguish between speed and progress. More PRs, more lines of code, more automated workflows aren't progress if the rework rate goes up, if no one understands what's been built, if cognitive debt piles up silently.

The tsunami is already here, yes. But those who survive won't be the ones who swim fastest. They'll be the ones who know when to swim, when to stop, and when to change direction.

If you'd like to have the interview content in PDF, you can download it directly.

% text:Conclusions
% level:2
% type:--h30-15-400
% align:left
% endblock

In my opinion, one of the most relevant conclusions is that engineering fundamentals (testing, observability, or architectural design) have never been more critical than now, not because they are new, but because their absence has immediate, large-scale consequences in an environment where agents can generate new code and massive code changes within minutes.

I like how the interview concludes with a clear message, both for professionals and for organizations, that the best way to adapt to AI's speed is to invest in what doesn't change. The key isn't to compete with AI on generation speed, but on judgment, technical criteria, and a deep understanding of systems.

In my opinion, and I believe I share the Radar's view, companies that treat AI as an individual productivity initiative instead of a systemic transformation run the risk of reaching disaster faster.

I hope you enjoyed the approach I took with this article, and as I mentioned, we'll publish another article with the "making of," the repository, and the technical details of the RAG used. I'll read you in the comments! 👇

We also reviewed the limitations of that approach, which forced the stochastic transition of the 1980s and 1990s, where statistical models (n-grams and HMMs) started inferring information directly from data. These models quickly ran into data sparsity and the semantic blindness of one-hot encoding.

In this post, we will look at the introduction of concepts like Word2Vec, Recurrent Neural Networks (RNNs), and Long Short-Term Memory (LSTM) networks.

The Distributed Representation Revolution: Word2Vec

Traditional systems assigned an arbitrary index to each term, creating massive matrices where semantic relationships completely disappeared. This lack of connection prevented software from extracting real value from unstructured data. In 2013, a research team led by Tomas Mikolov introduced Word2Vec.

Word2Vec proposed a model based on shallow neural networks that allows us to represent words in a continuous space, as dense vectors (usually between 50 and 300 dimensions, instead of tens of thousands). This model improved semantic relationships and word nuances with high precision.

Word2Vec transformed plain text into dense vectors within a continuous space and enabled similar concepts to coexist in nearby mathematical regions.

The Word2Vec architecture introduced two predictive model variants to compute continuous word representations from large text corpora:

• Continuous Bag-of-Words (CBOW): the neural network predicts the probability of a current target word based on the context window of surrounding words.
• Skip-Gram: operates on the inverse principle of CBOW. It uses the current word to predict surrounding words within a given range or window.

Thanks to this approach, it became possible to capture semantic and syntactic pattern analogies, such as the famous vector equation: “king – man + woman ≈ queen”.

The model deduced, without external instruction, the vector representing the concept of "royalty" and the vector for "gender," allowing it to navigate the lexicon as if it were a map of geographic coordinates.

All this through simple vector operations and cosine similarity measurements, without resorting to computationally expensive processes.

Its low computational cost and open-source availability, published freely for the research community, almost instantly drove the adoption of embeddings across the entire NLP spectrum.

This milestone paved the way for Deep Learning architectures, specifically Recurrent Neural Networks (RNNs) and, later, models based on the Transformers architecture (Church, 2017).

The Arrival of Deep Learning (DL) and Context Management: Recurrent Neural Networks (RNNs)

Having overcome the challenge of giving meaning to isolated words, the next big challenge was understanding context. Language is, by nature, a temporal sequence.

Here, the order of factors does alter (and drastically) the outcome. That is why a conversational system cannot treat text as simple unordered bags of words; it needs a dynamic memory capable of evolving at the same pace as the sentence itself.

DL revolutionized the field of NLP by enabling the development of much more efficient and powerful models for managing sequential data. Among the multiple DL architectures, RNNs stand out—they were introduced in the 1980s as an improvement over traditional neural networks.

Unlike traditional networks, where information flows unidirectionally from the input layers to the output layers, RNN architectures introduced recurrent connections in their hidden neurons.

This recurrence worked as a short-term memory that provided the system with continuous context. In this way, when processing a sequence, RNNs naturally began capturing the temporal dependencies of the text.

However, when implementing deep RNNs in complex tasks like generative chatbots, research teams noticed the vanishing gradient problem, a phenomenon that completely sabotaged the system's long-term memory.

During training, via the backpropagation through time algorithm, error calculations require iteratively multiplying weight matrices. If those values are less than one, the gradient shrinks exponentially until it vanishes from the equations.

The practical consequence was a scenario where chatbots forgot the beginning of the sentence by the time they reached the second paragraph of the dialogue. Traditional RNNs were unable to connect an initial prompt with a final response if the sequence exceeded a certain word limit, ultimately degrading the user experience.

The Long-Term Solution: Long Short-Term Memory (LSTM) Networks (1997)

To solve the vanishing gradient problem, researchers Sepp Hochreiter and Jürgen Schmidhuber developed Long Short-Term Memory (LSTM) networks in 1997, an architecture that would redefine sequential processing.

LSTMs were capable of preserving relevant information over significantly longer periods of time. Instead of allowing new data to overwrite previous context, they established a central memory channel protected by three neural network gates:

1. Forget gate: discards obsolete information through filtering that cleans noise from the system. It analyzes the context of the current word and the previous state to return a value between zero and one.
2. Input gate: selects new data worthy of being incorporated into long-term memory, preventing storage space from being saturated with irrelevant terms.
3. Output gate: determines what portion of the accumulated context should be passed on to the next sequential step, regulating the immediate response inherited by the system.

The integration of these structures helped mitigate the vanishing gradient problem almost entirely. This allowed for more coherent conversational modeling, where an artificial agent could remember a user's name or intent across multiple dialogue turns.

Conclusions

In this post, we have analyzed how the success of conversational systems depended on striking a delicate balance between semantic representation and memory management.

While Word2Vec transformed word meaning into accessible coordinates, RNN and LSTM architectures enabled machines to capture the sequential and temporal nature of human language.

However, the quest for an even deeper and more scalable understanding did not stop there.

In the next post, we will take the big leap into the modern AI era, where we will analyze the arrival of Seq2Seq models, the birth of attention mechanisms, and the Transformers architecture.

See you in the next installment!

References

• LSTM
• Fundamentals of Recurrent Neural Network (RNN) and Long Short-Term Memory (LSTM) Network

With regulations like the CSRD kicking in and the push for ESG compliance mounting, sustainability has shifted from a corporate talking point to a hard architectural constraint and testing requirement.

In this roundup, we’re unpacking Green QA, analyzing the five layers of its deployment framework, and breaking down the core KPIs needed to spot energy inefficiencies across your cloud infrastructure.

We’ll also share actionable strategies to transition toward a contextual testing model, completely stripping out wasted compute cycles from your CI/CD pipelines.

Let’s get into it. 👇

What Is Green QA? Quality That Breathes

Green Quality Assurance (Green QA) redefines testing to curb power consumption and the software's carbon footprint without sacrificing test rigor. This framework ties quality engineering directly to ESG criteria and the EU’s CSRD mandate by measuring raw technical impact in watts and carbon emissions. Operationally, it drives teams to streamline test automation suites, eliminate bloated API overhead, and audit cloud infrastructure—making it a critical discipline for aligning modern software development with sustainability targets.

The Green QA Framework: Quality that Breathes

Adopting Green QA requires a clear, structured methodology. In this post, we unpack the five core pillars of the framework—governance, processes, data, technology, and continuous improvement—while introducing a TMMi-inspired maturity model. This approach establishes a shared-responsibility model across dev and compliance teams, leveraging specialized tooling like Scaphandre for power metering and dedicated SonarQube plugins for static code analysis. Ultimately, it serves as a practical playbook for automating carbon tracking directly inside your CI/CD pipelines.

Green QA Metrics: Quality That Breathes

This post wraps up our Green QA series, zeroing in on how to leverage KPIs and OKRs to root out energy drains and digital waste. We’ve bucketed these metrics into four core areas: technical efficiency (energy intensity and compute cycles), environmental impact (carbon footprint per release), ESG compliance, and operational optimization (purging zombie tests and redundant datasets). Finally, we break down the mechanics of auditing this data under frameworks like CSRD, the GHG Protocol, and ISO 21031, ensuring high-level compliance metrics map directly to verifiable technical telemetry.

The starting point is an uncomfortable question: if tomorrow you were given complete freedom to redesign your platform with environmental, social, and governance requirements as a fundamental condition, would you still make the same decisions you make today? From there, we built a map of eight key technology decisions where this integration is both possible and necessary.

The conclusion? Choosing technology means choosing the future. Purpose-driven platforms are not more expensive or slower; they are more competitive, and the organizations that understand this first will gain an advantage that is difficult to replicate.

Purpose-Driven Technology Platforms: Embedding ESG Criteria from the Start

Would you make the same technology decisions if ESG were a design requirement rather than an afterthought? This question kicks off the series. We explain why environmental, social, and governance criteria have evolved from a strategic complement into a core business concern, and we introduce the map of eight key technology decisions for building truly purpose-driven platforms.

Purpose-Driven Technology Platforms: Aligning Technology, Business, and Sustainability

We take a deeper look at the first four pillars of the framework: sustainable cloud architecture, responsible AI, inclusive design, and interoperable platforms. Each decision has a direct impact on the three ESG dimensions and, far from being a cost, generates tangible competitive advantages: reduced carbon footprint, greater regulatory trust, broader market reach, and the elimination of silos that hinder innovation.

Purpose-Driven Technology Platforms: Governance, Security, and Digital Resilience

We complete the framework with the four pillars that ensure the integrity and continuity of the digital ecosystem: data governance and traceability, cybersecurity and resilience, ESG integration across the supply chain, and software lifecycle optimization. Because a purpose-driven platform is not only built responsibly—it is also managed and protected with the same level of awareness.