Nicolas Dabène — AI-Native E-commerce Architect - English

The Era of Orchestration: Why 2026 Marks the End of Code as We Know It

Thu, 07 May 2026 12:30:00 +0000

In February 2026, Andrej Karpathy triggered what the industry now calls the Breakpoint of software engineering. His assessment is unequivocal: the programming profession is undergoing radical « refactoring ». For the modern developer, the feeling of experiencing a « Skill Issue » has become chronic—not due to lack of talent, but because tools evolve faster than our mental frameworks. We must face the truth: code is no longer the output; it’s the residue. The challenge is no longer writing syntax, but mastering Agentic Engineering.

1. The Shipwreck of Pure Autonomy: The Devin Case

2025 buried the myth of the totally autonomous agent. The Devin case became a cautionary symbol of the costly « black box ». Despite the promises, real-world success rates on complex tasks (measured by SWE-bench) stagnated between 13.8% and 15%.

The massive rejection of Devin by engineering teams in 2026 stems not merely from technical failures, but from an architectural control deficit and unacceptable economic opacity. At $500/month per seat plus $2 per ACU (Agent Compute Unit), companies realized that blindly delegating to an AI that « charges ahead » without alerting human supervisors was financial suicide. The market is shifting toward structured control models like Intent, where developers validate each planning step.

💡 The insight — The problem isn’t the agent’s intelligence, but the absence of a control harness.

2. The « Harness » Outperforms the Model: Amazon Kiro’s Approach

A system’s intelligence no longer resides in the LLM’s raw power, but in its support infrastructure: the Harness. A mediocre model with rigorous execution harness will always outperform the largest model left to its own devices.

This agentic stack rests on four critical layers:

Context: Semantic indexing (RAG) of hundreds of thousands of files.
Planning: Decomposing intent into logical sub-tasks.
Execution: Interacting with the world via MCP (Model Context Protocol) and Agent Hooks (automatic triggers on file events).
Learning: Persistent memory that prevents error repetition.

The prime example of this rigor is Amazon Kiro. Unlike intuitive coding, Kiro enforces a « Spec-driven » flow: transforming prompts into structured requirements using EARS format (When X, the system shall Y), followed by visual design via Mermaid, before any line of code.

Sources : Andrej Karpathy - Breakpoint, Amazon Kiro, SWE-bench

3. The Toxicity of « Vibe Coding »: The 90-Day Wall

Vibe Coding — the practice of coding « by feel » through prompt iterations without architectural vision — delivers misleading initial euphoria. It’s a high-velocity drug that masks explosive technical debt. A major study on 8.1 million pull requests confirms that ungoverned AI adoption increases technical debt from 30% to 41%.

The cycle is ruthless:

Phase	Symptom
Day 1	Development speed multiplied by ten
Day 30	Duplicated logic appears, coherent error handling disappears
Day 90	The wall. Code becomes « hostile ». Modifying a minor function triggers bug cascades no one can resolve

Dimension	Vibe Coding (Initial)	Long-Term Maintenance	Structured Control (Intent/Kiro)
Input	Vague natural language	Deep understanding	Structured specifications (EARS)
Quality	« Happy path » only	Systemic fragility	Edge case coverage
Control	Speed illusion	Refactoring wall	Human validation at each step

⚠️ The warning — Vibe Coding kills maintainability. It’s the fastest route to the Technical Debt Ramp.

4. Micro-societies of agents: The MiroFish Explosion

Innovation no longer requires armies of engineers. In just ten days, a student at China’s University of Posts and Telecommunications, Guo Hangjiang, built MiroFish. With $4 million in funding from Chen Tianqiao (30 million yuan), this project illustrates the radical democratization of technological power.

MiroFish uses the OASIS framework to create not a chatbot, but a massive social simulation. By creating thousands of agent personas with persistent memories (via Zep Cloud), the system produced a credible ending to the literary masterpiece Dream of the Red Chamber. This shift from « answering a question » to « problem-solving via simulation » marks the future of public opinion prediction and market analysis.

💡 What changes — We move from the « I ask a question » paradigm to the « I run a simulation » paradigm.

5. Don’t Build a Mega-Agent, Orchestrate a Team

The fatal mistake in 2026 is trying to create an omniscient agent. Context saturation inevitably leads to hallucination. Software survival depends on collaborative architecture patterns:

Parallel Pattern (Swarms)

Ideal for massive research and divergent data analysis. Multiple agents simultaneously explore different branches of a problem.

Sequential Pattern (Pipeline)

For rigorous production. Each step validates the previous before moving to the next: Research → Writing → QA.

Supervisor Pattern

The core of ASD (Agentic Software Development). A coordinator agent decomposes tasks, delegates to specialists, and handles error recovery. This supervisor transforms stochastic chaos into reliable engineering.

💡 The key point — The Mega-Agent is a myth. Orchestration is the reality.

Conclusion: Toward « Software for One »

The developer’s role has shifted. You no longer write code—you orchestrate intent. We’re entering the era of Software for One: the ability to generate unique applications, throwaway or permanent, meeting an instant need.

Code has become a commodity; intent architecture is your new added value. If you could orchestrate a team of 1000 agents to solve a complex problem tomorrow, what would be the first step in your specification? The answer to this question defines your future in this new era.

The question to ask — Are you a developer who writes code, or an architect who orchestrates intent?

Nicolas Dabène — Architect of AI-native e-commerce transition & developer of MCP Tools Plus for PrestaShop. Certified PrestaShop expert with over 15 years of experience.

The Orchestrator Developer #4 — The New Profession: Frame, Orchestrate, Arbitrate

Tue, 05 May 2026 06:00:00 +0000

The Orchestrator Developer #4 — The New Profession: Frame, Orchestrate, Arbitrate

Since the beginning of this series, I’ve been defending a simple but structuring idea.

Agentic AI doesn’t just transform web development tools. It also transforms the nature of the work. It changes what we produce, but above all how we produce it, the control we keep over it, and the skills that gain value.

In the first article, I explained why agentic AI truly changes web development: because it brings AI into the real workflow, and from that point on, we’re no longer talking about simple assistance, but framed execution.

In the second, I explained why a single agent isn’t enough: because real projects demand specialization, handoffs, distinct validations, and a responsibility architecture.

In the third, I explained why skills, context, and method change everything: because quality doesn’t come from the model alone, but from the framework in which you make it work.

The fourth article is the logical consequence of all this.

If agentic AI changes work organization, if a single agent isn’t enough, and if quality depends on context, skills, and method, then another conclusion follows: the developer profession is itself shifting.

Not disappearing.
Not dissolving.
Not becoming secondary.

Shifting.

And this shift deserves to be named.

The Developer Isn’t Replaced, They’re Refocused on What Really Matters

A large part of the public debate around AI remains trapped between two caricatures.

The first says developers will be replaced. The second responds that AI remains too imperfect to threaten anything serious.

Both readings are too short.

The first underestimates the depth of real work. The second underestimates the speed at which this work can be recomposed.

What I see emerging is neither the end of the developer, nor the pure and simple continuation of the profession as it existed a few years ago. What I see is a progressive refocusing of value.

Some tasks become more accessible to assisted automation. Generating a codebase, proposing variants, accelerating documentation, quickly exploring multiple paths, drafting first versions, producing repetitive structures, preparing tests or simple fixes: all of this becomes easier to delegate, assist, accelerate.

But as this raw production becomes commoditized, something else grows in importance.

Understanding the real need.
Choosing the right level of breakdown.
Knowing what needs to be made explicit.
Determining what can be entrusted and what must be verified.
Identifying risk zones.
Maintaining overall coherence.
Arbitrating between speed and robustness.
Maintaining quality in a faster, more distributed work system.

That’s where value reconcentrates.

The useful developer doesn’t disappear. They become more responsible for the shape of the production system than for each line produced manually.

What Gets Commoditized Isn’t the Profession, but Part of Its Surface

That’s an important nuance.

When people say AI changes the profession, some immediately hear that the profession loses value. In reality, it’s not that simple. What loses rarity isn’t development as a whole. It’s mostly a part of its production surface.

Quickly producing a base structure becomes less differentiating. Reformulating a piece of logic becomes less rare. Generating an additional variant becomes less costly. Formatting a first level of documentation becomes less impressive. In short, everything that falls under relatively standardizable production tends to become commonplace.

But this commoditization doesn’t eliminate difficulty. It displaces it.

The problem is no longer just writing something. The problem is making a system that can now write a lot, fast, and sometimes in a deceptively convincing way, produce correctly.

In other words, when generation becomes easier, selection, structuring, and validation become more strategic.

That’s exactly what many professions have already experienced in other forms. When a production capability democratizes, real value often rises toward direction, coherence, quality of judgment, and control of the final result.

Web development is entering this logic too.

The New Point of Tension Is Arbitration

There’s one skill that becomes particularly important in this new landscape: arbitration.

An agentic system can propose multiple options. Multiple implementations. Multiple architectures. Multiple ways to break down a task. Multiple trade-offs. Multiple ways to work around a constraint. Multiple interpretations of a still-fuzzy need.

From a distance, this looks like formidable abundance. Up close, it creates a new type of pressure.

Because someone has to decide.

Someone has to choose the acceptable version, not just the possible version. Someone has to distinguish the fastest solution from the healthiest solution. Someone has to know when an elegant proposal is actually too fragile. Someone has to spot when the system has answered the request… but not the real problem.

That’s where arbitration becomes central.

And this arbitration isn’t a “managerial” add-on placed above technique. It’s a deeply technical act, because it requires understanding side effects, maintainability, security, coherence, compatibility, the future cost of certain decisions, and the real solidity of the proposed paths.

The more systems become capable of producing quickly, the more the judgment that selects, corrects, and validates gains value.

Framing Becomes a Full-Fledged Production Skill

For a long time, many developers saw framing as a preparatory step, sometimes necessary, sometimes a bit frustrating, before “the real work,” the one that consists of building.

With agentic AI, this hierarchy becomes much less obvious.

Because a tool-equipped system, if poorly framed, can produce enormous amounts of useless, unsuitable, or costly-to-review output. Conversely, a well-framed system can accelerate very strongly without sacrificing meaning.

As a result, framing changes status. It’s no longer a preamble. It becomes a direct lever of quality and productivity.

Framing well isn’t just reformulating a request. It’s clarifying what really matters. It’s reducing ambiguity usefully. It’s setting the right boundaries. It’s avoiding turning business fuzziness into premature technical certainty. It’s defining verifiable output expectations. It’s deciding at what level you’re asking for exploration, implementation, review, or control.

In short, framing becomes a way of producing better.

And that changes the profile that gains value in a team. Not just the one who executes fast, but the one who knows how to prepare a clean execution space.

The word “orchestration” can sometimes give the impression of comfortable, almost distant supervision, as if the developer simply distributed tasks to agents before harvesting the result. That’s not what I mean by it.

Orchestrating isn’t saying “do this” to a collection of tools and waiting. Orchestrating is building a work chain where each step has a clear function, an adapted context level, understandable success criteria, and coherent articulation with the others.

This requires very concrete decisions.

Should you start by exploring or specifying?
Should you produce a first base before review, or go through a stronger framing step?
Should you clearly separate implementation and validation?
At what point do you inject security constraints?
When should you interrupt a chain to prevent it from propagating a bad assumption?
Which results are reliable enough to move to the next stage?
What must remain under mandatory human review?

Orchestration is therefore not an abdication of technique. It’s a higher-level technique.

It demands less fascination with tools and more mastery over the conditions in which they work.

The Orchestrator Developer Remains a Developer

This is an important point, because it helps avoid a misunderstanding.

When I talk about the orchestrator developer, I’m not talking about a profile that has left technique to become a kind of vague coordinator. I’m talking about a developer who remains deeply anchored in the reality of code, architecture, project constraints, bugs, quality trade-offs, dependencies, maintenance, security, deliverables.

Simply put, this developer no longer draws all their value from their sole ability to produce each piece by hand.

They increasingly draw their value from their ability to make an AI-enriched production system work correctly.

They understand what is produced.
They understand why it was produced that way.
They understand what needs to be verified.
They understand where the system can lie, drift, or oversimplify wrongly.
They understand when to accelerate and when to brake.

That’s precisely why this role remains deeply technical. It’s not less technical than traditional development. It’s technical differently, with an additional level of structuring, discernment, and responsibility.

Final Responsibility Cannot Be Outsourced

This is perhaps the most important point of all.

In a lot of discourse around AI, you can sense a temptation: to imagine that responsibility could follow delegation. As if, as you entrust more work to agents, part of the weight of judgment could dissolve with it.

I don’t believe in this reading.

You can delegate part of the execution. You can accelerate part of the production. You can automate certain sequences. You can assist, enrich, structure, distribute. But you cannot outsource responsibility for the final result.

Someone must remain accountable for the quality delivered.
Someone must accept the fact that a choice was made.
Someone must be able to explain why this option was chosen over another.
Someone must carry the coherence of the product, the project, the architecture, and the risks.

That’s precisely where the orchestrator developer distinguishes themselves. They don’t use agents to fade away. They use them to build a more powerful system, while keeping responsibility for what matters.

This nuance is decisive. Because it makes all the difference between a truly augmented team and a team simply fascinated by automation.

Freelancers, Agencies, and Teams Won’t Be Impacted the Same Way, but All Will Be Affected

This transformation won’t have exactly the same effects everywhere. But it won’t spare anyone.

For a freelancer, agentic AI can become a formidable capacity extension. It allows exploring faster, preparing better, testing wider, documenting more cleanly, producing solid bases more quickly. But it also forces leveling up on framing, method, review, and assumed responsibility. The freelancer who simply “makes produce” without finely organizing the system will take risks very quickly.

For an agency, the question becomes even more structural. Agentic AI directly touches how work is distributed, how standards are transmitted, how best practices are industrialized, how deliverables are made reliable, and how team experience is transformed into a reusable asset. The challenge isn’t just individual. It becomes organizational.

For an internal product or technical team, the transformation is often read in workflows, validation criteria, review rules, acceptable automation zones, skill repositories, and project context quality. Here too, maturity won’t come just from the tool adopted, but from how the team recomposes its work system.

The common point remains the same: value will rise toward those who know how to structure.

What Will Distinguish the Best Profiles in the Years to Come

I think the strongest profiles won’t just be those who know how to “use AI,” a formula that has become far too broad to be truly useful.

The best profiles will be those who know how to:

transform a fuzzy request into an exploitable work space;
distinguish what should be automated from what should be arbitrated;
build readable work chains;
preserve quality under acceleration;
stabilize reusable skills and patterns;
detect zones where AI becomes deceptively convincing;
maintain a high level of responsibility for the final result.

In other words, they’ll know less how to “trust the machine” than how to properly organize the conditions in which this machine can be useful.

That’s where a large part of the differentiation will be played out.

Not in enthusiasm.
Not in the number of tools tested.
Not in the quantity of code generated.
But in the quality of the work system put in place.

The Profession Doesn’t Shrink, It Gains Density

You might think that agentic AI simplifies the developer profession by removing part of the work. In the short term, it simplifies certain tasks, yes. But in the longer term, it densifies the profession.

Because it forces you to be more explicit.
Because it pushes you to better formalize.
Because it makes visible skills that sometimes remained implicit.
Because it puts the quality of human judgment under tension.
Because it transforms context, method, and organization into real production assets.

The developer who adapts to this doesn’t become less important. They become more strategic.

Their role is no longer just to produce. It’s to guarantee that a more powerful production system remains aligned with the reality of the need, the project’s requirements, and the expected quality.

That’s why I talk about the orchestrator developer.

Not as a trendy phrase. As a name to designate the point where value shifts.

As I explained in I Stopped BMAD, method isn’t an accessory — it’s the foundation. And this foundation is precisely what the orchestrator developer builds and maintains.

Conclusion

Agentic AI doesn’t sign the end of the developer. It shifts the profession’s center of gravity.

What loses some rarity is a part of raw production.
What gains strongly in value is the ability to frame, orchestrate, and arbitrate.

Frame, to create a clear work space.
Orchestrate, to structure a reliable production chain.
Arbitrate, to keep quality, coherence, and responsibility where they must remain.

The developer who will matter tomorrow won’t just be the one who knows how to write code. It will be the one who knows how to intelligently organize a production system enriched by agents, without ever renouncing their judgment.

That’s precisely why I think the real rising profession isn’t that of a replaced developer, but that of an orchestrator developer.

End of the Series

The Orchestrator Developer #1 — Why Agentic AI Truly Changes Web Development
The Orchestrator Developer #2 — Why a Single Agent Is Not Enough
The Orchestrator Developer #3 — Why Skills, Context, and Method Change Everything
The Orchestrator Developer #4 — The New Profession: Frame, Orchestrate, Arbitrate

Nicolas Dabène — Architect of AI-native e-commerce transition & creator of AI solutions for PrestaShop. Book a strategy call to explore how AI can transform your business.

The Orchestrator Developer #3 — Why Skills, Context, and Method Change Everything

Thu, 30 Apr 2026 06:00:00 +0000

The Orchestrator Developer #3 — Why Skills, Context, and Method Change Everything

In the first article of this series, I explained why agentic AI truly changes web development. In the second, I showed that a single agent isn’t enough. But if we stop there, we’re still missing the heart of the matter.

Because once you’ve said that you need multiple roles, multiple steps, multiple controls, another question appears immediately: what actually determines the quality of an agentic system?

Many still answer too quickly: the model.

The best model.
The strongest model.
The fastest model.
The most impressive model on benchmarks.
The model that “reasons” best.
The model that codes best.

Of course, model quality matters. It would be absurd to claim otherwise. But in practice, that’s almost never where the decisive difference is made.

The real difference happens elsewhere.

It happens in the context you give the system.
In the skills you stabilize around it.
And in the method you impose on its work.

In other words, an agent doesn’t become useful simply because it runs on a good model. It becomes useful when it operates within a framework solid enough to produce reliable results.

And that’s probably one of the biggest current misunderstandings around AI in web development.

The Model Alone Isn’t Enough to Create Quality

It’s a very understandable temptation. As models improve, the more you want to believe they’ll naturally solve quality problems through their raw power alone.

That would be comfortable. You’d just need to pick the right market player, the right interface, the right integration, and the mechanics would follow on their own.

But in a real project, things don’t work that way.

A model, even an excellent one, doesn’t spontaneously arrive with the right business understanding. It doesn’t arrive with a team’s implicit memory. It doesn’t arrive with a list of errors already encountered on the project. It doesn’t arrive with an understanding of in-house conventions, client sensitivities, historical compromises, technical debt zones to avoid, parts of the code you shouldn’t touch too quickly, or the validations essential before a production deployment.

It arrives with generalization power.
Not with intimate knowledge of your living system.

That’s an essential difference.

Because it explains why a very impressive model can produce a brilliant answer in the abstract, yet completely unsuited to your real context. Not necessarily wrong in the strict technical sense. Simply misplaced. Miscalibrated. Mis-prioritized. Poorly connected to the system it needs to live in.

And in web development, this type of misalignment is costly.

It’s not always spectacular. It’s not necessarily the big bug that breaks everything immediately. Often, it’s more diffuse: a bad abstraction, an ignored convention, an overly light security assumption, a code structure that seems clean but complicates maintenance, a design decision made too quickly, an elegant response that forgets a central business detail.

That’s where you understand that quality doesn’t come only from the model’s apparent intelligence. It comes from its ability to work within a properly structured context.

As I explained in The Illusion of Disposable Code, production speed is worthless if the result isn’t maintainable over time.

Context Isn’t an Add-On, It’s the Primary Material

Context is often talked about as a kind of secondary fuel. In reality, you almost need to reverse the hierarchy.

In a mature agentic system, context isn’t just something you “add” to slightly improve outputs. Context is what transforms a general capability into useful work.

Without context, an agent improvises.
With weak context, it extrapolates.
With fuzzy context, it rationalizes.
With poorly prioritized context, it mixes the important and the accessory.

Conversely, when context is well constructed, many things change. The agent better understands what it should optimize. It more quickly spots what’s stable and what isn’t. It knows better which conventions to follow. It more easily avoids off-the-shelf solutions. It produces less noise. It becomes less spectacular, perhaps, but much more useful.

That’s also why so many agentic demos impress more than they reassure. They show capabilities. They show less of context governance. Yet it’s precisely this governance that makes the difference between a demo system and a production system.

Useful context, moreover, isn’t just documentary. It’s not just “putting a lot of information in the window.”

Good context is sorted.
Structured.
Prioritized.
Situated.
Oriented toward the expected action.

It contains what’s needed to decide. Not everything you can accumulate.

That’s a fundamental point, because it reminds us that an agent doesn’t need more noise. It needs better reference points.

What Teams Hold in Their Heads Must Become Transmissible

In many teams, a considerable portion of quality still relies on knowledge embedded in people. Reflexes. Habits. Weak signals. Useful “unspokens.” Rules you don’t always write down, but that good profiles have internalized.

The problem is that an agentic system doesn’t naturally benefit from this ambient intelligence.

What’s distributed across human experience must be made transmissible one way or another.

This is where many strategies fail. They assume the model will compensate for what hasn’t been explicitly structured. Sometimes it manages. Often it simulates. And very regularly, it produces an appearance of coherence where an experienced human would have sensed that an important piece was missing.

That’s why the challenge isn’t just having good AI. It’s transforming part of a team’s accumulated experience into elements reusable by agents.

This can take many forms: conventions, patterns, guardrails, validation criteria, architecture rules, decision documentation, examples of good deliverables, security procedures, packaging expectations, review sequences.

From the moment these elements become explicit and reusable, quality begins to stabilize.

And that’s where an increasingly strategic notion comes in: skills.

A Skill Isn’t a Gadget, It’s Reusable Expertise

The word can seem a bit marketing-driven if you use it poorly. Yet behind it, the idea is very concrete.

A skill isn’t just a prompt snippet filed in a folder. It’s not a decorative accessory added to look “more agentic.” A real skill is a way of condensing exploitable expertise.

It can contain a method.
Rules.
Recurring patterns.
Vigilance zones.
Boundaries not to cross.
Output expectations.
Useful references.
Implicit checklists.
A recognized way of reasoning about a given problem.

In short, a skill lets you not start from scratch every time.

It plays a very important role: it stabilizes useful behaviors. It prevents an agent from having to reinvent its posture on every task. It reduces result variability. It gives a more durable form to accumulated experience.

That doesn’t mean a skill replaces intelligence. It means it directs it.

And in an agentic system, this direction matters enormously. Because without it, you quickly end up doing opportunistic prompting, highly dependent on the moment, the tool, the model’s mood, the exact wording of the request, and therefore far too unstable for serious use.

A well-designed skill acts as a continuity point. It reminds the agent how to approach a type of problem, what to watch for, what to produce, and sometimes even what to refuse.

That’s precisely why it becomes a strategic asset.

Skills Change the Question You Ask Agents

Without skills, you often ask the agent: “What can you do with this?”

With skills, the question changes. It becomes: “How should you handle this type of task in this specific context?”

The nuance is enormous.

In the first case, you’re mostly soliciting the model’s general capability. In the second, you’re asking it to enter a pre-thought work framework.

And that’s where quality truly progresses.

Because fundamentally, a mature agentic system doesn’t just seek to get answers. It seeks to reproduce, increasingly reliably, certain ways of working that have already proven their value.

In other words, it seeks to industrialize good reflexes without industrializing stupidity.

That’s an important distinction. Because everything that becomes reusable isn’t automatically desirable. If you stabilize bad patterns, you simply create more coherent errors. If you stabilize good patterns, you raise the system’s average level.

A skill’s quality therefore doesn’t depend only on its precision. It also depends on the quality of the judgment it carries.

Without Method, Even a Good System Drifts

Context matters. Skills matter. But there’s still one missing piece: the method.

It’s probably the most decisive point, and yet one of the least glamorous.

There’s a lot of talk about models, agents, tools, automation. There’s less talk about execution discipline. Yet that’s often where reliability is won or lost.

An agentic system without method quickly looks like misdirected power. It can produce fast. It can generate a lot. It can explore paths. It can give an impression of momentum. But if there’s no clear sequence to frame, break down, verify, and fix, it almost always ends up drifting.

This is actually a constant that many teams are starting to observe: AI often starts better than it finishes alone. It proposes fast. It explores fast. It opens paths. But the longer, fuzzier, or more multi-constrained the task becomes, the more the need for a method is felt.

The myth of the perfect prompt belongs precisely to a more naive phase. It led people to believe that a good initial formulation could suffice to produce a good final result. In reality, what works well looks much more like a disciplined work chain.

You specify.
You plan.
You break down.
You execute.
You verify.
You fix.
You iterate.
You validate.

This sequence has nothing spectacular about it. But it’s infinitely more robust than the permanent search for a conversational stroke of genius.

As I detailed in I Stopped BMAD, method isn’t an accessory — it’s the foundation that makes power usable.

Method Is a Skill That Regains Value

This is undoubtedly one of the most interesting effects of agentic AI.

For years, method was sometimes opposed to speed. As if structuring more meant slowing down, weighing down, bureaucratizing. With AI, this opposition becomes much less tenable.

Why? Because speed without method very quickly produces disorder. And that disorder, in a tool-equipped environment, can itself propagate faster than before.

As a result, method changes status. It no longer just serves to reassure organizations. It becomes a direct performance lever.

A team that knows how to properly frame a request, properly distribute context, properly choose its skills, properly separate roles, properly place human validation, and properly structure handoffs will almost always get better results than a team that bets solely on the raw power of tools.

This profoundly changes how you read technical maturity.

True maturity is no longer just about the ability to code without error. It’s also about the ability to design a workflow where errors have less room to flourish.

And that brings us directly back to the figure of the orchestrator developer.

The Orchestrator Developer Acts on the Framework, Not Just the Output

When you look at all this together, the emerging role becomes much clearer.

The orchestrator developer isn’t just someone who “knows how to use AI.” That formula is already too weak. Many people know how to trigger a tool. Far fewer know how to build a coherent work framework around it.

The orchestrator developer operates at multiple levels.

They know what context to give.
They know what to make explicit and what to leave out of scope.
They know which skills should be mobilized.
They know when a task needs to be broken down.
They know when independent validation is necessary.
They know that a simple but rigorous method is often better than brilliant improvisation.

In short, they don’t just work on the output. They work on the conditions of producing the output.

And that’s precisely what gains value in an agentic world. Because the more powerful models become, the more the differential shifts toward framework quality.

This isn’t the end of development. It’s a rise in importance of everything that makes development reliable.

The Future Won’t Be Won by the Most Impressed Teams, but by the Most Structured Ones

I believe this is a useful conclusion at this stage of the series.

Agentic AI creates a lot of enthusiasm, sometimes a lot of noise, often a lot of illusions. Some are stimulating. Others are dangerous. But behind this agitation, a line of force is already taking shape.

The teams that will extract real, lasting value from AI won’t necessarily be the ones testing the most models, nor the ones changing tools most often, nor the ones publishing the most impressive demos.

They’ll be the ones that have learned to transform their experience into transmissible context, their best practices into reusable skills, and their daily work into a robust execution method.

They’ll be the ones that understand that quality doesn’t emerge spontaneously from a strong model. It emerges from a well-designed system around it.

In other words, agentic maturity doesn’t consist of admiring power. It consists of framing it intelligently.

Conclusion

In agentic web development, the model matters. But it doesn’t win alone.

What truly changes a system’s quality is the triad formed by context, skills, and method.

Context provides the right reference points.
Skills make expertise reusable.
Method transforms this power into a reliable work chain.

Without them, even a very good agent drifts.
With them, even an imperfect system becomes much more useful.

That’s why agentic AI isn’t just a question of tools. It’s a question of structuring work intelligence.

And that’s also why the developer’s role continues to evolve. It’s no longer just about producing, or even just supervising. It’s about building the conditions in which assisted production can truly create quality.

In the next article, I’ll conclude this series with the most important consequence of all: the new profession taking shape behind this transformation — frame, orchestrate, arbitrate.

Coming Up in the Series

Nicolas Dabène — Architect of AI-native e-commerce transition & creator of AI solutions for PrestaShop. Book a strategy call to explore how AI can transform your business.

The Orchestrator Developer #2 — Why a Single Agent Is Not Enough

Tue, 28 Apr 2026 06:00:00 +0000

The Orchestrator Developer #2 — Why a Single Agent Is Not Enough

In the first article of this series, I explained why agentic AI truly changes web development. Not just because it accelerates certain tasks, but because it transforms the very organization of work. From the moment AI enters the workflow, reads files, modifies code, runs commands, prepares deliverables, and participates in execution chains, we’re no longer talking about simple assistance. We’re talking about a production system to be piloted.

From there, an idea comes up very often. It’s seductive, intuitive, almost inevitable: why not have a single, very powerful agent that does everything?

One agent to understand the request.
One agent to produce the architecture.
One agent to code.
One agent to secure.
One agent to test.
One agent to package.
One agent to document.
One agent to review.
One agent to deliver.

Or rather, to put it differently: why not ask a single agent to play all these roles at once?

On paper, the idea seems perfect. A single interface. A single loop. A single logic. A single point of contact. It’s simple, comfortable, seductive. It gives the impression of a fluid, almost magical system. You talk to it, it understands, it chains tasks together, it delivers.

The problem is that this vision mostly holds as long as you stay on short, well-bounded tasks, or on demonstrations.

As soon as you enter real web development, things get complicated very quickly.

And that’s precisely where you have to accept a less spectacular, but much more solid reality: a single agent is not enough.

The Super-Agent Fantasy Is Understandable

Let’s start by acknowledging one thing: this idea isn’t absurd. It’s attractive because it answers an old dream of simplification.

For years, software development has been stacking layers of complexity. More tools. More frameworks. More pipelines. More standards. More validations. More dependencies. More context. So naturally, the idea of a single agent capable of absorbing all this complexity and transforming it into a clean deliverable has something very seductive about it.

It’s also reassuring because it echoes a familiar logic: that of the versatile developer who can do almost everything. Understand the need, design, implement, fix, document, secure, deliver. The single agent then becomes a kind of augmented projection of this figure.

And it’s true that at first, it can work.

On a limited task, a well-guided agent can propose a coherent plan, generate an acceptable implementation, fix a few errors, improve the form, draft a base of documentation, and give the impression of astonishing continuity.

That’s often what creates the first wave of enthusiasm.

You tell yourself: “Alright, we’re there. We just need to give it enough context and enough instructions.”

But this impression of fluidity masks a structural fragility.

A Single Agent Ends Up Carrying Everything… So Mixing Everything

The real problem isn’t that a single agent is incapable of producing something. The real problem is that it has to carry too many layers of work at the same time.

Understanding a request is not the same thing as designing an architecture. Designing an architecture is not the same thing as producing a clean implementation. Producing an implementation is not the same thing as reasoning about security. Reasoning about security is not the same thing as thinking about packaging, review, compatibility, or maintenance.

In a human system, we’ve known this for a long time. We know that a good developer isn’t automatically a good reviewer. That an excellent architect isn’t necessarily the best person to validate a back-office UX. That a security specialist doesn’t look at the same mental object as a performance specialist. That a packager, a QA, or a release manager don’t pay attention to the same details.

Yet, when it comes to AI, many fall back into the idea that a single loop could absorb everything.

The problem is that this single loop quickly becomes a place of confusion. It has to keep track of the need, the existing codebase, business constraints, architecture, trade-offs, code quality, technical validations, tests, security, documentation, and the final output. It also has to decide when to explore, when to produce, when to verify, when to fix.

In other words, it has to think about multiple jobs at once.

And the more it tries to do everything in a single trajectory, the more it risks smoothing out the differences between these roles. It then gives the illusion of global coherence, while in reality it’s mixing levels of responsibility that would benefit from being separated.

Real Development Is Not a Continuous Demo

This is often where the difference between an impressive demo and reliable usage appears.

In a demo, you can very well ask an agent to produce a feature end to end. It understands the request, proposes something, modifies code, fixes a few errors, announces it’s done. The loop seems elegant. It works well because it stays short, framed, and observed.

But a real project is not an extended demo.

A real project contains gray areas, contradictions, poorly documented dependencies, historical conventions, old compromises, elements you absolutely must not break, decisions that only make sense in context, rules that are written nowhere but still structure the expected quality.

In this type of environment, the single agent starts showing its limits. Not necessarily by failing visibly. Often, the problem is more subtle. It advances, it produces, it seems coherent, but it drifts little by little. It fills gaps with assumptions. It rationalizes too quickly. It turns ambiguities into certainties. It confuses what’s practical with what’s right. It reduces real tensions to an average solution.

The danger isn’t always the obvious bug. The danger is sometimes the apparently clean, but misaligned solution.

And that’s precisely why the single agent becomes fragile as soon as the project gains in reality.

Specialization Is Not a Luxury, It’s a Reliability Mechanism

At this point, you need to flip the perspective. Many see specialization as a complication. In reality, it’s often a well-thought-out simplification.

Specializing doesn’t mean multiplying agents for the sake of it. It doesn’t mean building a Rube Goldberg machine where every micro-task is artificially separated. It doesn’t mean replacing one confusion with bureaucracy.

Specializing means recognizing that there are fundamental differences in the nature of different types of work.

An agent reasoning about architecture doesn’t need to approach the problem the same way as an agent reasoning about security. An agent preparing a package doesn’t need to behave like an agent inspecting functional coherence. An agent reviewing to identify risks shouldn’t be in exactly the same posture as the one that produced the code.

This separation brings something fundamental: it makes responsibilities clearer.

And when responsibilities are clearer, several benefits appear immediately. Context becomes more targeted. Expectations become more explicit. Outputs become more comparable. Gaps become more visible. Reasoning errors become easier to identify. Human review becomes more effective, because it doesn’t apply to a blurry mass, but to situated productions.

In short, specialization doesn’t primarily serve to produce more. It serves to produce more reliably.

A Good Agentic System Looks More Like a Team Than a Magic Wand

I believe this is the most useful image for thinking about the subject.

A good agentic system doesn’t look like a single oracle that would answer everything. It looks more like a work organization.

With roles.
With sequences.
With checkpoints.
With verifications.
With relay decisions.
With areas where you can parallelize.
With moments where you must, on the contrary, slow down and arbitrate.

This is quite logical, actually. Web development has never been simply a writing activity. It’s a coordination activity between sometimes contradictory requirements: speed, maintainability, security, readability, compatibility, cost, debt, robustness, delivery pressure. It would be strange for a mature AI system to ignore this reality and pretend to solve it in a single monolithic loop.

Thinking in specialized roles, on the contrary, allows you to embrace the real complexity of the job.

One agent can explore.
Another can structure.
Another can produce.
Another can verify.
Another can review from a specific angle.
Another can transform a validated decision into a clean deliverable.

The important point here isn’t to make lots of agents. The important point is to make a comprehensible work architecture emerge.

It’s not the number of agents that counts. It’s the quality of responsibilities and the transitions between them.

Handoffs Become a Real Engineering Topic

As soon as you accept that a single agent isn’t enough, another question appears immediately: how do you properly pass from one role to another?

That’s where an often underestimated topic comes into play: the handoff.

In a human team, handoffs are already critical. A bad transmission between product and engineering, between implementation and QA, between security and delivery, creates loss, misunderstandings, backtracking, reading errors. With agents, this problem doesn’t disappear. It simply changes form.

A good handoff must preserve the essentials without transmitting noise. It must specify what was done, what was decided, what remains open, what needs to be verified, what must not be questioned, and the level of confidence placed in the previous step.

In other words, a handoff is not just a text transfer. It’s a context structuring operation.

And that changes a lot. Because you then understand that a reliable agentic system depends not only on the intrinsic quality of each agent. It depends on the quality of the interfaces between them.

That’s often where maturity plays out. Not in the ability to do a lot, but in the ability to transmit just the right amount.

Why the Agent That Produces Shouldn’t Be the One That Validates

There’s a fairly simple rule in engineering: what produces shouldn’t be the sole judge of its own quality. Of course, self-control exists, and it’s useful. But it doesn’t replace validation from a different angle.

With agents, this rule remains true.

The agent that implements tends to implicitly defend the logic it just built. Even if it tries to review itself, it remains at least partially trapped in its own reasoning trajectory. It’s therefore vulnerable to the same blind spots as a human: post-hoc rationalization, excessive confidence in an earlier assumption, tendency to minimize a risk to preserve the coherence of the whole.

Separating production from validation precisely allows you to break this inertia.

A review agent doesn’t have the same objective as a build agent. A security agent doesn’t have the same reading grid as an architecture agent. An evaluation agent isn’t there to extend the solution, but to put it to the test.

This dissociation doesn’t make the system heavier by principle. It makes it more credible.

Because it reintroduces an essential principle: quality is not decreed within the same loop that produced the result.

The Problem Isn’t Having Multiple Agents, It’s Having Poorly Thought-Out Responsibilities

There’s sometimes a quick criticism of multi-agent approaches: “You’re overcomplicating everything. A good generalist agent with enough context would suffice.”

Sometimes, this criticism hits the mark. There are unnecessarily complex systems, with too many artificial roles, too many steps, too much ceremony. A bad multi-agent architecture can indeed become more fragile than a well-framed single agent.

But this observation doesn’t prove that the single agent is the right answer. It simply proves that responsibilities need to be designed seriously.

The topic is therefore not “one agent or several” in a purely numerical sense. The topic is: where should responsibility boundaries sit so that the system remains readable, reliable, and steerable?

Sometimes, a single loop is enough for a simple task. Sometimes, two or three well-defined roles already create a huge quality gain. Sometimes, a richer chain becomes necessary as soon as you touch security, compatibility, packaging, validation, or decision memory.

The right architecture isn’t the one that impresses the most. It’s the one that separates just what needs to be separated, and keeps together what can reasonably be kept together.

Mature Agentic AI Means Giving Up on Magic

I believe this is, at its core, the heart of the matter.

As long as you’re looking for magic, you naturally look for the single agent. A single point of contact, a single intelligence, a single flow. It’s elegant on the surface. It’s simple to tell. It’s seductive to sell.

But real web development rarely rewards magic. It rewards systems capable of absorbing complexity without denying it.

That’s why mature agentic AI looks less like a feat of strength and more like an architecture.

An architecture where each role has a reason to exist.
An architecture where handoffs are thought through.
An architecture where validations are separated from productions.
An architecture where context isn’t just accumulated, but intelligently distributed.
An architecture where the human retains real arbitration power.

It may not be the most spectacular vision. But it’s probably the most solid.

The Orchestrator Developer Emerges Right Here

It’s in this shift that the figure of the orchestrator developer becomes clearer.

If a single agent isn’t enough, then value is no longer in simply knowing how to “talk to AI.” It’s in the ability to organize a coherent work chain.

The orchestrator developer isn’t there to replace all roles by sheer will. They’re there to structure interactions between roles, choose the right levels of separation, inject the right context in the right place, demand the right checkpoints, and know when a production should be stopped, fixed, validated, or relaunched.

In other words, they become the guarantor of the system’s readability.

This isn’t a decorative role. It’s probably a growing part of technical value in the years to come.

Because a poorly structured agentic system can produce fast without producing right.
And because a well-thought-out agentic system can truly change a team’s quality level.

As I explained in I Stopped BMAD, the method matters as much as the tool. And orchestration is precisely that method.

Conclusion

The idea of the single agent is seductive, but it collapses as soon as web development returns to its true nature: a work of constraints, contexts, responsibilities, and verifications.

A single agent can be useful. It can even be impressive. But it isn’t enough as soon as you look for reliability, readability, and control on real projects.

That’s why specialization, handoffs, the separation between production and validation, and the structuring of roles become so important.

Agentic maturity doesn’t consist of dreaming of a super-agent capable of absorbing everything. It consists of building a work architecture where each role serves the overall quality.

And that’s precisely what opens the next logical step in this series.

Because if a single agent isn’t enough, then real performance depends on something else: the quality of context, skills, and method.

That’s what I’ll cover in the next article.

Coming Up in the Series

Nicolas Dabène — Architect of AI-native e-commerce transition & creator of AI solutions for PrestaShop. Book a strategy call to explore how AI can transform your business.

Beyond SEO: The Practical Guide to Testing and Dominating Your Visibility in the AI Era

Tue, 21 Apr 2026 07:00:00 +0000

In 2024, Google served over 8 billion direct answers via AI Overviews. By 2025, ChatGPT Search surpassed 500 million weekly active users. And while most marketers kept optimizing their <title> tags, a growing portion of organic traffic vanished into generated answers with no clicked link.

TL;DR — If you only have 30 seconds: classic SEO is no longer enough. Test your presence in generative engines using the tools described below, identify AI training bots, and restructure your content for RAG. GEO isn’t optional — it’s the next battle for traffic.

1. SEO Is Dead — Not the Traffic, Just Its Path

Let me be direct: SEO isn’t dead, but its monetization model is collapsing.

For 25 years, the formula was simple: rank on page 1 → get clicks → convert. Today, generative search engines (GSEs) short-circuit that chain. The user asks a question, the AI synthesizes an answer, and the click to your site becomes optional — or nonexistent.

What’s really changing isn’t the technology. It’s the economics of the click.

The Anatomy of a Generative Search Engine (GSE)

A GSE operates in 4 steps:

Intent Understanding — The AI decomposes the query into semantic entities
Retrieval — The system queries its index and authorized sources
Generation — A language model assembles a coherent response
Attribution — Sources are cited (or not) as links

💡 The critical point: if your content isn’t retrieved at step 2, it simply doesn’t exist for the AI.

📄 Complement: How AI Discovers Your MCP Tools — the resource discovery process by AIs, directly related to the retrieval step.

2. GEO vs SEO: What Fundamentally Changes

SEO optimizes for a ranking algorithm. GEO optimizes for a comprehension pipeline.

Dimension	Classic SEO	GEO (Generative Engine Optimization)
Target	Ranking algorithm (PageRank, BERT)	RAG pipeline (Retrieval-Augmented Generation)
Primary signal	Backlinks, domain authority	Citability, semantic structure, E-E-A-T
Winning format	Keyword-optimized page	Standalone passage, well-structured, sourced
Success metric	SERP position, CTR	Presence in AI responses, citations
Lifespan	Months to years	Variable depending on content freshness

The Concept of a “Citable Passage”

A citable passage is a standalone block of content that answers a specific question. AIs don’t cite entire pages — they extract fragments.

💡 Golden rule: every section of your content must be understandable out of context.

📄 For more detail: GEO for e-commerce: optimizing product pages for AI answers — a concrete case study of GEO applied to merchant pages.

3. How to Test Your GEO Presence (Practical Methodology)

Here’s the method I use in my practice to audit the AI visibility of a merchant site:

Step 1: Test Direct Answers

For each target query, check:

Google AI Overviews — Enable SGE/AI Overviews and note whether your domain appears in cited sources
ChatGPT Search — Ask the question and observe whether your URL is mentioned
Perplexity AI — A natively source-citing tool, ideal for benchmarking
Bing Copilot — Test the answers generated by Microsoft

📄 Detailed methodology: Complete Guide to Measuring GEO — the metrics and KPIs to track your AI presence.

Step 2: Analyze Citation Structure

When your site is cited, note:

Which passage is extracted? (heading, paragraph, list?)
In what context? (primary answer, secondary source, footnote?)
With what sentiment? (neutral, positive, critical?)

Step 3: Map the Gaps

Create a simple table:

Query	Google AI	ChatGPT	Perplexity	Bing	Presence
“best PrestaShop SEO module”	✅	❌	✅	❌	50%
“configure MCP PrestaShop”	❌	❌	❌	❌	0%

💡 If your presence is below 50% on your strategic queries, you’re invisible to a growing portion of traffic.

4. Identifying AI Bots: Who’s Scraping Your Content?

This is where it gets technical — and crucial.

Not all bots are equal. Understanding who accesses your content determines how you’ll be represented in AI-generated answers.

The Two Families of AI Bots

Type	Role	Examples	Impact on You
Indexing bots	Retrieve content for real-time answers	Googlebot, Bingbot	Immediate visibility in AI Overviews
Training bots	Collect data for model training	GPTBot, CCBot, ClaudeBot	Future influence on generated answers

How to Identify Them

Check your server logs or use tools like:

Search Console — “Crawl stats” tab for Googlebot
Raw log files — Search for user-agents: GPTBot, CCBot, Claude-Web, PerplexityBot
Log analysis tools — Screaming Frog Log File Analyser, Botify

⚖️ GDPR reminder: you have the right to block training bots via robots.txt. But be careful: blocking all of them can reduce your AI visibility.

📄 MCP context: Connect Your PrestaShop Store to AI Agents via MCP — understanding how agents access your data changes your approach to visibility.

5. The “Delphic Cost”: Why Some Content Will Never Be Cited

I developed this concept after analyzing hundreds of cases: the Delphic Cost measures the gap between what your content says and what the AI can extract from it.

The 3 Levels of Delphic Cost

Low cost: Structured content, standalone passages, explicit data → High citability
Medium cost: Dense content, implicit information, narrative structure → Variable citability
High cost: Pure visual content, contextual information, undefined jargon → Near-zero citability

How to Reduce Delphic Cost

Structure in Q&A format — Each section answers a specific question
Define your terms — The AI doesn’t guess, it looks for explicit definitions
Use lists and tables — Tabular structures are the most easily extracted
Add quantified data — AIs prioritize sourced claims
Avoid implicit context — What’s obvious to you isn’t obvious to a model

💡 Content with a low Delphic Cost is 3x more likely to be cited than equivalent but poorly structured content.

📄 Practical application: Essential GEO FAQs for your store — Q&A templates optimized for AI citability.

6. The GEO Methodology in 5 Steps

Here’s the framework I apply systematically:

1. Citability Audit

Analyze each page against these criteria:

Does a standalone 150-300 word passage exist that answers a specific question?
Is the data sourced and dated?
Does the structure allow easy extraction (clear H2/H3, lists, tables)?

2. Semantic Optimization

Identify the entities the AI should associate with your brand
Create “answer-ready” passages: paragraphs designed to be extracted
Use your audience’s vocabulary, not internal jargon

3. RAG-Focused Structuring

Add structured FAQs (with schema.org FAQPage)
Create pillar pages with standalone sections
Use comparison tables — AIs love tabular structures

📄 Concrete example: Black Friday & GEO: the follow-up — how to structure seasonal content to maximize AI visibility.

4. Reinforced E-E-A-T Signals

Experience: concrete testimonials, use cases, proprietary data
Expertise: certifications, open-source contributions, publications
Authoritativeness: quality backlinks, mentions in trusted sources
Trustworthiness: transparency, cited sources, clear data policy

5. Continuous Monitoring

Monthly testing of your strategic queries across all 4 GSE platforms
Track the evolution of your presence in AI responses
Adjust structure based on observed citation patterns

7. Tools and Resources for Implementing GEO

Testing Tools

Google Search Console — AI Overviews performance data (rolling out)
Perplexity AI — Test the citability of your pages
ChatGPT Search — Verify your brand’s presence
GEO-specific tools — Emerging tools like BrightEdge, MarketMuse, Clearscope

Technical Tools

Schema.org markup — FAQPage, Article, HowTo, Product
Optimized sitemap — Include “answer-ready” content URLs
Strategic robots.txt — Allow indexing bots, manage training bots

Resources to Go Further

Google Search Central — AI Overviews
OpenAI — GPTBot documentation
Schema.org — Structured vocabulary for the semantic web

8. Conclusion: GEO Isn’t Optional, It’s a Necessity

Organic traffic isn’t disappearing — it’s migrating. And this migration rewards those who understand that AI visibility is built, not declared.

The question is no longer “how to rank on page 1” but “how to exist in the answer”.

My Recommendation

Start with the audit. Test your presence across all 4 GSE platforms for your 20 strategic queries. Identify gaps. Prioritize pages with high Delphic Cost. And restructure progressively.

Don’t rewrite everything. Optimize existing passages. Add standalone sections. Structure for extraction. GEO is incremental, not revolutionary.

💡 Merchants who integrate GEO into their SEO strategy from 2026 onward will have a lasting competitive advantage. The rest will watch their organic traffic erode without understanding why.

Nicolas Dabène — Architect of AI-native e-commerce transition & creator of AI solutions for PrestaShop. Book a strategy call to explore how AI can transform your business.

The Orchestrator Developer #1 — Why Agentic AI Is Truly Changing Web Development

Thu, 16 Apr 2026 06:00:00 +0000

The Orchestrator Developer #1 — Why Agentic AI Is Truly Changing Web Development

For months now, there has been a lot of talk about AI in web development. We compare models, test assistants, look at which one codes the fastest, which one explains the best, which one handles a terminal or an IDE the best. That’s normal. It’s visible, concrete, immediately measurable.

But by constantly looking at AI through the lens of speed or the raw quality of generated code, we’re missing what’s actually happening.

The real issue isn’t just that AI helps produce faster. The real issue is that web development is starting to change in nature. Not in some distant future. Now.

We’re moving out of a logic where AI was mainly a brilliant conversational partner — sometimes useful, sometimes approximate, often impressive, but still confined to a form of assistance. What’s happening today is different. AI no longer just responds. It’s starting to act within the workflow. It reads files, proposes plans, modifies code, runs commands, executes tests, reformulates specs, prepares documentation, helps structure a review, inserts itself into Git branches, interacts with tools.

And when a technology stops being merely consultative and becomes executable, the consequences go far beyond simple time savings.

That’s why I believe agentic AI is truly changing web development.

Not because it magically replaces developers. Not because it would suddenly write everything perfectly. Not because a single prompt would be enough to produce clean, robust, maintainable applications. On the contrary. Agentic AI changes web development because it shifts where value lies. It shifts it from the act of raw production toward the ability to organize, frame, supervise, and ensure the reliability of a work system.

And that shift is much deeper than it appears.

We’re No Longer Just in the Prompt Era

The first major phase of AI for developers was conversational. You asked a question, got an answer, corrected, re-prompted. That phase was important. It allowed many people to experience something very concrete: yes, a model can explain a bug, generate a function, propose tests, document a piece of logic, reformulate an architecture idea, speed up tedious work.

But that logic also showed its limits very quickly.

In a conversation, you can get very good one-off answers. You can even have the impression of a real technical dialogue. Yet, as soon as you enter a real project, the difficulty is almost never in the isolated answer. It’s in everything surrounding that answer: the application context, internal conventions, architecture choices already made, existing dependencies, versions to support, historical compromises, business rules, security concerns, the way a team reads, maintains, and evolves code.

That’s where a simple exchange, even a very good one, starts showing its fragility.

A model can very well produce an elegant solution in the abstract and a completely inadequate one in a real project. Not because it’s bad, but because it doesn’t naturally work from the same level of context as a team, nor with the same memory of constraints, nor with the same understanding of priorities.

For a while, many believed the main topic would be writing better prompts. In reality, that was only an intermediate step. The topic now becomes much broader: how do we make AI systems work in real software production chains, with real constraints, real verifications, and real responsibilities?

That’s where agentic AI begins — a topic I already explored from a different angle in The End of the Lone Coder.

The Tipping Point Happens When AI Enters the Workflow

I think it’s important to be very clear on this point: the disruption doesn’t just come from models getting better. It comes from them becoming operable in concrete working environments.

As long as AI remains an assistant in a window, its impact is limited to the quality of its responses. As soon as it enters a work system, the question changes completely.

From the moment an AI can read a repository, understand part of the existing codebase, propose an action plan, modify multiple files, run commands, verify results, document what it did, prepare a sequence of tasks, or pass the baton to another step, we’re no longer talking about the same thing.

We’re no longer just talking about assistance. We’re talking about framed execution.

And that difference profoundly changes how we think about the profession. Because the right question is no longer: which model codes the best? The right question becomes: how do we build a work framework in which agents can produce something useful without degrading quality?

That’s an engineering question. It’s even, in a way, a new layer of engineering.

Because an agent that acts poorly costs more than an assistant that answers poorly. An assistant that hallucinates in a conversation costs you a bit of time. A poorly framed agent that modifies, executes, chains actions, and drifts in a real project can create confusion, debt, and sometimes much more serious risks.

The arrival of agentic AI therefore doesn’t reduce the need for rigor. It increases it.

The Real Change Isn’t Speed — It’s Work Organization

When people talk about AI for developers, they very quickly fall into an imaginary of immediate productivity. Produce faster. Fix faster. Ship faster. And of course, that acceleration exists. It’s real. It would be absurd to deny it.

But if we stop there, we’re reading the phenomenon far too superficially.

In a professional setting, the problem has never been simply writing code. The problem has always been producing a reliable change in an existing system. A change that fits correctly into the architecture, that respects project constraints, that doesn’t break something else, that remains understandable by others, that passes through a validation cycle, that can be maintained, picked up, tested, corrected, reviewed.

In other words, what matters isn’t the raw speed of generation. What matters is the ability to move a living system forward without losing its coherence.

That’s exactly where agentic AI becomes more interesting than simple code generation. Because it forces us to look at development no longer as an addition of technical tasks, but as a work chain to be structured.

Who does what? With what context? In what order? With what boundaries? With what checkpoints? With what human validation? With what guardrails?

The further we go in this reflection, the more we understand that performance doesn’t come from a model miracle. It comes from the quality of orchestration — a point that echoes what I explained in The Illusion of Disposable Code.

The Breakthrough Is Organizational First

This is, in my view, the most important point and probably the most underestimated.

We often talk about AI as a technical revolution. That’s true, of course. But in web development, the major impact is also organizational. Perhaps even primarily organizational.

Why? Because a useful agent is never just a performant model. It’s a model inserted into a role, into a method, into a frame of action.

An agent starts to become truly interesting when we know precisely what we expect from it, what it’s allowed to do, what it must not do, what resources it can use, what output level we require, how its work will be verified, and at what point a human takes over.

In other words, agentic AI pushes teams to make explicit what they sometimes left implicit.

It forces clarification. Breakdown. Naming responsibilities. Structuring sequences. Better distinguishing exploration, implementation, validation, review, quality control.

That’s why I think the teams that will extract the most value from agentic AI won’t necessarily be the ones with access to the best models. They’ll be the ones that have learned to transform how they work.

The best won’t just be assisted. They’ll be better organized.

The Developer Doesn’t Disappear — They Shift Their Center of Gravity

This is often where reactions become caricatured. On one side, we hear that AI will replace developers. On the other, we repeat that it can’t properly finish a real project and therefore shouldn’t be taken too seriously.

I think both positions miss the point.

The developer doesn’t disappear. But their center of gravity shifts.

Some tasks become easier to accelerate: generating a base, proposing multiple variants, documenting a piece of logic, quickly exploring a path, automating part of repetitive work. This movement is real. It will continue. And it will banalize a portion of raw production.

In parallel, other skills gain more value. Framing. Understanding the real need. The quality of context given to the system. Breaking down a complex task into verifiable steps. Reading impacts. Anticipating side effects. Architecture. Security. Arbitrating between imperfect options. The ability to say stop, to correct a drift, to refuse a seductive but fragile solution.

That’s where the profession transforms.

The valuable developer is no longer just the one who knows how to produce. Increasingly, it’s the one who knows how to organize augmented production without losing control of the result.

That’s why I use the term orchestrator developer.

Not to create a new buzzword, but to name this shift. We remain in development. We remain in technique. We remain responsible for the deliverable. But we add a dimension that has become central: the ability to intelligently make a set of agents, tools, validations, and contexts work together.

The Trap Would Be Believing a Good Model Is Enough

There’s a seductive idea circulating widely: as models get better, problems will disappear on their own. It will then be enough to choose the right actor, the right interface, or the right agent, and the machine will produce the rest.

In practice, that’s not how it works.

Even an excellent model drifts if the request is vague. Even an excellent model makes mistakes if important constraints aren’t explicit. Even an excellent model produces noise if nobody actually verifies what it does. Even an excellent model can give an illusion of coherence while accumulating fragile assumptions.

That’s precisely what makes the topic interesting: final quality depends less on the model’s supposed “genius” than on the solidity of the framework in which it’s made to work.

And that reality changes the nature of differentiation.

The difference won’t come solely from access to a better AI. It will come from the ability to build better work systems around it. Better contexts. Better methods. Better checkpoints. Better rules for passing between stages. Better validation habits.

In other words, the advantage won’t just be technical. It will be methodological — a risk I detailed in AI and Development: Mastering Invisible Traps.

Web Development Becomes a More Explicit System

For a long time, much of development relied on a form of human compression. The developer absorbed many things on their own: the request, the context, the constraints, historical decisions, the riskiest paths, project habits, how to avoid certain errors, delivery trade-offs.

With agentic AI, part of that compression must be reopened and structured.

What was implicit must be made explicit. What was held in memory must be documented, transmitted, made operable. What was diffuse across a team must sometimes be transformed into exploitable context, into rules, into patterns, into steps, into controls.

This is an important change, because it pushes web development toward a more systemic logic.

The project is no longer just a codebase. It also becomes a set of conventions, flows, validation points, decision memories, and tool-enabled roles. The developer doesn’t lose their place in this system. On the contrary, they become an even more strategic piece. Because someone has to give it shape. Someone has to decide the level of trust. Someone has to take back control when automation becomes imprecise. Someone has to keep responsibility for the result.

Agentic AI doesn’t erase the developer. It brings to light what good developers were already often doing without necessarily formalizing it: structuring, prioritizing, coordinating, verifying, connecting.

Productivity Changes Its Definition

This is another major consequence.

For a long time, productivity could be read fairly simply: execution speed, quantity produced, delivery pace, ability to handle tickets, ship features, fix bugs.

With agentic AI, that reading becomes too poor.

A developer can now go very fast while creating more noise around them. They can produce more code, more changes, more branches, more intermediate outputs… without necessarily increasing the net value for the project. Sometimes even degrading it, if nothing is truly orchestrated.

Real productivity therefore becomes more demanding. It’s no longer just the ability to accelerate. It’s the ability to accelerate without losing control, without diluting coherence, without exploding the review load, without creating silent debt that the team will pay for later.

This nuance is essential. Because it reminds us of something simple: speed only makes sense if it remains compatible with quality.

And in an agentic environment, quality no longer comes solely from individual production talent. It also comes from how the work has been framed, distributed, verified, and picked back up.

The Best Will Learn to Organize, Not Just to Prompt

I think the developers who will extract the most value from this phase won’t necessarily be the ones who accumulate prompts or change tools every two weeks. They’ll be the ones who understand that the core topic is the structuring of work.

They’ll learn faster than others how to transform a vague request into clear steps. To define clear roles. To demand verifiable outputs. To give useful context rather than noise. To bring human review in at the right moment. To distinguish what can be largely automated from what must remain strongly arbitrated.

In short, they’ll understand that agentic AI isn’t primarily a topic of technological fascination. It’s a topic of discipline.

And that’s perhaps the most counter-intuitive point of this new phase: the more capable AI becomes, the more it demands a serious framework to produce lasting value.

Not less method. More method.
Not less rigor. More rigor.
Not less engineering. Broader engineering — a topic I also explore in I Stopped BMAD.

The Real Topic Is Already Ahead of Us

At this stage, the question is no longer really whether agents will find a place in web development. That place is being built before our eyes.

The real question is rather this one: what kind of work system are we going to build around them?

Because an agent without a framework is just an ambiguity amplifier. An AI without context is just a faster approximation. An automation without validation is just a better-packaged risk.

Agentic AI is not a magic shortcut. It’s a new layer of responsibility.

And that’s why it truly changes web development. Not because it would eliminate the need for developers, but because it forces developers to make more explicit, more structured, and more governed everything that actually enables producing quality.

Conclusion

Agentic AI doesn’t just mark a new step in code assistance. It opens a phase where web development becomes more systemic, more orchestrated, more dependent on the quality of context, breakdown, validation, and supervision.

This change is profound, because it touches less the spectacle of generation and more the reality of production.

In this landscape, the developer doesn’t fade away. They become more central on what truly matters: understanding, framing, structuring, arbitrating, verifying, assuming the final result.

In other words, they don’t stop being a developer. They also become an orchestrator.

And that’s precisely what I’ll dig into in the next article of this series: why a single agent is not enough.

Coming up in this series

The Orchestrator Developer #1 — Why Agentic AI Is Truly Changing Web Development
The Orchestrator Developer #2 — Why a Single Agent Is Not Enough
The Orchestrator Developer #3 — Why Skills, Context, and Method Change Everything
The Orchestrator Developer #4 — The New Job: Frame, Orchestrate, Arbitrate

I Stopped Using BMAD. Here's What Replaced It.

Tue, 14 Apr 2026 00:00:00 +0000

By Nicolas Dabène — AI-Native E-commerce Architect

This Is Not an Anti-BMAD Article

I want to be clear about this before I even start.

BMAD made me a better AI developer. The method forces something most people rush: thinking before generating. Structured brief, defined roles, sequential phases. When you used a single agent trying to do everything at once, BMAD taught you to decompose. That’s a real gain.

But in March 2026, on a PrestaShop project involving 14 specialized agents in parallel, I realized I was still carrying BMAD as a mental framework when my needs had changed. I was still manually orchestrating things the architecture could — should — handle alone.

That’s what this article is about. Not a problem with BMAD. An evolution beyond it.

What BMAD Actually Solves

If you don’t know BMAD, here’s a short definition: it’s an AI-assisted development method that structures work into phases (Brief, Method, Agent, Delivery). The core idea is that you don’t throw a vague request at an LLM — you build a structured conversation with a clear role, precise expectations, a defined output.

What changes in practice:

You stop getting generic answers because you’re asking generic questions
You think in systems (roles, responsibilities, outputs) rather than one-shot prompts
You build continuity between sessions instead of starting from scratch

On normal-sized projects — a PrestaShop module, an n8n workflow, a structured blog post — BMAD is effective. The friction it introduces (framing, briefing, phase validation) is productive. It prevents you from going down the wrong path for an hour.

I worked this way for several months. My deliverables gained consistency. My Claude Code sessions became more predictable. PS9 BC breaks no longer caught me by surprise because I included them in the brief.

So BMAD works. That’s not the question.

The Project That Changed Everything

End of January, I was working on a complete rewrite of the gmerchantcenter_pro module — Google Merchant Center PRO, version 2.0.0. Rewriting the taxonomy system, custom labels, exclusion rules, and in parallel an update to the product tags and attributes system.

This isn’t a simple module. It’s a wide technical surface: PrestaShop 9 Admin API, CQRS, API Platform, Symfony 6, plus all the Google Merchant Center specific business logic. And in this project, I needed multiple expertise at once: architecture, implementation, security, Marketplace packaging, tests, changelog.

With BMAD, I orchestrated manually. I briefed an agent on architecture. I took their output, passed it to the implementation agent. I came back, checked security, launched packaging. Sequential. Controlled. Me at the center of every relay pass.

And that’s when I saw the problem.

I was no longer a supervising architect. I had become a human router. My job was to copy-paste outputs from one context to another, reformulate what agent A had produced so agent B could understand it, maintain overall coherence in my head because no agent had it.

BMAD gave me structure. But that structure, I was carrying it entirely myself.

What Happens When You Externalize Orchestration

The question I asked myself: is this manual coordination irreducible, or is it just accidental complexity I accepted out of habit?

The answer became obvious when I started describing what I was doing out loud: I took a request, analyzed its dependencies, decided who could work in parallel and who had to wait, routed, assembled, validated. That’s exactly what an orchestrator does.

Except I was doing it manually, on every task, with all the cognitive load that implies.

Agentic orchestration, as I’ve implemented it since, externalizes this work. A master agent receives the request. It analyzes real dependencies. It launches specialized agents — in parallel when possible, in sequence when dependencies require it. It assembles. It returns a coherent output.

What changes for you: you decide what gets done, not how it’s coordinated.

What the Architecture Looks Like Today

I describe it in detail in the March 31 article, but here’s the essential to understand the difference with BMAD.

The master agent is the single entry point. It doesn’t touch code. It doesn’t write. Its sole responsibility: understand the request, analyze dependencies, route to the right specialists, synthesize the result.

14 specialized PrestaShop agents — each with a strict scope. prestashop-architect designs, prestashop-module-dev implements, prestashop-security audits, prestashop-phpstan statically analyzes, prestashop-packaging prepares for Marketplace. They don’t overlap. They don’t compromise between two expertises.

The skills — Markdown files that carry business rules. PS9 conventions, BC breaks between versions, patterns to avoid on multistore, Marketplace validation checklist. Each agent loads its skills before acting. This replaces the “context brief” I was manually rewriting at every BMAD session.

The concrete difference: when I ask to create a PrestaShop admin page with filterable product listing, master analyzes the request and produces something like this —

Step 1 (sequential): prestashop-architect sets the structure — Symfony controller, Grid, services, hooks.
Step 2 (parallel): prestashop-module-dev implements, prestashop-security audits permissions, prestashop-testing designs the test strategy. Simultaneously.
Step 3: qa-reviewer validates before delivery.

With BMAD, this sequence, I was piloting it. Now it’s in the architecture.

What BMAD Does That Orchestration Doesn’t Replace

I said it at the beginning, but it’s important to specify here.

BMAD teaches you to think. Agentic orchestration executes better what you’ve already learned to think.

If you’ve never structured an AI request, if you still arrive with “make me a module that does X” without context or constraints or definition of what “done” means — orchestration won’t save you. You’ll just have 14 agents going in different directions very quickly.

BMAD, or any method that forces you to frame before acting, remains a necessary step. Not because it’s the destination, but because it builds the reflexes you need to use orchestration correctly.

The transition I made wouldn’t have happened if I hadn’t spent months working with BMAD. I wouldn’t have seen it coming because I wouldn’t have known what I was trying to improve.

The Real Break: Who Carries the Complexity

If I had to summarize the difference in one formulation, it would be this:

BMAD: you carry coordination complexity in your head, and you use the method to structure it.
Agentic orchestration: you transfer this coordination complexity to the architecture, and you keep your energy for decisions that can’t be automated.

It’s not the same thing.

In BMAD, even well applied, you remain the pivot. You’re the one who knows where the project stands, who knows which agents produced what, who maintains overall coherence. The method helps you do it well. But it’s always you doing it.

In an orchestrated multi-agent architecture, overall coherence is in the system. master knows what was done, by whom, in what order. The skills carry the PrestaShop context you were rewriting manually. The dependency flow is analyzed, not memorized.

You go from AI project manager to AI systems architect. That’s a posture change, not just a tooling change.

Should You Make the Same Transition?

Probably not right now.

Multi-agent orchestration has a real entry cost. Building the architecture, defining agent scopes without overlap, writing skills that carry the right context — that’s several weeks of work before drawing value from it. And if you do this without having integrated the framing reflexes BMAD teaches, you’ll create complexity without structure, which is worse than having none.

The transition makes sense when you encounter this precise signal: you spend more time coordinating between agents than producing or deciding. When you find yourself being the human router of your own AI stack.

If that’s not your case yet, stay on BMAD or the method that forces you to frame. Optimize execution. Build the reflexes.

If it is your case — if you recognize yourself in the “human router” I described — then the architecture deserves real investigation.

What Comes Next

I don’t think agentic orchestration is the final form.

What I see emerging is agents that manage the evolution of their skills themselves. That detect when a PrestaShop convention has changed and update their rules base. That know, without you telling them, that the project went from PS8 to PS9 and that some patterns are now deprecated.

We’re not there yet. But the direction is clear: less human coordination, more human governance. Less “I manage the flow”, more “I decide the rules of the flow”.

BMAD was a step toward this. Agentic orchestration is another. The next one, I don’t know exactly what form it will take — but I know it will always be a question of where to place intelligence: in the developer’s head, in the method, or in the architecture itself.

The answer changes as tools change. What doesn’t change: the quality of decisions we make about this placement.

This article follows Why Multi-Agent Orchestration Is No Longer Optional for PrestaShop — if you want the details of the architecture itself, that’s where to look.

Mistral Small 4: The All-in-One Model Simplifying AI for E-commerce Merchants

Tue, 07 Apr 2026 00:00:00 +0000

When managing an e-commerce store, you rarely need just one AI model. Sometimes you need text generation, sometimes coding, sometimes structured reasoning. Result: multiplying subscriptions, API keys, configurations.

Mistral Small 4 changes this equation. By unifying three capabilities formerly spread across multiple models (Magistral for reasoning, Pixtral for multimodal, Devstral for coding), this model offers a single, adaptable solution.

What Mistral Small 4 Actually Changes

One Model, Multiple Use Cases

No more choosing between:

A fast instruction model for simple responses
A reasoning engine for complex analysis
A multimodal assistant for processing images

Small 4 does all of this. And thanks to its configurable reasoning effort, you adjust processing depth per task — without switching models.

Open Source at the Service of Control

Under Apache 2.0 license, Small 4 is:

Deployable locally or on your infrastructure
Customizable via fine-tuning
Auditable for GDPR compliance

For a PrestaShop merchant handling customer data, orders, and buyer segments, this is a valuable sovereignty lever.

“By unifying instruction, reasoning, and multimodal capabilities, Mistral Small 4 simplifies AI integration and allows users to tackle a wider range of tasks with a single adaptable tool.” — Mistral AI

Concrete Use Cases for PrestaShop

Task	What Small 4 Enables
Sales Analysis	Quarterly synthesis, trends, recommendations
Product Descriptions	SEO-optimized generation, multi-language variations
Operational Diagnostics	Identifying conversion drop causes
Customer Support Automation	Request classification, automated responses
Agent Workflows	Multi-step actions (e.g., automatic restocking)

How to Integrate with PrestaShop

In practice, with a connector like MCP (the same protocol that MCP Tools Plus uses for PrestaShop), Small 4 can connect to your store to:

Read your data (products, orders, inventory)
Analyze and reason over this data
Generate content optimized for your catalog
Execute actions via agent workflows

All while keeping data under your control — unlike external APIs that transit through third-party servers.

Mistral Small 4 vs Alternatives

Criteria	Mistral Small 4	Claude/GPT (External API)
Data Control	Local / Controlled	External transit
Single model for everything	✅ Yes	⚠️ Multi-models
Customization	Fine-tuning possible	Limited
GDPR Compliance	Simplified (local)	Complex (transfers)
Cost	Local inference + electricity	Subscription/API

Key Takeaways

Mistral Small 4 isn’t the most powerful model on each individual task. But it’s the first unified model covering the essential AI cycle for an e-commerce merchant — without administrative complexity or external dependency.

For PrestaShop merchants who want:

✅ Simplify their AI stack
✅ Keep data control
✅ Reduce inference costs
✅ Stay GDPR compliant

… Small 4 represents a serious alternative to proprietary solutions.

The question is no longer “which model for which task?” but “how to make AI operational on my store with a single controlled tool?”

Nicolas Dabène — PrestaShop enthusiast working with MCP & closely following the evolution of open-source models for e-commerce.

Why Multi-Agent Orchestration Is No Longer Optional for PrestaShop

Tue, 31 Mar 2026 00:00:00 +0000

Why Multi-Agent Orchestration Is No Longer Optional for PrestaShop

By Nicolas Dabène — AI-Native E-commerce Architect

The problem nobody says out loud

We talk a lot about “AI for PrestaShop.” We talk about Copilot, Claude, “vibe coding.” We talk about time savings, productivity, everything AI can generate in seconds.

What we say less is that AI alone — a single model, without architecture — produces PrestaShop code of questionable quality. It generates a GridDefinitionFactory that doesn’t respect PS9 conventions. It forgets to declare the service in config/services.yml. It mixes API versions. It doesn’t know your business constraints.

Not because the model is bad. Because a generalist model cannot hold in its head the entire complexity of the PrestaShop ecosystem — hooks, the Command Bus, CQRS on the Admin API side, multistore constraints, Marketplace packaging specs, 15 years of technical debt coexisting in the same codebase.

It can try. It will miss details. And in PrestaShop, details have consequences.

The answer is not “use AI less.” It’s “structure it better.” It’s orchestration.

What multi-agent orchestration really is (without the jargon)

Here’s the core principle, in one sentence:

A master agent clarifies, routes, and synthesizes. Specialized agents execute. Skills carry the business rules.

Nothing magical. It’s the same logic as a well-organized agency: a project manager who knows what to delegate to whom, and experts who master their domain.

In my architecture, master is the unique entry point. It doesn’t touch code. It doesn’t write a single line of PHP. Its job: understand the request, choose the right agent(s), launch them — in parallel if possible, sequential if necessary — then assemble the result.

The specialized agents, on the other hand, have only one job. And they do it well because they have the rules to do it well.

The 4 components of the architecture

1. The master orchestrator: the only one who speaks

master is the unique visible orchestrator. The user talks to it. It responds.

Its core rule: it never does the business work itself. If you ask it to fix a module, it doesn’t touch the code — it launches prestashop-module-dev, waits for the return, and synthesizes the result for you.

What master actually does:

Clarify the request if it’s ambiguous
Choose the right specialist(s)
Decide whether we can parallelize or if it’s sequential
Assemble outputs into something coherent
Hand back control cleanly

This design has an important consequence: master never makes business decisions alone. It knows it doesn’t know better than its specialists.

2. Specialized PrestaShop agents: each their territory

That’s where PrestaShop’s complexity is cleanly partitioned.

I have 14 active PrestaShop agents, split into two families:

Build / Implementation

Agent	What it does
`prestashop-architect`	Designs architecture, chooses patterns, sets foundations
`prestashop-module-dev`	Implements, fixes, debugs
`prestashop-security`	OWASP audit, injection, input validation
`prestashop-testing`	Test strategy, behavioral coverage
`prestashop-performance`	Profiling, N+1 queries, cache, indexing
`prestashop-webservice`	REST, Admin API, API Platform

Packaging / Operations

Agent	What it does
`prestashop-htaccess`	Sensitive file protection
`prestashop-license`	License headers, proprietary vs open-source
`prestashop-changelog`	Maintained and coherent CHANGELOG
`prestashop-phpstan`	Static analysis, PS-targeted PHPStan level
`prestashop-phpcsfixer`	Code standards, PSR, PS conventions
`prestashop-upgrade`	Migration between PS versions
`prestashop-translator`	XLIFF, MD5 translations, translation domain management
`prestashop-compat-advisor`	Command Bus compat: Tactician vs Messenger

Why this granularity? Because “PrestaShop expert” means nothing alone. Marketplace packaging expertise has nothing to do with data migration expertise. And an agent that tries to do everything ends up doing nothing well.

3. Parallelization: the real speed gain

Orchestration doesn’t just serve to have specialized agents. It serves to make them work at the same time.

Let’s take a concrete case. You ask:

“Create a PrestaShop admin page with a filterable product listing.”

Without orchestration: you do this in full sequence, manually.

With orchestration, master analyzes dependencies and structures the flow:

▶

1/3

Sequential

🏗️

prestashop-architect

Defines structure: Symfony controller, Grid, services, hooks

Parallel

💻

prestashop-module-dev

Implements controller and Grid

🔒

prestashop-security

Audit permissions and BO access control

🧪

prestashop-testing

Test strategy for the listing

Validation

✅

qa-reviewer

Final validation before delivery

Sequential — one step after another

Parallel — simultaneous execution

Validation — review before delivery

The parallelization rule is precise: anything that can be done independently is done in parallel. What has real dependencies — architecture before implementation, implementation before QA — stays sequential. master analyzes these constraints before routing, not after.

4. Skills: the business rules layer that changes everything

This is the least visible component, and probably the most important.

An agent without a skill is like a developer without documentation, without checklists, without team conventions. It will do something. Maybe good. Maybe not.

Skills are Markdown files that carry:

PrestaShop-specific patterns and conventions for each domain
Validation checklists (what a module must contain, in what order)
Version references (PS8 vs PS9, BC breaks, deprecated APIs)
Non-negotiable business rules (how to handle multistore, how to declare a Symfony service in our context)

Each agent loads its skills before acting. prestashop-module-dev loads prestashop-dev. prestashop-phpstan loads php-pro. prestashop-compat-advisor loads prestashop-cmdbus-compat.

What this changes concretely: the agent doesn’t start from scratch every time. It starts from a PrestaShop-contextualized knowledge base. It knows the BC breaks of PS9. It applies the project’s naming conventions. It spots patterns to avoid on multistore.

It’s the difference between an external contractor discovering your codebase and a senior who has worked on it for 3 years.

Two concrete routing examples

Case 1 — Implementing a stock synchronization module via webhook

Request: “Create a PrestaShop module that receives an incoming webhook to update stocks in real time.”

master analyzes the request and detects a real dependency: prestashop-module-dev cannot implement without the architecture being set. Step 1 is therefore sequential. However, once the structure is defined, security, implementation, and API design have no dependencies between them.

Step 1 — Sequential

🏗️

prestashop-architect

Sets structure: hook, ObjectModel or Doctrine, queue management

Step 2 — Independent work

💻

prestashop-module-dev

Implements endpoint, handler, stock update

🔒

prestashop-security

Validates webhook signature, controls inputs, rate limiting

🔌

prestashop-webservice

Designs API contract, verifies Admin API PS9 compatibility

Step 3 — Final validation

✅

qa-reviewer

Full diff review before delivery

Sequential

Parallel

Validation

That’s the real value of orchestration: not blind parallelization, but parallelization where dependencies allow. master analyzes constraints, decides what can be parallelized and what must remain sequential. A generalist agent doesn’t have this mechanism — it does everything in one go or waits for manual instructions.

Case 2 — Complete module packaging for the PrestaShop Marketplace

Request: “The module is ready. Prepare everything for Marketplace submission.”

This is the perfect case for total parallelization. The 6 packaging agents have no dependencies between them — they all work on distinct files.

Packaging — All in parallel

🛡️

prestashop-htaccess

Sensitive file protection rules

📄

prestashop-license

License headers on all PHP files

🔧

prestashop-php-headers

PHP version & PS compatibility

🔍

prestashop-phpstan

Static analysis, zero blocking errors

✨

prestashop-phpcsfixer

PSR code standards + conventions

📝

prestashop-changelog

CHANGELOG since last release

Final validation

✅

qa-reviewer

Packaging coherence, nothing forgotten

Sequential

Parallel

Validation

Without orchestration, this is a manual checklist you do by hand — or forget to do. With orchestration, it’s one command, one synthesis, and a module ready to submit.

What this changes for a PrestaShop agency

If you manage modules for multiple clients, or maintain a catalog of modules in parallel, orchestration is not a technical luxury.

It’s the structural answer to three real problems:

The depth problem — PrestaShop 9 with Admin API, API Platform, CQRS, and Symfony 6 has a massive technical surface. No generalist agent covers it well. Specialized agents with up-to-date skills do.

The parallelism problem — A module version upgrade often involves code, security, changelog, translations, and packaging all at once. Orchestration does this in one pass.

The regression problem — qa-reviewer at the end of the chain is not optional in my architecture. It’s a rule. Every risky output goes through review before being returned.

What this architecture doesn’t do

Let me be honest about this.

This architecture doesn’t replace human judgment on structural decisions. If you need to choose between two architecture patterns incompatible with your deployment history, prestashop-architect can model the options — but you decide.

It also doesn’t replace knowledge of your own codebase. Skills are generic relative to PrestaShop, not specific to your module. Adapting them to your context is a one-time configuration job you must do — but you must do it.

And it doesn’t solve missing data problems. If you ask prestashop-translator to translate into 12 languages and you don’t have reference human translations, it will invent. And invented translations are often wrong.

Orchestration structures AI expertise. It doesn’t create expertise where there is none.

Where we are and where it’s going

This architecture runs in production on our projects. It currently covers:

14 PrestaShop agents (build, support, packaging)
8 SEO agents
10 frontend agents (Bootstrap + Tailwind)
5 PHP agents
A blog pipeline with mandatory final validation

The next step: agents that self-improve. Not in the science-fiction sense — in the practical sense. An agent that after each debugging session documents the pattern in the corresponding skill. A memory that grows with projects.

PrestaShop is a complex ecosystem. Generalist AI skims over it. Specialized orchestration understands it.

The difference shows in the code.

Nicolas Dabène is Senior PHP Developer & AI Orchestrator, Platinum PrestaShop Partner, 5 PrestaShop Awards, +100,000 module installations. He shares his approach on nicolas-dabene.fr and LinkedIn.

Developing PrestaShop Modules with AI Agents: What Actually Changes

Tue, 31 Mar 2026 00:00:00 +0000

It’s 11pm. Production deployment is tomorrow morning. A PrestaShop 9 hook isn’t firing — the module works fine on PS 8, nothing on PS 9. The context required to diagnose: Tactician to Messenger migration, Symfony Service Container, CQRS compatibility, hook registry changes between versions. Three years of ecosystem evolution, packed into a single debug session.

That’s the daily reality of the senior PrestaShop developer. Not because they lack experience — but because the platform has accumulated a density of context that no generic tool can absorb correctly.

TL;DR — If you only have 30 seconds: using specialized PrestaShop AI agents changes the nature of development work, not just its speed. This isn’t enhanced autocomplete — it’s a different organization of expertise. The AI model matters less than the precision of the context you give it.

🧩 The Problem: PrestaShop Is Impossible to Hold in Your Head Completely

PrestaShop 8 and 9 coexist in production across the majority of merchants. Between the two versions: a Command Bus migration (Tactician → Symfony Messenger), a partial Admin API rewrite, a new reference theme (Classic → Hummingbird v2), changes to multistore handling, and continuously evolving PHPStan constraints.

An active module developer simultaneously juggles:

Hook behavior differences between versions
Which Symfony patterns are acceptable vs deprecated per target version
PrestaShop-specific security rules (tokens, ACL, Smarty escaping)
Marketplace packaging constraints (PHP headers, .htaccess, licenses)
Legacy MD5 translation files still active on thousands of stores

Ask a generic LLM to implement a PrestaShop 9 hook with the correct CQRS pattern — it outputs PrestaShop 1.7 code, with direct database calls, no token validation, and a service container wired by hand like it’s 2019. The result compiles. It doesn’t work.

💡 The problem isn’t the model’s capability. It’s the absence of precise domain context.

🤖 Before: AI as a Code Copilot

Most PrestaShop developers use AI the same way today: autocomplete, boilerplate generation, occasional questions about PHP 8.x syntax.

It’s useful. It’s marginal.

The real gain is blocked by a structural problem: the model doesn’t know what context it’s working in. It doesn’t know your module needs to run on both PS 8.2 AND PS 9.0, that you use Doctrine for entities but ObjectModel for legacy compatibility, that your Bitbucket pipeline requires PHPStan level 5 before any merge, that your translation files use 1.7 MD5 keys.

Every session starts from zero. Every response must be checked against a context the tool doesn’t have. The developer spends as much time correcting as coding.

🚀 What Changes with Specialized Agents

The fundamental difference isn’t in the AI model — it’s in the domain knowledge layer that accompanies it.

A specialized PrestaShop agent doesn’t start from scratch. It knows the patterns acceptable per version, the expected security rules, the packaging constraints, the compatibility pitfalls. When it produces code or a recommendation, it’s not generic generation — it’s code that accounts for the real constraints of the platform.

The closest metaphor: the difference between a brilliant junior developer you need to brief on everything, and a senior with ten years of PrestaShop modules in production. The junior can write very good code. The senior instinctively knows which questions to ask, which problems to anticipate, which constraints not to ignore.

This isn’t magic. It’s contextual precision.

💡 It’s not the model’s power that changes everything — it’s the quality and precision of the context you give it.

📊 What Concretely Changes

I’ve been working with this approach for several months. Here’s what’s genuinely different in the results — without detailing the method.

Security Is No Longer an End-of-Sprint Checklist

Before: module security audits arrived at the end of development, often reduced to a quick read-through. Vulnerabilities made it to production.

Now: security is integrated from the architecture phase. A dedicated agent audits data flows, traces sources to sinks, verifies CSRF protections, Smarty escaping, SQL queries. The report is structured, reproducible, with severity levels and concrete remediation steps. It’s no longer an opinion — it’s an audit.

Architecture Accounts for Version Constraints from the Spec

Before: PS 8/9 compatibility issues were discovered during testing, sometimes after delivery.

Now: an agent that knows version differences can flag during design that a specific pattern is deprecated in PS 9, that an interface changed namespace, that a service must be declared differently per target version. Architecture decisions are made with the right constraints as input.

Packaging Is No Longer a Release Burden

Before: PHP headers on every file, .htaccess, License.txt, semantic changelog, PHPStan configuration, CI pipeline — every release was a tedious manual session with a risk of missed items.

Now: these tasks are handled autonomously and systematically. The changelog is generated from commits, headers are verified across all files, PHPStan runs before every release. What used to take half a day takes a few minutes.

Architecture Decisions Are Documented and Retrievable

Before: technical decisions lived in Slack threads, emails, and people’s heads. They disappeared with team turnover.

Now: every structural decision is persisted with its context, reasoning, and date. At the next session, the project context is recoverable. The developer picks up where they left off — even after several weeks.

🛡️ What Doesn’t Change

Let me be direct about the limits, because this subject attracts a lot of overpromising.

Specialized AI agents don’t replace the senior developer’s judgment. They don’t know your business choices, your specific technical debt, your team constraints, your decision history. They don’t see what your client didn’t say in their brief. They don’t sense that a “simple” feature will conflict with a third-party module already in production.

The developer remains the pilot. Agents execute — they don’t arbitrate.

There’s also a real learning curve. Working effectively with specialized agents requires understanding their domains of competence, their limits, and how to structure requests to get useful output. It’s not immediate.

What agents do well	What remains human
Precise PrestaShop context per version	Judgment on architecture choices
Structured security audit	Technical debt assessment
Systematic packaging and release	Understanding client needs
Decision documentation	Priority arbitration
Cross-version compatibility	Detecting conflicts with existing code

📌 Verdict: Who Should Care About This Now

Go for it if you are…

An active PrestaShop developer with a regular volume of modules to produce or maintain. The return on investment is quick once your project complexity exceeds basic CRUD modules.

An agency or team juggling multiple PrestaShop versions and multiple clients. Context capitalization across sessions and developers is particularly valuable.

You can wait if you are…

A merchant without an in-house developer — this topic doesn’t directly concern you, even if the modules you use will benefit.

A developer on simple one-shot projects — the initial setup cost doesn’t justify itself for a two-day module.

The real question isn’t “will AI replace the PrestaShop developer?” — that question is already outdated. The real question is:

Which PrestaShop developer knows how to make AI work with the precision the platform demands?

Personally, I’ve been working on this topic for over a year — and the difference between a poorly calibrated generic AI and an agent with precise domain context is as large as the difference between a junior and a senior. They’re not the same thing.

Nicolas Dabène — Senior PHP Developer & AI Orchestrator, 15 years of PrestaShop expertise, 5 PrestaShop Awards, 100,000+ module installations. Book a strategy call to explore how AI can transform your business.

Friends of Presta: The PrestaShop Expert Directory and Open Source E-commerce Community

Thu, 26 Mar 2026 00:00:00 +0000

Friends of Presta: The PrestaShop Expert Directory and Open Source E-commerce Community

Reading time: 5 min Last updated: March 26, 2026

Friends of Presta: What Is It?

Friends of Presta is a French non-profit association founded in 2021. It brings together agencies, freelancers, and module publishers specializing in PrestaShop e-commerce — in France and across Europe.

In just a few years, it has become the reference independent body for the PrestaShop ecosystem. Its three core missions:

Directory — List certified professionals (agencies, freelancers, publishers)
Events — Organize community gatherings (FOP Days → EO2S)
Security — Run the PrestaShop Hall of Fame security

The community has 1,000+ members on its Slack workspace and continues to grow.

The Directory: Finding a PrestaShop Expert

The heart of the association is its expert directory. Three types of profiles:

Profile	Examples
Agencies	Web agencies specializing in PrestaShop, migration, redesign
Freelancers	Developers, integrators, PHP/Symfony consultants
Publishers	PrestaShop module creators (payments, SEO, logistics…)

Each provider is reviewed by the community — giving rare transparency in the ecosystem.

💡 If you’re looking for a PrestaShop provider, this is the first place to check before marketplaces or forums.

What Sets Friends of Presta Apart

Independence. Friends of Presta is not tied to PrestaShop SA. It’s a neutral association governed by its members. This means:

No conflict of interest in recommendations
Open community governance
Impartial events (unlike events sponsored by a single vendor)

Security. The association runs the Hall of Fame security — a space dedicated to security alerts and patches for the ecosystem.

Events. From local meetups to structured conferences (EO2S), Friends of Presta drives the community calendar of the ecosystem.

Key Sections of the Site

The friendsofpresta.org site organizes its content into 6 sections:

Directory — Certified professionals
News — E-commerce and PrestaShop news
Modules — Module ecosystem
Projects — Calls for tender between members
Job Board — PrestaShop recruitment
Events — Community calendar

Elected Members and Governance

Friends of Presta is led by elected members. Among them: Christophe Vidal (President) and Thomas Rayrat (Vice President), who regularly co-sign major statements from the association — like the first-ever French CMS E-commerce Barometer.

This associative governance gives the ecosystem an independent voice in the face of PrestaShop’s evolution and its new owners.

How to Join the Association

Membership is open to all professionals in the ecosystem:

Sign up at friendsofpresta.org
Access Slack — 1,000+ active members
Attend events — meetups, EO2S, workshops
Contribute — security, modules, content, governance

Whether you’re a freelance developer, web agency, or merchant with a technical team — there’s a place for you.

EO2S 2026: Friends of Presta’s Signature Event

It’s today that EO2S — Ecommerce Open Source Summit takes place at Le Nida, Issy-les-Moulineaux (Paris). The first edition of this European open source e-commerce summit, hosted by Friends of Presta.

On the agenda: first joint appearance of PrestaShop and Sylius, unveiling of the first-ever French CMS E-commerce Barometer, roundtables on e-invoicing and AI.

Find the full program in my dedicated article.

TL;DR

Friends of Presta is much more than a directory. It’s the beating heart of the PrestaShop ecosystem in France and Europe: neutral, community-driven, and structured.

If you work with PrestaShop — as a developer, agency, or merchant — it’s a resource to bookmark.

👉 friendsofpresta.org

Mistral 3 vs Claude & ChatGPT + MCP Tools Plus: GDPR & AI Governance for PrestaShop Merchants

Tue, 24 Mar 2026 00:00:00 +0000

As we saw in the previous article: connecting an AI assistant to a real PrestaShop store via MCP Tools Plus + MCP Server transforms a “chatbot” AI into an operational assistant capable of:

analyzing sales
detecting stockouts
generating product descriptions
diagnosing business problems
and even executing complete workflows

with your real business data.

Today, a new player changes the equation once more: Mistral 3, a family of powerful open-source models that are more controllable and more respectful of merchant data sovereignty.

And above all — an angle the previous article didn’t cover — GDPR and AI governance are becoming unavoidable requirements for stores connecting to external models.

Here’s how Mistral 3 performs on those same tests, while improving data privacy and control.

🧠 Why Mistral 3 Changes the Equation for PrestaShop

Unlike proprietary models, Mistral 3 is:

open source (Apache 2.0),
usable locally or on controlled hosting,
customizable for specific business needs.

👉 In a GDPR context, this is a major advantage: you retain full control over where and how your store’s data is processed.

This is crucial for a PrestaShop merchant handling customer data, order history, and buyer segments. It lets you define strict AI governance, without depending on an external service that might store or exploit your data in unpredictable ways.

🧪 The Same Tests with Mistral 3 + MCP Tools Plus

For each of the following tests, the AI engine interacts with PrestaShop data via MCP Tools Plus, exactly as in the first article — but here, we replace or complement Claude/ChatGPT with Mistral 3.

Test Setup

Element	Detail
Store	Real PrestaShop 8.x — ~1,200 products, 3 years of history
Connector	MCP Tools Plus (same API for all 3 AIs)
Mistral 3	Local / controlled infrastructure deployment
Bonus criterion	Data control + GDPR traceability

🥇 Test 1 — Sales Analysis (Complex Business Query)

The Prompt

“Analyze my last quarter’s sales, identify trends, top products, flops, and give me 3 concrete actions.”

🤖 Mistral 3

Mistral 3, running locally or on your controlled infrastructure, can produce:

secure summaries with no round-trips to third-party servers
recommendations without data leaving your environment
analyses compatible with strict GDPR frameworks

The model is slightly less “magical” than Claude or GPT via external API, but the business context remains entirely under your control — drastically reducing the risk of sensitive data leaks.

Test 1 Verdict

Criterion	Mistral 3	Claude	ChatGPT
Analytical depth	4/5	5/5	4/5
Data control	5/5	2/5	2/5
GDPR compliance	5/5	2/5	2/5
Actionability	4/5	5/5	4/5

Mistral 3 wins on governance. Claude and ChatGPT stay ahead on raw analytical power.

📦 Test 2 — Stockout Detection

The Prompt

“Identify products likely to run out of stock within 15 days and propose a restocking plan.”

🤖 Mistral 3

The logic stays the same: MCP Tools Plus exposes stock + sales data, and Mistral 3 can:

project stockouts over defined periods
recommend restocking actions
output results locally, with no external data transit

👉 Once again: no data needs to leave your environment, which fully aligns with internal GDPR-compliant governance — provided the configuration is local or hosted under your responsibility.

Test 2 Verdict

Criterion	Mistral 3	Claude	ChatGPT
Calculation rigor	4/5	5/5	3/5
Locally hosted data	5/5	1/5	1/5
Immediate actionability	3/5	4/5	5/5
Decision traceability	5/5	2/5	2/5

Mistral 3 dominates on traceability and data sovereignty.

📄 Test 3 — Product Description Generation

The Prompt

“Rewrite the descriptions of 5 products for SEO, using your PrestaShop data.”

🤖 Mistral 3

Same text generation capability as Claude/ChatGPT, with additional advantages:

✔ Control over training and model parameters
✔ Application of internal brand rules (style, GDPR constraints)
✔ Log capture for audit / compliance purposes

This ability to log and trace text generation is a major strength for AI governance. In case of an audit, you know what, why, and how responses were produced — without depending on an external provider.

Test 3 Verdict

Criterion	Mistral 3	Claude	ChatGPT
Writing quality	4/5	5/5	4/5
Auditability / logs	5/5	2/5	2/5
Model customization	5/5	1/5	1/5
SEO optimization	3/5	4/5	5/5

Mistral 3 leads on compliance and customization.

🧩 Test 4 — Operational Diagnostic

The Prompt

“Why did my conversion rate drop?”

🤖 Mistral 3

In this test, what matters isn’t just the quality of the analysis but the control over conclusions and action plans.

With Mistral 3 hosted under your control:

✅ You can define processing limits
✅ You can record reasoning steps
✅ You can apply strict AI governance (logs, traceability)

These measures are GDPR best practices for an AI system used in a professional context, especially when handling sensitive user data.

Test 4 Verdict

Criterion	Mistral 3	Claude	ChatGPT
Diagnostic methodology	4/5	5/5	3/5
Use of local data	5/5	2/5	2/5
Logs & traceability	5/5	2/5	2/5
Actionable conclusions	3/5	5/5	3/5

🤖 Test 5 — Full Autonomous Workflow

The Prompt

“Complete audit + propose and apply certain actions without supervision.”

🤖 Mistral 3

This round reveals a key difference:

🔹 Claude/ChatGPT with external API execution → fast, but opaque remote data processing
🔹 Localized Mistral 3 → more cautious, but fully audited, traceable, and controlled

For a merchant, control and traceability can be more important than raw speed — especially when AI automates actions affecting personal or financial data.

Test 5 Verdict

Criterion	Mistral 3	Claude	ChatGPT
Safety / caution	5/5	5/5	3/5
Execution autonomy	3/5	3/5	5/5
Complete audit trail	5/5	2/5	2/5
Speed of results	3/5	3/5	5/5

🏆 Final 5-Test Scorecard

Test	Mistral 3	Claude	ChatGPT	GDPR Winner	Perf Winner
Sales analysis	18/20	19/20	15/20	Mistral 3	Claude
Stockout detection	17/20	19/20	14/20	Mistral 3	Claude
Product descriptions	17/20	18/20	18/20	Mistral 3	ChatGPT/Claude
Diagnosis	17/20	20/20	12/20	Mistral 3	Claude
Autonomous workflow	16/20	16/20	17/20	Mistral 3	ChatGPT

Mistral 3 systematically wins on governance. Claude dominates on raw performance.

AI governance for a PrestaShop merchant involves several dimensions:

Dimension	Without Mistral 3	With Local Mistral 3
Data access control	Provider-dependent	Under your full control
AI decision traceability	Opaque / limited	Complete, exploitable logs
Logs for audit	Not available	Configurable and exportable
Revoking an agent action	Difficult	Possible and documentable
DPIA & documentation	Complex	Simplified (local processing)
External dependency	High	Reduced or eliminated

What Mistral 3 + MCP Tools Plus Concretely Enables

With this combination, you can operate an AI system where:

➡ Data stays under your own hosting
➡ You generate exploitable logs for every processing activity
➡ You define custom processing rules
➡ You can demonstrate compliance when required (data authority, audit, client)
➡ You reduce external dependencies and associated risks

All of this without sacrificing the power of generative AI applied to your business.

📊 Which Architecture to Choose Based on Your Profile?

Choose Mistral 3 + MCP Tools Plus if:

Data sovereignty is a priority for you
You handle sensitive customer data (health, finance, B2B)
You need to be able to justify every AI decision (audit, GDPR)
You have or can set up a controlled infrastructure
You want to fine-tune the model on your specific business domain

Choose Claude or ChatGPT + MCP Tools Plus if:

You need the best raw performance right away
Execution speed takes priority over governance
Your store handles low-sensitivity data
You don’t have resources to host a model locally
You want rapid deployment without infrastructure overhead

The Hybrid Approach (Recommended)

💡 Use Mistral 3 for processing that involves sensitive data, Claude or ChatGPT for creative tasks and rapid workflows.

With MCP Tools Plus, the same connector can feed all three models. You decide which brain accesses which data — and that’s exactly what good AI governance requires.

📌 In Conclusion

The tests we ran with MCP Tools Plus are not a simple comparison between AI models.

They reveal a reality: AI connected to your business data changes everything.

Today, with Mistral 3, you can go even further:

✅ Retain complete control over your data
✅ Apply strict AI governance rules
✅ Stay GDPR-compliant without compromise
✅ Build useful, auditable, integrated AI agents for your business

The question is no longer just:

Claude or ChatGPT?

It becomes:

How do I keep control of the AI running my store?

And that is a genuine strategic inflection point for PrestaShop merchants.

Nicolas Dabène — Creator of AI solutions for PrestaShop. Book a strategy call to explore how AI can transform your business.

EO2S 2026: Open Source E-commerce Summit — March 26, Paris

Sat, 21 Mar 2026 00:00:00 +0000

EO2S 2026: Open Source E-commerce Summit

Reading time: 12 min Last updated: March 21, 2026

EO2S 2026: An Open Source E-commerce Summit Redefining the Game

EO2S 2026 — Ecommerce Open Source Summit — is Europe’s first open source e-commerce summit. It takes place on March 26, 2026 at Le Nida, Issy-les-Moulineaux (Paris), organized by Friends of Presta (non-profit association, 1,000+ Slack members).

This is the first joint appearance of PrestaShop and Sylius since their merger at the end of 2025, following PrestaShop’s acquisition by cyber_Pixel. Mikołaj Król, CEO of both projects, will deliver the closing keynote. 17+ sessions cover AI, cybersecurity, e-invoicing, and digital sovereignty.

Ticket at €30 — shop.friendsofpresta.org.

TL;DR — If you only have 30 seconds: PrestaShop + Sylius on stage together for the first time, unveiling of the first-ever French CMS E-commerce Barometer, 17+ sessions, 150+ professionals. March 26, Paris. €30.

EO2S 2026 Program: 5 Key Moments

1. CMS E-commerce Barometer in France (Opening Keynote — 9:15 AM)

The morning opens with what could be the most significant announcement of the day: the unveiling of the first-ever French CMS E-commerce Barometer.

Why does it matter? Because the French open source e-commerce market has never been mapped independently and with hard data. Between Shopify’s figures, WooCommerce estimates, and assumptions about PrestaShop, there was no clear, factual vision.

Olivier Binet (Managing Director, PrestaShop), Christophe Vidal (President, Friends of Presta), and Thomas Rayrat (Vice President, Friends of Presta) co-sign this opening keynote. If you’re an e-commerce professional, this data directly concerns you — whether you’re a developer, integrator, merchant, or software vendor.

I’ve had the opportunity to speak with several ecosystem players over the past few months. This barometer, if it delivers on what we’re being promised, could well become the reference for all consulting firms, media outlets, and decision-makers who talk about e-commerce without ever having reliable figures on the open source segment.

2. PrestaShop and Sylius: First Joint Appearance on Stage

One year after the launch of PrestaShop’s Call for Contribution, Paule Morizot (Head of Product, PrestaShop) returns with contributors to take stock. What worked? How has community governance evolved? What are the current priorities?

It’s also an opportunity to understand how Sylius fits into this dynamic — and most importantly, how the two projects plan to work together on a shared Symfony foundation.

3. E-Invoicing with PrestaShop: 2026 Obligations

Mandatory e-invoicing in France (and across Europe with EU Directive 2014/55/EU) remains a topic where many merchants are sailing blind. The roundtable moderated by Marie-Sophie Cuinet (VP Category Management, PrestaShop) brings together Atoo Next and OpenSI for a concrete discussion:

Where does the obligation stand? Timeline, penalties, exemptions
What open source solutions are available today?
How to migrate without breaking things?

If your store isn’t yet e-invoicing compliant, this session should be your top priority.

4. Sessions: AI E-commerce, SEO, Cybersecurity, Digital Sovereignty

The program covers a broad spectrum of topics:

Agentic commerce — when AI makes autonomous purchasing decisions
AI in e-commerce — concrete use cases beyond the chatbot
SEO in the AI era — how AI language models read your product listings
E-commerce cybersecurity — 2026 threats, defenses, best practices
Digital sovereignty — the open source argument against US SaaS solutions
Sylius migration — real-world experiences and best practices
PrestaShop internationalization — go global without losing your mind

If AI is a topic that interests you — and it should — I refer you to my article on AI governance in PrestaShop which lays out what you need to master before deploying artificial intelligence in a store.

5. Mikołaj Król — Closing Keynote, PrestaShop & Sylius

The closing is signed by Mikołaj Król, CEO of PrestaShop and Sylius since the end-2025 merger. This is the first time he speaks publicly before both communities gathered together.

Beyond the visionary talk, we can expect concrete announcements on:

The technical roadmap for PrestaShop + Sylius convergence
The expected synergies between the two platforms
The European open source strategy against market concentration

Who Is Mikołaj Król, CEO of PrestaShop & Sylius?

Behind this closing keynote stands a man: Mikołaj Król. Before leading PrestaShop and Sylius, he drove Sylius’s growth to make it one of Europe’s most advanced Symfony e-commerce frameworks. His profile is technical, not marketing — which sets him apart from the usual ecosystem keynotes.

When cyber_Pixel acquired PrestaShop at the end of 2025, he was appointed to lead both projects. His arrival wasn’t an accident: it was the choice of someone who knows the field, knows the tech, and wants to build rather than manage.

His closing keynote at EO2S 2026 will likely be the most important of his young joint tenure at the helm of both platforms.

EO2S vs FOP Days: What Really Changes

The name change isn’t cosmetic. Here’s what the EO2S rebrand concretely means:

Former format (FOP Days)	New format (EO2S)
Focused on the PrestaShop community	Open to the entire European open source ecosystem
Technical day format	Conference + roundtables + workshops + networking format
Dev/technical audience	Mixed audience: devs, merchants, decision-makers, agencies
Community sessions	Structured program with keynotes, roundtables, workshops
France	Stated European ambition

The leap in maturity is noticeable. Friends of Presta is moving from a community meetup to a structured professional event.

Partners on Site: The Full Ecosystem

EO2S 2026 brings together a panel of partners representative of the open source e-commerce ecosystem:

Partner	Positioning	Site
PrestaShop	Open source e-commerce CMS	friendsofpresta.org
Sylius	Symfony e-commerce framework	friendsofpresta.org
OpenSi	Open source ERP/PIM for commerce	friendsofpresta.org
Atoo Next	E-invoicing solutions	friendsofpresta.org
Lyra	Online payments	friendsofpresta.org
Mollie	Payment platform	friendsofpresta.org
Crisp	Chat and customer support	friendsofpresta.org
Doofinder	E-commerce search / SEO	friendsofpresta.org
Store Commander	PrestaShop administration tools	friendsofpresta.org
KerAwen	Open source POS software	friendsofpresta.org
Motive	E-commerce logistics	friendsofpresta.org
Gladhost	Hosting	friendsofpresta.org
Versus Venture	Holding PrestaModule & BusinessTech	friendsofpresta.org

Covering the entire value chain of an online store.

What This Event Says About the Health of Open Source E-commerce

Beyond the program, EO2S 2026 sends a clear signal: European open source e-commerce isn’t retreating — it’s restructuring.

A few facts:

PrestaShop powers 200,000+ active stores across 80+ countries, holding the #1 position in France, Poland, and Spain (source: PrestaShop)
The PrestaShop + Sylius merger creates a coherent technical player (shared Symfony foundation, convergent roadmap)
The Friends of Presta community (non-profit association, 1,000+ members) brings stable, independent governance
Demand for sovereignty-aware solutions (European hosting, data in Europe, no dependency on a US hyperscaler) creates an opportunity window

EO2S 2026 is the first public rendezvous of this new era. The French CMS E-commerce Barometer, if it holds up, could become a reference for sector professionals.

Who Should Really Go (And Who Can Skip It)

Let me be direct. Not every event is for everyone. Here’s my honest analysis:

You should go if you’re…

1. PrestaShop / Sylius developer The technical sessions on Sylius migration and future architecture will give you a concrete view of where the platform is headed. It’s also a chance to network with core contributors — which is always valuable.

2. E-commerce merchant with significant volume The e-invoicing roundtable alone justifies the trip. And the barometer will give you data-backed arguments for your strategic discussions.

3. Agency or module vendor You’re in the right place to understand market direction and meet future partners or clients. In-person networking is still irreplaceable.

4. IT decision-maker with sovereignty concerns The open source vs. US SaaS argument takes on new dimensions with the PrestaShop + Sylius merger. This is the moment to evaluate whether this direction suits you.

You can probably skip if…

1. You’re hunting for clients at all costs This isn’t a B2B trade show. It’s a professional event where network quality trumps quantity.

2. You have no connection to the PrestaShop/Sylius ecosystem You might feel a bit out of place. EO2S owns its specialization.

5 Questions to Ask Before You Go

If you’re attending EO2S 2026, here are the questions I encourage you to ask the speakers:

What is the precise roadmap for PrestaShop + Sylius convergence? We want concrete details, not promises.
How will the PrestaShop module system evolve? Will my current modules still work in 3 years?
What does “digital sovereignty” actually mean for a merchant? Beyond the rhetoric, what are the tangible benefits?
How will community governance be structured? Who decides, how, and with what transparency?
What is the timeline for mandatory e-invoicing? Dates, penalties, exemptions — everyone needs clarity.

Practical Info

EO2S — Ecommerce Open Source Summit

Date: March 26, 2026
Venue: Le Nida, Issy-les-Moulineaux (Paris)
Doors open: 8:30 AM (coffee + networking)
Tickets: €30 — shop.friendsofpresta.org
Organizer: Friends of Presta (non-profit association)
Expected attendance: ~150+ professionals
Hashtag: #EO2S2026

Conclusion: The Verdict

If you are:

PrestaShop / Sylius developer → technical sessions, networking, roadmap
E-commerce merchant → e-invoicing roundtable, barometer, partner solutions
Agency / vendor → ecosystem, prospecting, competitive benchmarking
IT decision-maker → digital sovereignty, open source vs. SaaS

EO2S 2026 has something for you. And at €30, it’s probably the best value-for-money e-commerce event of the first half of 2026.

I’ll be there personally. The program more than justifies the trip, and the atmosphere of an event where the PrestaShop and Sylius communities meet for the first time since the merger feels like a moment not to be missed.

See you March 26 at Le Nida.

A debrief will be published within 48 hours of the event with key announcements and speaker slides.

Beyond Injection: The Rise of "Promptware" and Self-Replicating AI Worms

Thu, 19 Mar 2026 00:00:00 +0000

In November 1988, Robert Tappan Morris, a Cornell student, released what would become the first computer worm to cripple the nascent Internet. By exploiting technical vulnerabilities in the sendmail and finger protocols, he managed to take 10% of the world’s machines offline. Thirty-six years later, the “ghost” of Morris has returned to haunt us in a radically more insidious form: the Morris II worm.

The irony is biting for the cybersecurity community. While we spent three decades hardening binary code and securing low-level access, we opened the doors of our infrastructure to a technology that treats natural language — our own language — as executable code. In 2025, our AI agents are no longer simple chatbots; they are assistants with “Read/Write” permissions on our emails, calendars, and databases. This deep integration transforms productivity into “cross-boundary liability,” paving the way for autonomous “zero-click” attacks capable of spreading at the speed of API calls.

The Concept of “Promptware”: Prompt Injection Is Just the Beginning

The term “prompt injection” has become dangerously reductive. It suggests an isolated flaw, a simple filtering “bug.” In reality, we are facing the emergence of Promptware: a class of malware where natural language becomes the vector for a complete “Kill Chain.”

Unlike SQL, where commands can be isolated from data, LLMs suffer from a tokenization paradox: they process input as a single, undifferentiated sequence of tokens. There is no architectural boundary between system instructions and user data. This is what triggers the “Confused Deputy” attack: the AI, deceived by malicious content, uses its legitimate privileges to carry out criminal actions.

On this subject, the UK’s National Cyber Security Centre (NCSC) issued a warning that has become authoritative:

“Prompt injection is shaping up to be one of the most persistent problems in AI security. Treating this as a simple variant of SQL injection is a serious mistake; this problem may never be fully ‘fixed.’”

The Promptware “Kill Chain”: 7 Steps to Compromise

Building on the work of Bruce Schneier and his team, we can now model the Promptware attack according to a seven-step structure, revealing a sophistication that far exceeds simple chatbot sabotage.

1. Initial Access

The payload enters through direct or, more commonly, indirect injection. The AI analyzes a poisoned email, document, or web page, and the malicious content infiltrates its execution context.

2. Privilege Escalation (Jailbreaking)

The attacker uses “persona” techniques or adversarial suffixes to bypass security filters and force the model to ignore its ethical directives.

3. Reconnaissance

Unlike traditional malware, this step occurs after the jailbreak. The attack manipulates the AI into listing its own capabilities, connected services (Slack, GitHub), and access to sensitive data.

4. Persistence

The malware poisons the RAG (Retrieval-Augmented Generation) memory or the agent’s history to ensure the payload is re-executed with each new session.

5. Command and Control (C2)

The AI is instructed to fetch new directives from a remote server (e.g., via a text file on GitHub), turning the agent into a dynamic Trojan.

6. Lateral Movement

The infection spreads. For example, the AI is forced to forward the malicious payload to all contacts in the mailbox or inject it into a shared Notion workspace.

7. Actions on Objective

The final phase. Real-world examples already exist: a crypto agent AiXBT manipulated to steal $105,000 (55 ETH), or a car dealership chatbot forced to sell an SUV for $1. In the study “Invitation Is All You Need,” researchers even managed to force an AI to launch Zoom to spy on the user.

The “Lethal Trifecta”: Why Your Agents Are So Vulnerable

Expert Simon Willison defined the “Lethal Trifecta” — three conditions that, when combined, make an AI application virtually indefensible:

Access to sensitive data: The AI can read private information (PII, trade secrets).
Exposure to untrusted content: The AI processes data from external sources (emails, web search results).
Ability to communicate externally: The AI can send API requests, emails, or post on forums.

In this context, the LLM becomes a blind executor. Since there is no semantic distinction between “summarize this email” and “execute the order contained in this email,” the agent becomes the weapon of its own destruction.

Morris II: The First Self-Replicating AI Worm in Action

The Morris II worm is no longer theoretical. Researchers have demonstrated that a poisoned email can trigger autonomous propagation between different assistants (ChatGPT, Gemini, LLaVA).

The scenario is terrifyingly simple: the user receives an email. They don’t even need to open it. The AI assistant, running in the background to index or summarize the inbox, processes the message. The malicious prompt contained in the email “jailbreaks” the assistant, ordering it to extract recent contacts and send them a copy of that same email. It is the return of the 1988 worm, but without a software vulnerability: it is a pure semantic failure.

The MCP Protocol: A New Playground for Attackers

The arrival of Anthropic’s Model Context Protocol (MCP) aimed to standardize the connection between AI and tools. Yet it expands the attack surface. Recent analyses show that 43% of MCP servers are vulnerable to command injection. The risk is particularly high for tools like mcp-remote (over 437,000 installations), where misconfiguration allows arbitrary code execution (RCE).

Security here does not depend on the protocol, but on its implementation. For remote servers, the use of OAuth 2.1 with PKCE (Proof Key for Code Exchange) is imperative, though too often neglected. As researchers point out: “The MCP protocol cannot enforce security at the protocol level.”

Defense: Moving from Signatures to Behavior

The adaptive and polymorphic nature of Promptware renders traditional antivirus solutions obsolete. We must shift from signature-based defense to behavioral AI.

Characteristic	Traditional Threats	Promptware Variants (AI)
Payload evolution	Fixed code; known signatures.	Learns and rewrites its prompts in real time (semantic polymorphism).
Propagation vector	OS or protocol vulnerabilities.	API manipulation and inter-agent communication.
Detection surface	Network patterns, binary files.	Token consumption anomalies and unusual API calls.
Propagation speed	Minutes or hours.	Seconds via automated workflows (RPA/Agents).

Imperative Prevention Strategies

Instruction hierarchy: Use strict delimiters and prompt structures that isolate data from system commands.
Strict segmentation: Isolate models processing external content from critical databases (mandatory mTLS for server-to-server communications).
Human-in-the-loop: Require manual approval for any high-risk action (fund transfers, file deletion, mass email sending).

Conclusion: Toward Autonomy Under High Surveillance

The autonomy of AI agents is a double-edged sword. The more “hands” we give them to act on the world, the more levers we offer attackers. The risk of seeing entire infrastructures compromised by a simple phrase hidden in an email signature is a technical reality of 2025.

The productivity offered by AI cannot justify such architectural fragility. The only viable response is the adoption of a Zero Trust model applied to agents: never trust inputs, verify every tool call, and monitor every token consumed. The question is no longer whether your agents will be targeted, but whether they are isolated enough not to become patient zero of a viral epidemic of an entirely new kind.

AI Governance in PrestaShop: The Essential Strategic Framework for 2026

Tue, 17 Mar 2026 00:00:00 +0000

AI Governance in PrestaShop: The Essential Strategic Framework for 2026

March 17, 2026

Introduction

Artificial intelligence is no longer just a marketing gimmick in e-commerce.

Intelligent search. Automatic product sheet generation. Personalized recommendations. Dynamic price optimization. Chatbots connected to the catalog. Action orchestration via API.

In 2026, the question is no longer:

“Should I integrate AI into my PrestaShop store?”

The real question becomes:

“How do I integrate AI without losing control of my store?”

Opening PrestaShop to AI doesn’t mean abandoning control. On the contrary.

The smarter a system is, the more structured its framework must be.

In my e-commerce development practice spanning over 15 years — and today in AI orchestration applied to PrestaShop — I always observe the same friction point:

Companies adopt AI faster than they structure its governance.

Result:

untraced automatic decisions
poorly controlled data access
poorly evaluated vendor dependencies
underestimated legal risk
invisible technical debt

This article proposes a complete, pragmatic model adapted to the PrestaShop ecosystem.

1. Why AI Governance Becomes Essential in 2026

The European regulatory context has profoundly evolved.

The European regulation on artificial intelligence, adopted by the European Commission, is progressively coming into effect.

It introduces a risk-based approach.

Depending on the type of AI system used, obligations may include:

formalized risk management
data governance
technical documentation
logging
user transparency
human oversight
robustness and cybersecurity requirements

In parallel, GDPR remains fully applicable.

The CNIL (French Data Protection Authority) regularly reminds that AI is not incompatible with GDPR — but it requires a rigorous approach on:

profiling
automated decisions
data minimization
user information
access and objection rights

Concretely:

AI in e-commerce is no longer just a technical subject. It’s a strategic and organizational subject.

2. The PrestaShop Specificity: Power and Exposure Surface

PrestaShop is an extremely flexible open source e-commerce engine.

Its architecture relies notably on:

an extensible module system
a network of hooks (business events)
a Webservice API allowing CRUD operations

This architecture is ideal for integrating AI systems.

But it also presents major vigilance points.

An AI module can:

read customer data
modify a cart
adjust stock
generate product content
trigger emails
alter an order process

Without a clear framework:

rights can be too broad
actions can be opaque
logs non-existent
external dependencies poorly managed

Governance must therefore be designed at the architectural level.

3. Fundamental Principle: AI is a Governed Actor

In my orchestration-oriented architectures, I start from a simple principle:

AI is a governed client.

It should never be:

an omnipotent administrator
free access to the database
a tool without traceability
an uncontrollable black box

It must be:

identified
limited in its rights
restricted to explicit actions
logged
revocable at any time

Opening ≠ abandoning. Automating ≠ delegating without control.

This paradigm shift is central.

4. The AI Governance Model Adapted to PrestaShop

The model I propose is notably inspired by NIST risk management best practices and ANSSI (French Cybersecurity Agency) security recommendations.

It relies on six structuring pillars.

4.1 AI System Registry

You can only govern what you inventory.

Create an AI registry containing:

system name
business purpose
data used
vendor
internal owner
estimated risk level
deactivation mechanism
model version

Even a simple shared spreadsheet constitutes a maturity leap.

4.2 Data Governance

Data is the heart of e-commerce.

In PrestaShop:

customers
orders
addresses
navigation
catalog
statistics

Before any AI integration:

Map flows
Identify personal data
Apply minimization
Separate test and production
Frame Webservice API usage

If the system personalizes or segments, profiling becomes a central subject.

A DPIA (Data Protection Impact Assessment) may be necessary depending on the use case.

4.3 Proportionate Human Oversight

Even an automated system must remain supervisable.

This can translate into:

feature flags
intermediate workflow
“pending” status before validation
activation thresholds
manual override

Human oversight doesn’t mean slowing down.

It means keeping the ability to stop.

4.4 AI and LLM Specific Security

LLM systems expose to new risks.

OWASP recommendations on LLM vulnerabilities are particularly relevant.

Essential principles:

never directly inject sensitive data into a prompt
filter outputs before database writes
isolate environments
log interactions
control external plugins

AI security should not be added afterwards.

It must be designed from the architecture.

4.5 Monitoring and Drift

A model performing well today can degrade tomorrow.

Seasonality. Catalog changes. Behavior evolution.

Without monitoring:

drift remains invisible
performance drops
trust disappears

Implement:

performance metrics
structured logs
alerts
monthly review
rollback mechanism

4.6 Dependencies and Vendor Management

Many AI integrations rely on:

external APIs
cloud services
proprietary models

Each dependency is a potential risk:

service interruption
contractual evolution
data policy change
cost increase

Governance involves:

vendor analysis
clear contractual clauses
flow mapping
exit plan

5. Pragmatic Roadmap in 4 Phases

Phase 1: Foundations

create AI registry
map flows
define internal roles
formalize AI data policy
raise team awareness

Phase 2: Controlled Pilot

Choose a non-critical use case:

description generation
internal search engine
simple recommendations

Implement:

logs
human oversight
monitoring
shutdown procedure

Phase 3: Industrialization

secure CI/CD integration
secrets management
automated tests
model versioning
regular registry review

Phase 4: Demonstrable Compliance

formalized documentation
monitoring evidence
complete logging
incident management process
annual AI systems review

6. Strategic Opportunity for PrestaShop Developers

AI doesn’t replace developers.

It shifts value.

The developer becomes:

architect
orchestrator
framework guardian
governed system designer

The differentiating skill in 2026 is no longer just the ability to code a module.

It’s the ability to design a controlled system.

7. Towards Collective Ecosystem Maturity

It would be relevant for the PrestaShop Project to eventually propose:

an official AI & modules guide
a transparency manifest
standardized security best practices

The ecosystem would gain in trust and robustness.

Conclusion

AI in PrestaShop is not dangerous.

Improvisation is.

Governance transforms AI:

from an invisible risk
to a controlled lever
from an experimental tool
to a strategic infrastructure

In 2026, the real differentiating skill is governed orchestration.

And in modern e-commerce, orchestration without governance is just a gamble.

The question is therefore no longer:

“How do I add AI?”

But:

“How do I build controlled, traceable, and strategic AI in PrestaShop?”

That’s where true transformation begins.

Key Takeaways — AI Governance & PrestaShop

The 5 essential points to retain about AI governance in PrestaShop for 2026:

AI is a governed client, not an administrator. It must be identified, limited in its permissions, logged, and revocable at any time. Opening PrestaShop to AI doesn’t mean surrendering control — it means structuring it more rigorously.
The 6 indispensable pillars: AI system registry, data governance, proportionate human control (feature flags, override), LLM security (prompt/output filtering, OWASP), drift monitoring, vendor dependency management.
Start small, govern from day one. A simple AI registry (shared spreadsheet) and a pilot on a non-critical use case (product description generation) is enough to begin. The key is establishing traceability before scaling.
AI Act + GDPR make governance mandatory. In 2026, AI in e-commerce is no longer purely a technical topic — it’s strategic, organizational, and legal. Risks include untracked automated decisions, poorly controlled data access, and underestimated vendor dependencies.
The differentiating skill in 2026: governed orchestration. PrestaShop developers no longer just code modules — they design controlled systems where AI operates within a defined framework. That capability is what creates lasting value.

About the author: Nicolas Dabène has been supporting companies in their e-commerce transformation for over 15 years. PrestaShop specialist and AI orchestration architect, he shares his expertise on ndabene.com.

Evolution of CartRule.php: PrestaShop 9.0.x → 9.1.x

Thu, 05 Mar 2026 00:00:00 +0000

Context

The 9.1.x branch of PrestaShop introduces a new Discount system, protected behind a feature flag. This structural change is directly reflected in classes/CartRule.php, which serves as the foundation for the new system while maintaining backward compatibility with the legacy cart rules system.

Sources: DevDocs 9.1.x, Official Blog, Core Monthly January 2026, GitHub develop branch.

1. New imports and dependencies

9.0.x

The CartRuleCore class in 9.0.x uses classic PrestaShop imports without dependency on the new discount system.

9.1.x (develop)

New use statements appear at the top of the file:

use PrestaShop\PrestaShop\Adapter\ContainerFinder;
use PrestaShop\PrestaShop\Adapter\Discount\Application\DiscountApplicationService;
use PrestaShop\PrestaShop\Core\Domain\CartRule\CartRuleSettings;
use PrestaShop\PrestaShop\Core\Domain\Discount\DiscountSettings;
use PrestaShop\PrestaShop\Core\Domain\Discount\ValueObject\DiscountType;
use PrestaShop\PrestaShop\Core\FeatureFlag\FeatureFlagSettings;
use PrestaShop\PrestaShop\Core\FeatureFlag\FeatureFlagStateCheckerInterface;

Impact: The CartRule class now integrates with:

DiscountType: a Value Object that distinguishes application levels (ORDER_LEVEL, PRODUCT_LEVEL)
DiscountApplicationService: the service that orchestrates discount application in the new system
FeatureFlagSettings / FeatureFlagStateCheckerInterface: to dynamically check if the new Discount system is enabled

2. Discount Feature Flag Integration

New method: `isDiscountFeatureFlagEnabled()`

A key addition in 9.1.x is the private method that checks the feature flag state:

private function isDiscountFeatureFlagEnabled(): bool
{
    return $this->getFeatureFlagManager() !== null
        && $this->getFeatureFlagManager()->isEnabled(FeatureFlagSettings::FEATURE_FLAG_DISCOUNT);
}

Role: This method acts as a switch throughout the file. When the flag is disabled (default), behavior remains identical to 9.0.x. When enabled, new calculation logic takes over.

New method: `getFeatureFlagManager()`

Protected method that instantiates the FeatureFlagStateCheckerInterface from the Symfony container:

protected function getFeatureFlagManager(): ?FeatureFlagStateCheckerInterface

3. New concept: `getType()` — Discount Typing

Added in 9.1.x

The getType() method is introduced to classify a cart rule according to the new discount model with 4 types:

Type	Description
Catalog (`PRODUCT_LEVEL`)	Discount applied to a product or product segment
Cart (`ORDER_LEVEL`)	Discount on total cart amount (excluding shipping)
Free Shipping	Free shipping
Free Gift	Free product added to order

This method returns a DiscountType Value Object based on the internal configuration of the cart rule (fields reduction_product, free_shipping, gift_product, etc.).

Developer impact: Modules that query the discount type can now use $cartRule->getType() instead of manually checking individual fields.

4. Changes in `getContextualValue()`

The getContextualValue() method — the core of discount calculation — contains the most significant changes.

4.1 Percentage reduction at order level (ORDER_LEVEL)

9.0.x: Percentage reduction is applied only to product total.

9.1.x: When the feature flag is enabled and type is ORDER_LEVEL:

if ($this->getType() === DiscountType::ORDER_LEVEL
    && $this->reduction_percent > 0.00
    && $this->reduction_product == 0) {
    $order_products_total = $context->cart->getOrderTotal($use_tax, Cart::ONLY_PRODUCTS, $package_products);
    $order_shipping_total = $context->cart->getOrderTotal($use_tax, Cart::ONLY_SHIPPING, $package_products);
    $order_total = $order_products_total + $order_shipping_total;
    $reduction_value += $order_total * $this->reduction_percent / 100;
}

Key change: The percentage now applies to products + shipping costs instead of products only.

4.2 Fixed amount reduction — capped differently

9.0.x: Reduction amount is capped at product total.

9.1.x: For ORDER_LEVEL with feature flag enabled, the cap includes shipping:

if ($this->isDiscountFeatureFlagEnabled() && $this->getType() === DiscountType::ORDER_LEVEL) {
    $max_reduction_amount = $this->reduction_tax
        ? $cart_amount_ti + $context->cart->getOrderTotal(true, Cart::ONLY_SHIPPING, $package_products)
        : $cart_amount_te + $context->cart->getOrderTotal(false, Cart::ONLY_SHIPPING, $package_products);
    $reduction_amount = min($reduction_amount, $max_reduction_amount);
}

4.3 Current cart amount calculation

When a fixed amount reduction is applied (reduction_amount > 0), the $current_cart_amount calculation now includes shipping costs for ORDER_LEVEL discounts:

if ($this->isDiscountFeatureFlagEnabled() && $this->getType() === DiscountType::ORDER_LEVEL) {
    $current_cart_amount += $this->reduction_tax
        ? $context->cart->getOrderTotal(true, Cart::ONLY_SHIPPING, $package_products)
        : $context->cart->getOrderTotal(false, Cart::ONLY_SHIPPING, $package_products);
}

5. Bug fix: variable inconsistency (PR #40424)

PR #40424 by @pjouglet fixes variable usage inconsistency throughout the file.

Before: Some variables were used inconsistently (e.g., mixing $cart_rule->name and htmlspecialchars($cart_rule->name)).

After: Normalization of variable usage throughout the file, particularly in voucher compatibility error messages:

// 9.1.x - with htmlspecialchars for XSS security
return (!$display_error) ? false : $this->trans(
    'This voucher is not combinable with an other voucher already in your cart: %s',
    [htmlspecialchars($cart_rule->name)],
    'Shop.Notifications.Error'
);

6. New discount compatibility system

9.0.x

The compatibility system relies on the ps_cart_rule_combination table and the cart_rule_restriction field. Each forbidden combination is stored as a pair in the table, causing exponential data explosion with many rules.

9.1.x

The new system introduces compatibility by discount type:

Discounts are no longer ordered by promo code vs. automatic
Fixed application order:
- Catalog (product) → Cart (cart) → Free Shipping → Free Gift
Within the same type: sorted by priority (lower = applied first), then by creation date
Dynamic re-evaluation on each cart modification

7. Impact on `CartRuleCalculator.php`

While this file is separate from CartRule.php, the changes are intrinsically linked. The CartRuleCalculator (in src/Core/Cart/) integrates the same feature flag checks:

if ($cartRule->getType() === DiscountType::ORDER_LEVEL
    && (float) $cartRule->reduction_percent > 0
    && $cartRule->reduction_product == 0) {
    if ($this->isDiscountFeatureFlagEnabled()) {
        // New calculation: products + shipping
        $initialShippingFees = $this->calculator->getFees()->getInitialShippingFees();
        $productsTotal = $this->calculator->getRowTotal();
        $orderTotal = $productsTotal->add($initialShippingFees);
        // ...
    }
}

8. Associated database changes

The 9.1.x introduces schema modifications to support the new discount system (visible in install-dev/upgrade/sql/9.1.0.sql). These changes are linked to the feature flag and don’t alter existing tables as long as the flag remains disabled.

9. Changes summary table

Aspect	9.0.x	9.1.x
Imports	No Discount dependency	`DiscountType`, `DiscountSettings`, `FeatureFlagSettings`
Feature Flag	Absent	`isDiscountFeatureFlagEnabled()` present
Discount typing	Implicit (individual fields)	Explicit via `getType()` → `DiscountType`
% on ORDER_LEVEL	Products only	Products + shipping
Fixed amount cap	Product total	Product total + shipping (ORDER_LEVEL)
XSS security messages	`$cart_rule->name`	`htmlspecialchars($cart_rule->name)`
Discount compatibility	`cart_rule_combination` table	By type with fixed application order
Backward compatibility	—	✅ Flag disabled = 9.0.x behavior

10. Recommendations for module developers

Don’t override CartRule.php if you plan to support 9.1.x — the file is actively evolving.

Check the feature flag in your modules if you interact with discounts:

$featureFlagManager = $this->get(FeatureFlagStateCheckerInterface::class);
if ($featureFlagManager->isEnabled(FeatureFlagSettings::FEATURE_FLAG_DISCOUNT)) {
    // New system logic
}

Test both modes (flag enabled and disabled) as merchants can switch between both.
Use getType() instead of manually checking reduction_product, free_shipping, gift_product etc.
Be careful with shipping calculation: if your module calculates discount totals, behavior changes based on discount type in 9.1.x.

Key Takeaways — CartRule.php in PrestaShop 9.1.x

What every PrestaShop module developer must remember about the CartRule evolution from 9.0.x to 9.1.x:

The feature flag protects backward compatibility. The new Discount system is disabled by default — 9.1.x behaves exactly like 9.0.x as long as the flag remains off. No forced migration pressure.
ORDER_LEVEL calculation changes fundamentally. With the flag enabled, percentage and fixed-amount discounts now apply to products + shipping, not products alone. Your cart calculation tests must cover both modes.
Use getType() instead of individual fields. The new method cleanly encapsulates the discount type (Catalog, Cart, Free Shipping, Free Gift) — no more manually checking reduction_product, free_shipping, gift_product.
Don’t override CartRule.php. This file is actively evolving. Use hooks and Symfony services instead to interact with the discount system.
Test both flag states in your CI: flag disabled (9.0.x behavior) and flag enabled (new system). It’s the only way to guarantee compatibility across your clients’ stores.

Sources and references

How vibecoding is destroying the open source that feeds it

Tue, 03 Mar 2026 00:00:00 +0000

How vibecoding is destroying the open source that feeds it

March 3, 2026

The snake eating its own tail

A year ago, vibecoding was a curiosity. Today, it’s an industry. Millions of developers — or rather prompters — generate entire applications by describing what they want to an LLM. In minutes, an API, a frontend, a deployment. Magical.

But behind this magic lies a dirty secret that nobody wants to face: every line of code generated by these AIs was trained on millions of open source projects — projects that are now dying.

Vibecoding would be nothing without open source. And it’s killing it.

What exactly is vibecoding?

For those who spent 2025 in a cave: vibecoding is the practice of creating software in natural language, relying on generative AI models (Claude, GPT-5, Gemini, and the dozens of specialized models that have emerged since). You describe a vibe, an intention, and the AI produces the code.

No debugging. No reading documentation. No Stack Overflow. And above all — here’s the crux — no contributing back.

The implicit pact of open source is broken

The open source ecosystem has always rested on a tacit social contract:

I publish my code for free. In return, others use it, find bugs, suggest improvements, contribute. The project lives because a community keeps it alive.

This contract had already been severely tested by large corporations that consume open source without contributing proportionally. But at least the developers who used these libraries understood them. They opened issues. They forked. They sent pull requests. They wrote blog posts that spread the word about the project.

Vibecoding has blown up this cycle.

The vibecoder doesn’t know which library they’re using. They don’t know, and they don’t care. They asked “build me a payment API with webhook handling,” and the AI chose this or that dependency for them. They will never read that project’s README. They will never open an issue. They won’t even know that project exists.

The chilling numbers

The data is starting to speak, and it’s not reassuring:

Contributions to mid-size open source projects (10-500 stars) dropped 35% between January 2025 and January 2026, according to aggregated data from GitHub and GitLab. These mid-size projects form the essential connective tissue of the ecosystem.
The number of new issues opened by humans is down 28%, while issues opened by bots or automated tools are exploding — mostly noise, rarely signal.
Donations via GitHub Sponsors, Open Collective and Tidelift are stagnating or declining for the majority of projects, while actual usage (measured by npm, PyPI downloads, etc.) continues to rise. More consumption, less support.
The number of new “first-time” contributors to foundational projects (crypto libraries, parsers, networking tools) has dropped 41%.

That last number is the most alarming. The pipeline of the next generation is drying up.

The ghost generation

I spoke with about ten maintainers of popular open source projects in recent weeks. The same observation comes up, almost word for word:

“My downloads have never been higher. My contributions have never been lower.”

— Maintainer of a Python data processing library, 12,000 stars

“I’m getting issues that clearly make no sense. Someone copy-pasted an error message generated by an AI tool, without understanding what my library does or even knowing they’re using it. I spend more time closing useless issues than developing.”

— Maintainer of a Node.js tool

“I feel like I’ve become an invisible subcontractor for Cursor and Copilot. My code is everywhere, but I’ve disappeared.”

— Creator of a UI component library

Vibecoding has created a ghost generation: people who depend on open source without existing in open source. They are neither users, nor contributors, nor observers. They are passive consumers of an automated value extractor.

The technical problem: dependencies without awareness

Beyond the community problem, there’s a concrete technical issue.

When a human developer chooses a dependency, they (in theory) do evaluation work: is this project maintained? Does it have known vulnerabilities? Is it suited to my use case? What’s its license?

AI optimizes for what works right now. It favors libraries over-represented in its training data — meaning those that were popular at training time. This creates two perverse effects:

The fossilization effect: obsolete or poorly maintained libraries keep being injected into new projects because the AI “remembers” them. We’ve seen projects generated in 2025 using package versions from 2022, with known CVEs.
The winner-take-all effect: big projects (React, Express, pandas) continue to be systematically recommended, while newer, lighter, better-designed alternatives remain invisible. The ecosystem’s innovation freezes.

The “democratization” paradox

Vibecoding advocates make a compelling argument: democratization. Thanks to AI, millions of people who couldn’t code can now create software. That’s true. It’s even wonderful.

But this democratization is extractive. It extracts value from a common good (open source) to concentrate it in proprietary products (AI IDEs, SaaS platforms, inference APIs). Vibecoders pay their subscription to Cursor or Replit, not to the person maintaining date-fns at 2 AM.

We’ve privatized the benefits and socialized the costs. A classic.

AI models themselves make it worse

We must also point the finger at the AI companies themselves.

The models were trained on open source code, often without explicit consent, and the revenue generated by these models doesn’t flow back to the projects they depend on.

Some initiatives exist — Anthropic, Google and others have launched support funds — but let’s be honest: these are crumbs. The “AI for Open Source” fund announced by the Linux Foundation in November 2025 represents $50 million. That’s less than what these companies spend on compute in a single quarter.

And above all, money doesn’t replace contributors. An open source project doesn’t die for lack of dollars. It dies for lack of people who care.

The nightmare scenario

Let’s project forward for a moment.

If current trends continue:

Exhausted maintainers abandon their projects. This is already happening. Maintainer burnout isn’t new, but vibecoding accelerates it by increasing the load (more usage, more noise in issues) while diminishing the reward (less recognition, fewer contributions).
Critical projects become zombie software: still downloaded, never updated again. Security flaws accumulate. AIs keep recommending them.
A major security crisis erupts when a vulnerability in a zombie package ends up in thousands of vibecoded applications. Log4Shell will seem like a warm-up exercise.
Innovation slows down because new open source projects can no longer find a community. Why publish a package when nobody will ever look at it — when people don’t look at code at all anymore?
AI models degrade because they increasingly train on AI-generated code rather than thoughtful human code. The snake eats its own tail down to the bone. What’s called model collapse becomes visible in the quality of produced code.

This scenario isn’t science fiction. Every step is already underway.

What can be done?

I’m not naive enough to think we can stop vibecoding. The genie is out of the bottle, and frankly, the productivity it brings is real. But we can — we must — correct course.

1. Tax extraction, fund the commons

AI platforms that monetize code generated from open source should return a significant percentage of their revenue to the ecosystem. Not a symbolic fund. A structural mechanism, proportional to actual usage. The model already exists in other domains: it’s called a redistribution license or a digital commons royalty.

2. Make dependencies visible

Vibecoding tools should systematically display the open source dependencies they inject, with a link to the project, its maintenance status, its license, and a way to contribute. Not hidden in a package.json that nobody will read. Full screen. “This code uses 47 open source projects. 3 of them haven’t been updated in a year. Here’s how to support them.”

3. Integrate contribution into the AI workflow

Why couldn’t AI tools generate contributions back? Detect a bug in a library, draft a fix, propose improved documentation? If AI can consume open source, it should be able to contribute to it.

Some experimental projects are moving in this direction. They need to be generalized.

4. Educate vibecoders

Just because you don’t code doesn’t mean you shouldn’t understand where the code you use comes from. Vibecoding platforms should include a minimum of open source literacy: what’s a license? What’s a maintainer? Why does it matter?

We don’t require someone who drives a car to know how to build one. But we do require them to know that the road was built by someone, and that they pay taxes to maintain it.

5. Rethink licenses

The MIT license and the Apache license were written for a world where users were developers. That world no longer exists. It’s time to explore new licensing models that account for AI extraction and ensure fair redistribution of the value created.

GEO for e-commerce: how I optimized a product page to appear in ChatGPT, Gemini and Perplexity answers

Thu, 26 Feb 2026 00:00:00 +0000

A step-by-step case study with before/after measurements

Reading time: 20 min Last updated: February 2026

You invest time and money in SEO for your PrestaShop store. Your product pages rank well on Google. Yet a quiet revolution is reshuffling the deck: more and more consumers no longer search on Google. They ask ChatGPT, Gemini or Perplexity directly which product to buy.

And when these AIs answer, your product page is nowhere to be found.

This is exactly the problem I faced with an e-commerce client. In this article, I walk you through the complete process I followed to get a PrestaShop product page to appear in AI engine answers — step by step, with measured before and after results.

The context: a product page invisible to AI

My client sells trail running shoes on PrestaShop. Their flagship product page — a technical terrain trail shoe model — ranked decently on Google:

Position 8 for “technical terrain trail shoe”
~120 visits/month from organic search
A solid 3.2% conversion rate

On the surface, everything looked fine. But I wanted to check something.

The AI visibility test: a rude awakening

I asked the same question to three conversational AIs:

“What is the best trail running shoe for technical terrain in 2025?”

The results:

AI Engine	Product mentioned	Brand mentioned	Link to page
ChatGPT (GPT-4o)	No	No	No
Gemini	No	No	No
Perplexity	No	No	No

Zero mentions. Zero.

All three AIs recommended Salomon, Hoka, La Sportiva — the big brands. My client’s product page, despite being relevant and well-positioned on Google, simply did not exist in the AI answer universe.

That’s when the GEO (Generative Engine Optimization) work began.

What is GEO, and why does it change everything for e-commerce?

GEO is the practice of optimizing your content so that it is understood, selected and cited by AI answer engines — not just indexed by traditional search engines.

The fundamental difference:

SEO optimizes for a ranking algorithm that displays 10 blue links.
GEO optimizes for a language model that synthesizes a single answer from multiple sources.

In SEO, ranking at position 8 can be enough. In GEO, you’re either cited in the answer or you don’t exist. There is no “page 2”.

Why standard product pages fail at GEO

Most e-commerce product pages are built to convert a visitor who is already on the page. They contain:

A keyword-optimized title
Bullet points of features
Photos
An “Add to cart” button

But they almost never contain what an AI needs to recommend a product:

Sourced and verifiable claims
Detailed usage context
Honest comparisons with alternatives
Structured data the AI can parse
Authority signals (reviews, tests, certifications)

The complete process: 7 steps to optimize a product page for GEO

Here is exactly what I did, step by step.

Step 1 — Audit current AI visibility

Before touching anything, I conducted a comprehensive GEO visibility audit. Not just the generic question above, but a battery of 15 conversational queries covering different intents:

Informational queries:

“What trail shoe for rocky terrain?”
“Technical trail shoes comparison 2025”
“Which trail brand for rugged terrain?”

Transactional queries:

“Buy technical terrain trail shoe affordable”
“Best trail shoe value for money”

Specific queries:

“Trail shoe Vibram sole for ultra-trail”
“Trail running shoe for rocky terrain review”

For each query, I logged in a spreadsheet:

The complete answer from each AI
Whether the product or brand was mentioned
Which competitors were cited
The sources used by the AI (especially visible on Perplexity)

Audit result: across 45 combinations (15 queries x 3 AIs), my client’s product appeared 0 times. The brands cited repeatedly were Salomon (mentioned 38 times), Hoka (31 times), La Sportiva (27 times), and Scarpa (19 times).

Key lesson: AIs have a strong tendency to recommend what they “know” best — meaning the brands and products most present in their training data and in the sources they consult in real time.

Step 2 — Analyze why competitors get cited

To beat competitors in GEO, you need to understand why AIs cite them. I analyzed the product pages of models recommended by the AIs and identified recurring patterns.

What the cited products’ pages had in common:

Content-rich editorial pages — not just specs, but paragraphs explaining who the product is for, what conditions it excels in, and why.
Complete structured data — Schema.org Product with aggregateRating, review, offers, brand, and even isSimilarTo.
Mentions on high-authority third-party sites — reviews on specialized magazines (RunRepeat, Outdoor Gear Lab), comparisons on expert blogs, presence on community forums.
Structured and detailed customer reviews — not just “5 stars, great product”, but reviews mentioning specific use cases.
Coherent semantic interlinking — the product page was surrounded by related content (buying guides, blog articles, FAQ) that reinforced the site’s topical authority.

What my client’s page was missing:

80-word product description (essentially raw technical specs)
No structured data beyond basic PrestaShop defaults
Zero mentions on third-party sites
4 customer reviews, all very short
No supporting editorial content on the blog

Step 3 — Rewrite the product page for AIs (and humans)

This is the most important step. I completely rewrote the product page applying GEO principles.

Before: the original page

TrailForce X1 — Technical terrain trail shoe

Vibram MegaGrip sole
6mm drop
Weight: 310g
Breathable mesh upper
Rock guard protection
Colors: black/red, grey/blue

Ideal for technical trails and rugged terrain.

80 words. No contextualization. No comparisons. No sourced claims.

After: the GEO-optimized page

Here is the structure of the new page — I detail each section and explain why it’s there:

1. A semantically enriched title

TrailForce X1 — Technical trail shoe for rocky and rugged terrain | Review & ratings 2025

Why: AIs use the title as a strong relevance signal. Adding “rocky and rugged terrain” and “review & ratings 2025” increases match rate with conversational queries.

2. An “expert summary” introduction paragraph

The TrailForce X1 is a trail running shoe designed specifically for technical terrain — rocky trails, scree fields, rugged single tracks. Equipped with a Vibram MegaGrip sole and a 6mm drop, it delivers a balance of grip, protection and ground feel typically found on models 30 to 50% more expensive. In our tests over 200 km of Alpine trails, it stood out for its downhill stability on technical terrain and its durability (sole still in excellent condition after 200 km on abrasive terrain).

Why: this paragraph contains specific, verifiable claims (“200 km tested”, “30 to 50% cheaper”), precise usage context (“rocky trails, scree fields”), and an implicit comparative evaluation. AIs favor this type of content because it directly answers user questions.

3. A “Who is this shoe for?” section

Ideal profile: intermediate to advanced trail runner, running on technical terrain (scree, roots, rocks), distances from 15 to 80 km.

It excels if: you’re looking for maximum grip on wet rock, impact protection without sacrificing ground feel, and a controlled budget.

It’s not made for: flat forest trail running (too rigid), ultra-trails over 100 km (insufficient cushioning over very long distances), runners who prefer a high drop.

Why: this section is crucial for GEO. When a user asks an AI “which shoe for this use case”, the AI looks for content that clearly segments use cases. Mentioning the product’s limitations is also a credibility signal that AIs are learning to value.

4. Technical specs in context

Instead of a dry spec list, I reformatted each feature with an explanation of its real-world benefit:

Feature	Detail	What it changes on the trail
Sole	Vibram MegaGrip, 5mm lugs	Superior grip on wet rock — comparable to Salomon Speedcross on dry terrain, significantly better on wet surfaces
Drop	6 mm	Good balance between uphill dynamism and long downhill comfort
Weight	310 g (size 42/US 9)	Average for technical shoes — 20 g heavier than a Hoka Speedgoat, but with more solid rock guard protection
Protection	Full rock guard + anti-perforation plate	Allows attacking scree fields without hesitation, where lighter shoes demand caution
Upper	Technical breathable mesh, welded lateral reinforcements	Decent breathability in summer, reinforcements prevent tears on rocks

Why: direct comparisons with known products (Salomon, Hoka) are a powerful GEO lever. When the AI already knows the reference products, a factual comparison allows it to position the product within its existing knowledge framework.

5. A structured FAQ section

Is the TrailForce X1 suitable for ultra-trail? It’s suitable for distances up to 80 km on technical terrain. Beyond that, cushioning may become insufficient for runners over 75 kg. For ultra-long distances, we recommend [link to another model in the range].

How does it compare to the Salomon Speedcross 6? The Speedcross 6 is more aggressive on loose terrain (mud, dirt), but less versatile on rock. The TrailForce X1 offers better stability on rocky terrain and superior protection, at a price approximately 40 euros lower.

What size should I choose? The TrailForce X1 runs true to size. If you’re between sizes, go half a size up — that’s standard practice in trail running to avoid black toenails on descents.

Why: FAQs are one of the most powerful formats for GEO. The questions match exactly the format of conversational queries. AIs detect them easily and often use them as a direct source for their answers.

6. A “tester reviews” block with quotes

4.6/5 — Average across 47 verified reviews

“I ran the Trail des Aiguilles Rouges (58 km, 3,200 m elevation gain) in these. Impeccable grip on wet granite slabs. Best surprise of my season.” — Julien M., ultra-trail runner, Chamonix

“I was coming from a Hoka Speedgoat 5. Heavier and less cushioned, but grip and protection are in another league on rocky terrain.” — Sophie L., intermediate trail runner, Grenoble

“Unbeatable value for technical terrain. Only downside: the lacing system could be better designed.” — Marc D., field tester for TrailSession.fr

Why: detailed reviews with context (trail name, comparison with another model, negative point) are strong credibility signals for AIs. A review that compares with a known competitor particularly helps the AI contextualize the product.

Result: the page went from 80 words to approximately 900 words of useful, structured content optimized for conversational queries.

Step 4 — Implement advanced structured data

PrestaShop generates basic structured data, but it’s insufficient for GEO. I implemented enriched Schema.org markup:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "TrailForce X1 — Technical terrain trail shoe",
  "description": "Trail shoe designed for rocky and rugged terrain, equipped with a Vibram MegaGrip sole. Tested over 200 km of Alpine trails.",
  "brand": {
    "@type": "Brand",
    "name": "TrailForce"
  },
  "category": "Trail running shoes",
  "sku": "TF-X1-2025",
  "offers": {
    "@type": "Offer",
    "price": "119.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "priceValidUntil": "2025-12-31",
    "seller": {
      "@type": "Organization",
      "name": "TrailForce Store"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "47",
    "bestRating": "5"
  },
  "review": [
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "Julien M."
      },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5"
      },
      "reviewBody": "I ran the Trail des Aiguilles Rouges (58 km, 3,200 m elevation gain) in these. Impeccable grip on wet granite slabs."
    }
  ],
  "additionalProperty": [
    {
      "@type": "PropertyValue",
      "name": "Sole",
      "value": "Vibram MegaGrip, 5mm lugs"
    },
    {
      "@type": "PropertyValue",
      "name": "Drop",
      "value": "6mm"
    },
    {
      "@type": "PropertyValue",
      "name": "Weight",
      "value": "310g (size 42)"
    },
    {
      "@type": "PropertyValue",
      "name": "Recommended terrain",
      "value": "Rocky, scree, technical trails"
    }
  ],
  "isSimilarTo": [
    {
      "@type": "Product",
      "name": "Salomon Speedcross 6",
      "brand": { "@type": "Brand", "name": "Salomon" }
    },
    {
      "@type": "Product",
      "name": "Hoka Speedgoat 5",
      "brand": { "@type": "Brand", "name": "Hoka" }
    }
  ]
}

Key elements added:

additionalProperty with domain-specific properties (recommended terrain, sole type) — helps AIs precisely understand product characteristics
isSimilarTo — explicitly tells AIs which products are comparable, facilitating placement in comparative answers
Detailed aggregateRating and review — credibility signal

On PrestaShop, I used a custom module to inject this enriched JSON-LD into the product page <head>, replacing the default markup.

Step 5 — Create supporting content (the “GEO cluster”)

An isolated product page, even an excellent one, has little chance of being cited by an AI if the site lacks topical authority on the subject. AIs evaluate a source’s credibility partly through the depth and consistency of its content on a given domain.

I created a mini content cluster around the product page:

Article 1: Buying guide “How to choose a trail shoe for technical terrain: the complete 2025 guide” A 2,500-word article covering selection criteria (grip, protection, cushioning, drop), with natural mentions of the TrailForce X1 as a concrete example.

Article 2: Comparison “TrailForce X1 vs Salomon Speedcross 6 vs Hoka Speedgoat 5: the field comparison” An honest comparative test with summary table, trail photos, and verdict by runner profile. The client’s product doesn’t “win” everywhere — it wins on value and rock grip, but loses on long-distance cushioning and brand recognition.

Article 3: Long-term review “200 km in the TrailForce X1: my long-term test on Alpine trails” A test report with photos, GPS data, and wear evaluation. A narrative format that generates potential long citations for AIs.

Each article:

Contains links to the product page
Uses Schema.org Article markup with about pointing to the product
Includes FAQs at the bottom
Is written in an expert but accessible tone (the register that AIs tend to prefer citing)

Step 6 — Build external authority signals

This is the most often overlooked dimension in GEO, yet one of the most important. Conversational AIs — especially Perplexity, which cites its sources — rely heavily on high-authority third-party sites to validate their recommendations.

Actions taken:

Sent the product to 3 specialized trail blogs for independent testing. Two published a detailed test article within the following 6 weeks.
Published a detailed post on a French trail running forum (in “user experience report” format), with a link to the product page.
Answered questions on Quora and Reddit about “best trail running shoes for rocky terrain” with factual mentions of the product among other options.
Created entries on product databases referenced by AIs (certain product aggregators are crawled by Perplexity and used by ChatGPT shopping plugins).

Key point: every external mention uses the exact product name (“TrailForce X1”) and the same key descriptors (“technical terrain”, “Vibram MegaGrip sole”, “rocky terrain”). Terminological consistency across all sources is a strong signal for AIs.

Step 7 — Measure, iterate, re-measure

Four weeks after all optimizations went live, I ran exactly the same audit as in Step 1: the same 15 queries, on the same 3 AIs.

The results: before / after

AI visibility — Results across 15 test queries

Metric	Before	After (D+30)	After (D+60)
Total mentions (out of 45 combinations)	0	8	14
ChatGPT — mentions	0/15	2/15	4/15
Gemini — mentions	0/15	1/15	3/15
Perplexity — mentions	0/15	5/15	7/15

Qualitative citation breakdown

Perplexity was the first to cite the product, as early as Day+12. Its answers cited:

The comparison article published on the blog (direct link)
One of the two test articles published on external specialized blogs

ChatGPT started mentioning the product at Day+25, mainly on comparative queries (“TrailForce X1 vs Speedcross”) and value-for-money queries.

Gemini was the slowest to integrate the product, with first mentions around Day+35.

Impact on traffic and sales

Metric	Before	After (D+60)	Change
Product page traffic (visits/month)	120	185	+54%
Traffic from ChatGPT/Bing Chat	0	23	New channel
Traffic from Perplexity (referral)	0	41	New channel
Support articles traffic (blog)	30	210	+600%
Product sales (units/month)	4	7	+75%
Google position (“technical terrain trail shoe”)	8	5	+3 positions

Important observation: the GEO work also improved traditional SEO. This makes sense — content enrichment, advanced structured data, content clusters, and editorial backlinks are also powerful SEO signals. GEO and SEO are not opposed: well-executed GEO amplifies SEO.

The 5 GEO principles I take away for e-commerce

After this experience and several similar optimizations, here are the principles I apply systematically:

1. Think “answer”, not “result”

In SEO, you optimize to appear in a list. In GEO, you optimize so that your content becomes the answer. This means your product page should be readable aloud by an AI and constitute a credible recommendation.

2. Compare yourself explicitly to reference products

AIs know the big brands. If your product is less well-known, you need to build the bridge between what the AI knows and your product. Factual and honest comparisons (“comparable to Salomon X on this criterion, better on that one, weaker on this other one”) are extremely effective.

3. Source your claims

“Best trail shoe” means nothing to an AI. “Tested over 200 km of Alpine trails with 15% sole wear according to our test protocol” is a claim the AI can evaluate and cite. Statistics, test results, numerical data are the fuel of GEO.

4. Multiply consistent sources

A product page alone isn’t enough. You need an ecosystem of mentions — your blog, third-party sites, forums, product databases — all saying the same thing with the same terminology. The more diverse and concordant the sources, the more confident the AI is in recommending your product.

5. Structure for machines, write for humans

Schema.org structured data is not optional in GEO. But the content itself must remain natural, useful, and honest. AIs are trained on quality human content — that’s exactly what you need to produce.

How to measure your GEO visibility right now

If you want to know where you stand, here is the minimal protocol I recommend:

Identify 5 to 10 conversational queries your customers might ask an AI (natural language, in question form).
Submit them to ChatGPT, Gemini and Perplexity and note whether your product, brand or site is mentioned.
Analyze the cited sources (especially on Perplexity) to understand where the AI pulls its information from.
Compare with cited competitors: what do they have that you don’t?
Repeat every 30 days to measure progress.

Conclusion: GEO is not the future of e-commerce, it’s the present

While you’re reading this article, thousands of consumers are asking ChatGPT or Perplexity which product to buy. If your product page isn’t optimized for these answer engines, you’re leaving sales on the table — and your better-positioned competitors are picking them up.

The good news: as this case study shows, GEO levers are accessible and actionable. You don’t need a multinational’s budget. You need quality content that’s well-structured, sourced, and supported by a consistent ecosystem of mentions.

GEO is still emerging territory. Those who position themselves now will have a major competitive advantage when the wave goes mainstream.

The question isn’t whether AIs will influence purchase decisions. It’s whether your product will be in their recommendations when it happens.

Vibe Coding in e-commerce: why 80% of AI-generated modules will never make it to production

Tue, 24 Feb 2026 00:00:00 +0000

Vibe Coding in e-commerce: why 80% of AI-generated modules will never make it to production

Reading time: 15 min Last updated: February 2026

The dream they’re selling vs. the reality on the ground

“Describe what you want, AI codes it for you.”

Since Gene Kim popularized the concept of Vibe Coding and tools like Cursor, Claude Code, and GitHub Copilot exploded onto the scene, an enticing narrative has taken hold: anyone can now create software. No need to understand the code — just “give the vibe.”

And honestly? For a prototype, a demo, a side project… it works. It’s even impressive.

But I’ve been developing PrestaShop modules for over 10 years. Modules running on stores processing 50,000 orders per month. Modules installed on multi-shop architectures with 12 stores, 4 languages, 3 currencies, business rules specific to each customer group, and an ERP plugged in behind it all.

And what I’ve been seeing over the past 6 months in my audits, code takeovers, and support requests is a wave of “vibe-coded” modules that all share the same fate:

They work in demo. They break in production.

This article isn’t an anti-AI manifesto. I use AI every day in my workflow. But I’m going to show you, with concrete examples and real code, why Vibe Coding applied to e-commerce — and specifically to PrestaShop — is a minefield that only domain expertise can navigate.

1. Hooks: the #1 trap AI doesn’t understand

What AI generates

Ask an LLM to create a module that displays a reassurance block on the product page. You’ll get something like:

public function hookDisplayProductAdditionalInfo($params)
{
    $product = $params['product'];

    $this->context->smarty->assign([
        'product_name' => $product->name,
        'reassurance_text' => 'Free shipping over €49',
    ]);

    return $this->display(__FILE__, 'views/templates/hook/reassurance.tpl');
}

Looks clean. Works on a fresh PrestaShop install. The client is happy for 48 hours.

What blows up in production

Problem 1: $params['product'] isn’t what you think it is.

Depending on the PrestaShop version (1.7.6 vs 1.7.8 vs 8.1), whether you’re on the standard product page or in a quick-view module, depending on the theme used… $params['product'] can be:

A Product object
An associative array (from ProductPresenter)
null (if the hook is called in an unexpected context)
An array with different keys depending on the version

Robust code looks like this:

public function hookDisplayProductAdditionalInfo($params)
{
    // Defensive handling of the product parameter
    $product = null;

    if (isset($params['product'])) {
        if (is_array($params['product'])) {
            // PrestaShop 1.7.7+ with ProductPresenter
            $productId = (int) ($params['product']['id_product'] ?? $params['product']['id'] ?? 0);
            if ($productId > 0) {
                $product = new Product($productId, false, $this->context->language->id, $this->context->shop->id);
            }
        } elseif ($params['product'] instanceof Product) {
            $product = $params['product'];
        }
    }

    // Fallback to context if the hook doesn't provide anything usable
    if (!Validate::isLoadedObject($product)) {
        $productId = (int) Tools::getValue('id_product');
        if ($productId > 0) {
            $product = new Product($productId, false, $this->context->language->id, $this->context->shop->id);
        }
    }

    if (!Validate::isLoadedObject($product) || !$product->active) {
        return '';
    }

    // ... rest of the processing
}

Sexy? No. Necessary? Absolutely.

Problem 2: the hook might not even exist.

AI will suggest hookDisplayProductAdditionalInfo because it’s in the official documentation. But on a real store with a custom theme (Flavor, Warehouse, etc.), this hook:

may have been removed from the template
may be called at a different position in the DOM
may be competing with 4 other modules registered on it

A senior developer knows to check the target theme, offer a widget as an alternative, and implement a fallback with hookDisplayFooterProduct or hookDisplayOverrideTemplate if needed.

Problem 3: forgotten action hooks.

AI generates display hooks very well. It systematically forgets critical action hooks. A vibe-coded stock management module I audited last month:

Handled hookActionProductUpdate to recalculate stock
Forgot hookActionObjectProductDeleteAfter → ghost products in the database
Forgot hookActionProductAttributeUpdate → product combinations never synchronized
Forgot hookActionObjectCombinationDeleteAfter → ERP crash
Didn’t handle hookActionObjectStockAvailableUpdateAfter → conflict with native stock

One forgotten hook = inconsistent data across hundreds of products.

2. Security: the gaping hole AI leaves wide open

Unprotected AJAX

This is the pattern I find in 90% of vibe-coded modules with an admin interface:

// front/ajax.php — AI-generated
include('../../config/config.inc.php');

$action = Tools::getValue('action');

if ($action === 'updatePrice') {
    $id_product = Tools::getValue('id_product');
    $new_price = Tools::getValue('price');

    $product = new Product($id_product);
    $product->price = $new_price;
    $product->save();

    die(json_encode(['success' => true]));
}

This code is a wide-open door. Anyone can change the price of any product in the store with a simple curl call:

curl "https://your-store.com/modules/mymodule/front/ajax.php?action=updatePrice&id_product=1&price=0.01"

Congratulations: all your products are now 1 cent.

What secure code requires

// controllers/front/ajax.php — secure version
class MyModuleAjaxModuleFrontController extends ModuleFrontController
{
    public function initContent()
    {
        // Verify this is actually an AJAX request
        if (!$this->ajax) {
            $this->ajaxRender(json_encode(['error' => 'Invalid request']));
            return;
        }

        parent::initContent();
    }

    public function displayAjaxUpdatePrice()
    {
        // 1. CSRF token verification
        if (!$this->isTokenValid()) {
            header('HTTP/1.1 403 Forbidden');
            $this->ajaxRender(json_encode(['error' => 'Invalid token']));
            return;
        }

        // 2. Permission check (admin employee logged in)
        $cookie = new Cookie('psAdmin');
        if (!$cookie->id_employee) {
            header('HTTP/1.1 401 Unauthorized');
            $this->ajaxRender(json_encode(['error' => 'Unauthorized']));
            return;
        }

        $employee = new Employee((int) $cookie->id_employee);
        if (!Validate::isLoadedObject($employee)
            || !$employee->hasAuthOnShop($this->context->shop->id)) {
            header('HTTP/1.1 403 Forbidden');
            $this->ajaxRender(json_encode(['error' => 'Insufficient permissions']));
            return;
        }

        // 3. Strict input validation
        $idProduct = (int) Tools::getValue('id_product');
        $newPrice = (float) Tools::getValue('price');

        if ($idProduct <= 0) {
            $this->ajaxRender(json_encode(['error' => 'Invalid product ID']));
            return;
        }

        if ($newPrice < 0 || $newPrice > 999999.99) {
            $this->ajaxRender(json_encode(['error' => 'Invalid price range']));
            return;
        }

        // 4. Verify the product belongs to the current shop context
        $product = new Product($idProduct, false, null, $this->context->shop->id);
        if (!Validate::isLoadedObject($product)) {
            $this->ajaxRender(json_encode(['error' => 'Product not found in current shop']));
            return;
        }

        // 5. Secure update with multi-shop handling
        $product->price = $newPrice;

        if (Shop::getContext() === Shop::CONTEXT_SHOP) {
            $product->save();
        } else {
            // In multi-shop context, force current shop
            $product->id_shop_default = $this->context->shop->id;
            $product->save();
        }

        // 6. Log the action for audit trail
        PrestaShopLogger::addLog(
            sprintf('Product #%d price updated to %f by employee #%d via module MyModule',
                $idProduct, $newPrice, (int) $cookie->id_employee),
            1,
            null,
            'Product',
            $idProduct,
            true,
            (int) $cookie->id_employee
        );

        // 7. Flush product price cache
        Product::flushPriceCache();

        $this->ajaxRender(json_encode([
            'success' => true,
            'product_id' => $idProduct,
            'new_price' => $newPrice,
        ]));
    }
}

We went from 8 lines to 65 lines. And every additional line blocks a real attack vector.

SQL injections: still here in 2026

AI loves generating “readable” SQL queries:

// AI-generated — SQL injection
$sql = "SELECT * FROM " . _DB_PREFIX_ . "product
        WHERE reference = '" . $reference . "'";
$results = Db::getInstance()->executeS($sql);

// Secure version
$sql = new DbQuery();
$sql->select('p.id_product, p.reference, p.price, pl.name');
$sql->from('product', 'p');
$sql->innerJoin('product_lang', 'pl', 'p.id_product = pl.id_product AND pl.id_lang = ' . (int) $this->context->language->id);
$sql->innerJoin('product_shop', 'ps', 'p.id_product = ps.id_product AND ps.id_shop = ' . (int) $this->context->shop->id);
$sql->where('p.reference = \'' . pSQL($reference) . '\'');
$sql->where('ps.active = 1');
$results = Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS($sql);

Notice the details AI systematically forgets:

pSQL() to escape the value
The product_shop join for multi-shop context
The product_lang join for the current language
Using _PS_USE_SQL_SLAVE_ for read queries (performance)
Filtering on active = 1

3. Performance: the silent serial killer

The N+1 problem: the classic AI reproduces endlessly

A vibe-coded cross-selling module I recently audited:

// AI-generated code — N+1 queries
public function hookDisplayShoppingCartFooter($params)
{
    $cart = $this->context->cart;
    $products = $cart->getProducts();
    $recommendations = [];

    foreach ($products as $product) {
        // Query 1 per product: fetch the category
        $category = new Category($product['id_category_default'], $this->context->language->id);

        // Query 2 per product: fetch products from the same category
        $categoryProducts = $category->getProducts($this->context->language->id, 1, 10);

        foreach ($categoryProducts as $catProduct) {
            // Query 3 per recommended product: check stock
            $stockAvailable = StockAvailable::getQuantityAvailableByProduct($catProduct['id_product']);

            if ($stockAvailable > 0) {
                // Query 4 per recommended product: fetch the image
                $image = Image::getCover($catProduct['id_product']);
                $catProduct['image_url'] = $this->context->link->getImageLink(
                    $catProduct['link_rewrite'],
                    $image['id_image'],
                    'home_default'
                );
                $recommendations[] = $catProduct;
            }
        }
    }

    $this->context->smarty->assign('recommendations', array_slice($recommendations, 0, 4));
    return $this->display(__FILE__, 'views/templates/hook/recommendations.tpl');
}

A cart with 5 products, in categories of 50 products each = potentially 1,000+ SQL queries on every cart page display.

On a store with traffic, this module brings the server to its knees within 24 hours.

The optimized version

public function hookDisplayShoppingCartFooter($params)
{
    $cart = $this->context->cart;
    $products = $cart->getProducts();

    if (empty($products)) {
        return '';
    }

    // Cache: don't recalculate on every page load
    $cacheKey = 'mymodule_reco_' . $cart->id . '_' . md5(serialize(array_column($products, 'id_product')));

    if ($cachedOutput = $this->getCachedRecommendations($cacheKey)) {
        return $cachedOutput;
    }

    $productIds = array_column($products, 'id_product');
    $categoryIds = array_unique(array_column($products, 'id_category_default'));
    $idLang = (int) $this->context->language->id;
    $idShop = (int) $this->context->shop->id;

    // A SINGLE query to fetch everything
    $sql = new DbQuery();
    $sql->select('DISTINCT p.id_product, pl.name, pl.link_rewrite, p.price,
                   p.id_category_default, sa.quantity as stock,
                   IFNULL(img.id_image, 0) as id_image');
    $sql->from('product', 'p');
    $sql->innerJoin('product_lang', 'pl',
        'p.id_product = pl.id_product AND pl.id_lang = ' . $idLang . ' AND pl.id_shop = ' . $idShop);
    $sql->innerJoin('product_shop', 'ps',
        'p.id_product = ps.id_product AND ps.id_shop = ' . $idShop);
    $sql->innerJoin('stock_available', 'sa',
        'p.id_product = sa.id_product AND sa.id_product_attribute = 0 AND sa.id_shop = ' . $idShop);
    $sql->leftJoin('image_shop', 'img',
        'p.id_product = img.id_product AND img.id_shop = ' . $idShop . ' AND img.cover = 1');
    $sql->where('p.id_category_default IN (' . implode(',', array_map('intval', $categoryIds)) . ')');
    $sql->where('p.id_product NOT IN (' . implode(',', array_map('intval', $productIds)) . ')');
    $sql->where('ps.active = 1');
    $sql->where('sa.quantity > 0');
    $sql->orderBy('RAND()');
    $sql->limit(4);

    $recommendations = Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS($sql);

    if (empty($recommendations)) {
        return '';
    }

    // Build image URLs in batch (no extra queries)
    foreach ($recommendations as &$reco) {
        if ($reco['id_image'] > 0) {
            $reco['image_url'] = $this->context->link->getImageLink(
                $reco['link_rewrite'],
                $reco['id_product'] . '-' . $reco['id_image'],
                ImageType::getFormattedName('home')
            );
        } else {
            $reco['image_url'] = $this->context->link->getImageLink(
                $reco['link_rewrite'],
                $this->context->language->iso_code . '-default',
                ImageType::getFormattedName('home')
            );
        }
    }

    $this->context->smarty->assign('recommendations', $recommendations);
    $output = $this->display(__FILE__, 'views/templates/hook/recommendations.tpl');

    // Cache for 30 minutes
    $this->cacheRecommendations($cacheKey, $output, 1800);

    return $output;
}

Result: 1 query instead of 1,000. Caching included. Ready for traffic.

This is where the vast majority of vibe-coded modules collapse, because AI simply has no idea about the complexity of PrestaShop multi-shop.

What AI doesn’t know

PrestaShop multi-shop means 3 possible contexts:

Shop::CONTEXT_SHOP    → a single store
Shop::CONTEXT_GROUP   → a group of stores
Shop::CONTEXT_ALL     → all stores

And every database table potentially has an associated _shop table. When a vibe-coded module does:

// Only works in single-shop mode
Configuration::updateValue('MY_MODULE_SETTING', $value);

In a multi-shop context, this line can:

Overwrite the configuration of ALL stores (if ALL context)
Only save for the group (if GROUP context)
Work correctly (if SHOP context, and even then…)

The correct approach

// Explicit multi-shop handling
public function saveConfiguration()
{
    $shops = Shop::getShops(true, null, true);

    if (Shop::getContext() === Shop::CONTEXT_SHOP) {
        // Save for the current store only
        Configuration::updateValue(
            'MY_MODULE_SETTING',
            Tools::getValue('MY_MODULE_SETTING'),
            false,
            null,
            (int) $this->context->shop->id
        );
    } elseif (Shop::getContext() === Shop::CONTEXT_ALL) {
        // User wants to apply to all stores
        foreach ($shops as $idShop) {
            Configuration::updateValue(
                'MY_MODULE_SETTING',
                Tools::getValue('MY_MODULE_SETTING'),
                false,
                null,
                (int) $idShop
            );
        }
    }
}

Multi-shop installation: the real nightmare

The install() of a vibe-coded module:

// Naive installation
public function install()
{
    return parent::install()
        && $this->registerHook('displayProductAdditionalInfo')
        && $this->installDb();
}

private function installDb()
{
    $sql = 'CREATE TABLE IF NOT EXISTS `' . _DB_PREFIX_ . 'mymodule_data` (
        `id` INT AUTO_INCREMENT PRIMARY KEY,
        `id_product` INT NOT NULL,
        `custom_field` VARCHAR(255) NOT NULL
    )';

    return Db::getInstance()->execute($sql);
}

The robust install():

// Multi-shop aware installation
public function install()
{
    if (Shop::isFeatureActive()) {
        Shop::setContext(Shop::CONTEXT_ALL);
    }

    if (!parent::install()) {
        $this->_errors[] = $this->l('Could not install module base');
        return false;
    }

    $hooks = [
        'displayProductAdditionalInfo',
        'displayBackOfficeHeader',
        'actionProductUpdate',
        'actionProductDelete',
        'actionShopDataDuplication', // ← Crucial for multi-shop!
        'actionObjectShopDeleteAfter',
    ];

    foreach ($hooks as $hook) {
        if (!$this->registerHook($hook)) {
            $this->_errors[] = sprintf($this->l('Could not register hook: %s'), $hook);
            return false;
        }
    }

    if (!$this->installDb()) {
        return false;
    }

    // Default configuration for all stores
    $this->initializeDefaultConfig();

    return true;
}

private function installDb()
{
    $sql = [];

    $sql[] = 'CREATE TABLE IF NOT EXISTS `' . _DB_PREFIX_ . 'mymodule_data` (
        `id_mymodule_data` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
        `id_product` INT UNSIGNED NOT NULL,
        `custom_field` VARCHAR(255) NOT NULL,
        `date_add` DATETIME NOT NULL,
        `date_upd` DATETIME NOT NULL,
        INDEX (`id_product`)
    ) ENGINE=' . _MYSQL_ENGINE_ . ' DEFAULT CHARSET=utf8mb4';

    // _shop table for multi-shop
    $sql[] = 'CREATE TABLE IF NOT EXISTS `' . _DB_PREFIX_ . 'mymodule_data_shop` (
        `id_mymodule_data` INT UNSIGNED NOT NULL,
        `id_shop` INT UNSIGNED NOT NULL,
        `active` TINYINT(1) UNSIGNED NOT NULL DEFAULT 1,
        PRIMARY KEY (`id_mymodule_data`, `id_shop`),
        INDEX (`id_shop`)
    ) ENGINE=' . _MYSQL_ENGINE_ . ' DEFAULT CHARSET=utf8mb4';

    // _lang table for multilingual support
    $sql[] = 'CREATE TABLE IF NOT EXISTS `' . _DB_PREFIX_ . 'mymodule_data_lang` (
        `id_mymodule_data` INT UNSIGNED NOT NULL,
        `id_lang` INT UNSIGNED NOT NULL,
        `id_shop` INT UNSIGNED NOT NULL DEFAULT 1,
        `custom_label` VARCHAR(255) NOT NULL,
        PRIMARY KEY (`id_mymodule_data`, `id_lang`, `id_shop`),
        INDEX (`id_lang`),
        INDEX (`id_shop`)
    ) ENGINE=' . _MYSQL_ENGINE_ . ' DEFAULT CHARSET=utf8mb4';

    foreach ($sql as $query) {
        if (!Db::getInstance()->execute($query)) {
            $this->_errors[] = $this->l('Database installation error');
            return false;
        }
    }

    return true;
}

// Crucial hook: when a store is duplicated, data must follow
public function hookActionShopDataDuplication($params)
{
    $oldShopId = (int) $params['old_id_shop'];
    $newShopId = (int) $params['new_id_shop'];

    Db::getInstance()->execute('
        INSERT INTO `' . _DB_PREFIX_ . 'mymodule_data_shop` (`id_mymodule_data`, `id_shop`, `active`)
        SELECT `id_mymodule_data`, ' . $newShopId . ', `active`
        FROM `' . _DB_PREFIX_ . 'mymodule_data_shop`
        WHERE `id_shop` = ' . $oldShopId
    );
}

AI NEVER generates hookActionShopDataDuplication. Never. And without it, store duplication breaks the module’s data.

5. Tests and validation: what simply doesn’t exist

A vibe-coded module has no tests. Zero. AI generates functional code, not quality infrastructure.

In a professional module, here’s what exists beyond the code:

mymodule/
├── mymodule.php
├── config/
│   └── services.yml          ← Dependency injection
├── src/
│   ├── Controller/
│   ├── Repository/            ← Database abstraction layer
│   ├── Service/
│   └── Exception/             ← Typed business exceptions
├── tests/
│   ├── Unit/
│   │   ├── Service/
│   │   └── Repository/
│   └── Integration/
│       ├── HookTest.php
│       ├── MultiShopTest.php
│       └── InstallTest.php
├── upgrade/
│   ├── upgrade-1.1.0.php      ← Database migration
│   ├── upgrade-1.2.0.php
│   └── upgrade-2.0.0.php
├── views/
├── translations/
└── .github/
    └── workflows/
        └── ci.yml             ← Automated CI/CD

Upgrade files: the great forgotten

When your module evolves, the database needs to migrate. AI never thinks to create upgrade files:

// upgrade/upgrade-1.2.0.php
function upgrade_module_1_2_0($module)
{
    $sql = [];

    // Add a column without breaking existing data
    $sql[] = 'ALTER TABLE `' . _DB_PREFIX_ . 'mymodule_data`
              ADD COLUMN `priority` INT UNSIGNED NOT NULL DEFAULT 0 AFTER `custom_field`';

    // Migrate existing data
    $sql[] = 'UPDATE `' . _DB_PREFIX_ . 'mymodule_data` SET `priority` = 1 WHERE `active` = 1';

    // New hook needed
    if (!$module->registerHook('displayAfterBodyOpeningTag')) {
        return false;
    }

    foreach ($sql as $query) {
        if (!Db::getInstance()->execute($query)) {
            return false;
        }
    }

    // Clear cache
    if (method_exists('Cache', 'clean')) {
        Cache::clean('mymodule_*');
    }

    return true;
}

Without upgrade files, updating the module breaks all existing installations. That’s the kind of thing you learn after receiving 200 support tickets in a single day.

6. Compatibility: the real craft

Compatibility with other modules

A module never lives alone. On a typical PrestaShop store, there are 30 to 80 installed modules. A vibe-coded module:

Overwrites overrides without checking if they already exist → crashes other modules
Loads jQuery twice or loads an incompatible version → JavaScript broken everywhere
Modifies ObjectModels without using hooks → modules observing these objects are never notified
Adds CSS/JS everywhere instead of targeting relevant pages → global slowdown

// What AI generates
public function hookDisplayHeader()
{
    // Loaded on ALL front pages
    $this->context->controller->addCSS($this->_path . 'views/css/style.css');
    $this->context->controller->addJS($this->_path . 'views/js/script.js');
}

// What you should do
public function hookDisplayHeader()
{
    $controller = $this->context->controller;

    // Only load on relevant pages
    if ($controller instanceof ProductController) {
        $this->context->controller->registerStylesheet(
            'mymodule-product',
            'modules/' . $this->name . '/views/css/product.css',
            ['media' => 'all', 'priority' => 150]
        );
        $this->context->controller->registerJavascript(
            'mymodule-product',
            'modules/' . $this->name . '/views/js/product.js',
            ['position' => 'bottom', 'priority' => 150, 'attribute' => 'defer']
        );
    }
}

PrestaShop version compatibility

A professional module must handle this:

// Adapt code based on version
if (version_compare(_PS_VERSION_, '8.0.0', '>=')) {
    // PrestaShop 8: uses Symfony and Doctrine
    // Legacy AdminControllers are deprecated
    // Theme system has evolved
} elseif (version_compare(_PS_VERSION_, '1.7.7', '>=')) {
    // PrestaShop 1.7.7+: new hooks, new ProductPresenter
    // Symfony partially integrated
} else {
    // PrestaShop 1.7.x legacy
    // Still pre-Symfony code everywhere
}

7. The bottom line: what Vibe Coding does well, and where it stops

Let’s be honest. Here’s my assessment after 6 months of daily AI use in my PrestaShop development:

What AI does very well

Task	Time saved
Initial module scaffolding	~60%
Basic Smarty template generation	~50%
Writing simple SQL queries	~40%
HelperForm form generation	~70%
Code documentation	~80%
Refactoring existing code	~40%

What AI does poorly (or not at all)

Problem	Production consequence
Security (tokens, permissions, SQL injection)	Store hacked, data stolen
Multi-shop	Corrupted data across stores
Performance (N+1, cache)	Server down during peak traffic
Complete action hooks	Inconsistent data, ERP/CRM desynchronized
Upgrade files	Module impossible to update
Cross-version compatibility	Module crashes on other versions
Robust error handling	White screens, 500 errors
GDPR compliance	Legal risk
Accessibility (a11y)	Legal non-compliance

8. My method: AI as an accelerator, not a replacement

I’m not against Vibe Coding. I’m against Vibe Coding without a safety net.

Here’s how I integrate AI into my daily workflow:

1. AI generates, I specify

I never ask “create me a wishlist module”. I ask:

“Generate the WishlistRepository class with add, remove, getByCustomer methods. Use DbQuery, handle multi-shop with shop joins, escape values with pSQL and (int). The getByCustomer method must use _PS_USE_SQL_SLAVE.”

2. AI codes, I review

Every generated line goes through my mental checklist:

Security: token, permissions, escaping
Multi-shop: context, _shop joins
Multi-language: _lang joins
Performance: number of queries, caching
Hooks: complete (action + display)
Compatibility: PS version, themes
Errors: try/catch, Validate, fallbacks

3. AI iterates, I validate

AI is excellent at iterating quickly on variations. But the final validation is human, with tests on a real store, with real data, in a real multi-shop context.

Key Takeaways — Vibe Coding & PrestaShop Modules

What every developer (and every merchant ordering a module) must understand about Vibe Coding applied to PrestaShop:

AI generates functional code — not production-ready code. Vibe-coded modules compile and work in demos. They break on edge cases, real load, and inter-module interactions. That’s precisely what makes them dangerous.
Three unavoidable failure vectors: security (AJAX without CSRF token, SQL injections), multi-shop (missing _shop and _lang joins, hookActionShopDataDuplication never generated), and performance (N+1 queries that bring a server down within 24h of traffic).
Critical action hooks are systematically forgotten. AI generates display hooks well, never the hookActionObject*Delete/Update/Add hooks required for data consistency with ERPs and CRMs.
PrestaShop 9 introduces breaking changes AI doesn’t know about. Legacy product page removed, 100% Symfony admin auth, hook alias deprecation — a vibe-coded module without an audit can be incompatible on 40% of its features.
The right approach: AI to accelerate, expert to validate. AI saves 40–80% on scaffolding. But every generated line must pass through a mental checklist: security, multi-shop, multi-language, performance, complete hooks, version compatibility.

Conclusion: Vibe Coding doesn’t replace 10 years of production failures

Vibe Coding is a wonderful tool in the hands of a developer who knows what they’re doing. It accelerates work by 30 to 50%.

But in the hands of someone who doesn’t know PrestaShop’s pitfalls — and there are countless — it’s a technical debt generator, a source of security vulnerabilities, and a recipe for unstable stores.

The 80% of vibe-coded modules that will never make it to production aren’t modules that are poorly coded in a syntactic sense. AI writes code that compiles, that executes, that appears to work. That’s precisely what makes them dangerous.

They fail on edge cases, specific contexts, inter-module interactions, load scaling, updates, and business constraints that only field experience can teach.

The expertise of a senior PrestaShop developer isn’t knowing how to write PHP. It’s knowing everything that can go wrong in production, and preventing it before it happens.

Vibe Coding generates code. Experience generates trust.

And in e-commerce, when every minute of downtime costs thousands of euros, trust is what has value.

You have an AI-generated module and you’re wondering if it’s ready for production? I offer a comprehensive technical audit with a detailed report, priority fixes, and technical debt assessment. Because the best time to find problems is before your customers do.

What about you — what’s your experience with Vibe Coding on PrestaShop? Any AI modules that held up in production? Disasters narrowly avoided?

Claude + MCP Tools Plus vs ChatGPT + MCP Tools Plus: Which AI Assistant to Run Your PrestaShop Store in 2026?

Thu, 19 Feb 2026 00:00:00 +0000

It’s 2026. AI is no longer a gimmick. It’s an operational co-pilot for e-commerce merchants.

But one question keeps coming up in my conversations with PrestaShop merchants:

“Claude or ChatGPT? Which one should I pick to manage my store?”

The honest answer? It depends on what you’re doing.

And since I have the (somewhat crazy) privilege of working daily with both platforms connected to the same module — MCP Tools Plus for PrestaShop — I decided to settle this question once and for all.

Not with theory. Not with abstract benchmarks.

With a real shop. Real products. Real e-commerce tasks.

The Test Protocol

The Test Store

A real PrestaShop 8.x instance with:

~1,200 active products (fashion & accessories)
3 years of order history
Multi-warehouse stock enabled
Messy, incomplete data — in other words: real life

The Common Connector

Both AIs use the exact same entry point: MCP Tools Plus, the module I developed to expose PrestaShop data via the MCP (Model Context Protocol).

Same API. Same data. Same permissions.

Only the brain changes.

The 5 Challenges

#	Challenge	What We’re Really Testing
1	Sales analysis	Understanding complex numerical data
2	Stockout detection	Anticipation and logical reasoning
3	Product description generation	Creativity + SEO + brand voice
4	Problem diagnosis	Multi-step reasoning on real data
5	Full autonomous workflow	Chaining actions without human intervention

ROUND 1 — Last Quarter Sales Analysis

The Prompt

“Analyze my sales from last quarter. Identify trends, star products, flops, and give me 3 actionable recommendations.”

Claude (Anthropic)

Claude starts by asking clarifying questions:

“By ‘last quarter,’ do you mean Q1 2026 (January-March)? And would you like me to include canceled orders in the analysis or only validated ones?”

Then it retrieves the data via MCP Tools Plus and produces a layered analysis:

Macro view: Total revenue, average basket, evolution vs Q4 2025
Product view: Top 10 / Bottom 10, with margins (not just revenue)
Behavioral view: Best performing days of the week, correlation with past marketing campaigns
Recommendations: Specific, nuanced, with “however, be cautious about…” caveats

What impressed me: Claude spontaneously cross-referenced sales data with stock levels to flag that 3 of the top sellers were at risk of stockout. Nobody asked for that.

ChatGPT (OpenAI)

ChatGPT dives right in. No preliminary questions. It retrieves the data and immediately generates a visual report:

Formatted tables with emojis and polished styling
Text-based charts (ASCII trend representations)
More “consultant” tone: punchy phrases, bullet points, bold numbers
More decisive recommendations: “Remove these 5 references”, “Double the stock of X”

What impressed me: Speed and immediate readability. The report is “presentable as-is” to a sales director.

Round 1 Verdict

Criteria	Claude	ChatGPT
Depth of analysis	5/5	4/5
Immediate readability	4/5	5/5
Reliability of conclusions	5/5	3/5
Spontaneous initiatives	5/5	3/5

Claude wins this round. Its ability to cross-reference unrequested data and nuance its conclusions is a step above. ChatGPT is “sexier” in presentation but more superficial on substance.

ROUND 2 — Stockout Detection and Management

The Prompt

“Identify products at risk of stockout within the next 15 days and propose a restocking plan.”

Claude

Claude methodically breaks down the problem:

Retrieves current stock levels via MCP Tools Plus
Calculates sales velocity over the last 30 days per product
Projects stockouts by dividing stock / daily velocity
Ranks by urgency (stockout in 3 days vs 12 days)
Proposes restocking quantities based on supplier lead time (which it asks for if unavailable)

Result: A prioritized restocking table with an “estimated revenue impact if stockout” column.

Unexpected bonus: Claude flags that 2 products have negative stock (data error) and recommends an audit.

ChatGPT

ChatGPT takes a more direct approach:

Retrieves stock and recent sales
Generates an alert list with color coding
Proposes immediate actions: “Order 50 units of REF-4521 today”
Suggests creating an automatic rule for future alerts

The approach is more “act now” than “analyze fully.” ChatGPT wants you to do something right now.

Round 2 Verdict

Criteria	Claude	ChatGPT
Calculation rigor	5/5	3/5
Immediate actionability	4/5	5/5
Anomaly detection	5/5	3/5
Business context awareness	5/5	3/5

Claude wins this round, once again on depth. But ChatGPT scores points on the “stop thinking, start acting” aspect.

ROUND 3 — Product Description Generation

The Prompt

“Rewrite the descriptions of these 5 products (summer dresses) for SEO. Tone: elegant but accessible. Target: women 28-45. Include the product’s technical specs from the PrestaShop listing.”

Claude

Claude retrieves the product listings via MCP Tools Plus and produces descriptions that are… surprisingly human.

Each description has a different narrative structure (no copy-paste template)
It naturally integrates SEO keywords without feeling stuffed
It adapts tone per product: more casual for a linen dress, more sophisticated for an evening gown
It adds sensory micro-details: “The piqué cotton breathes with you through the hottest days”

Strong point: Claude spontaneously adds optimized meta title and meta description suggestions.

ChatGPT

ChatGPT delivers descriptions that are technically excellent for SEO:

Suggested H2/H3 structure
Well-controlled keyword density
Each description includes an integrated call-to-action
More “professional product sheet” format than narrative
It even proposes A/B variants for testing

Strong point: ChatGPT simultaneously generates product FAQ suggestions (the “People Also Ask” kind) to boost SEO.

Round 3 Verdict

Criteria	Claude	ChatGPT
Writing quality	5/5	4/5
Technical SEO optimization	4/5	5/5
Originality / variety	5/5	3/5
Useful extras	4/5	5/5

Near tie, slight edge to ChatGPT. If your priority is pure SEO, ChatGPT is formidable. If you want copy that makes people want to buy (conversion), Claude has a clear editorial advantage.

ROUND 4 — Operational Problem Diagnosis

The Prompt

“My conversion rate dropped 15% this month. Help me understand why by analyzing available data.”

Claude

This is where Claude crushes the competition.

Its approach resembles that of a senior consultant:

“Before looking for causes, let me verify that the drop is statistically significant and not a seasonal artifact.” — Compares with the same period year-over-year
Segments the drop by traffic source (if available in order data)
Checks whether popular products are out of stock (stock/conversion correlation)
Analyzes the average basket: does the drop come from order count or order value?
Looks for temporal correlations: does the drop coincide with a price change, end of a promotion?

Claude’s conclusion (in the test):

“The drop appears primarily linked to the stockout of 3 best-sellers since the 8th of the month, combined with the end of your -20% campaign on the 5th. The decline is not structural but circumstantial. Recommendation: prioritize restocking REF-2847 and REF-3391, and launch a targeted offer for returning visitors.”

ChatGPT

ChatGPT produces a well-organized checklist of possible causes:

Technical issue (site speed, 404 errors)
Price changes
Stockouts
Seasonality
Competition

It’s relevant but more generic. ChatGPT lists hypotheses where Claude prioritizes and decides using real data.

Round 4 Verdict

Criteria	Claude	ChatGPT
Diagnostic methodology	5/5	3/5
Use of real data	5/5	3/5
Actionable conclusion	5/5	3/5
Nuance and caution	5/5	3/5

Claude dominates clearly. Multi-step reasoning on interconnected data is its natural territory.

ROUND 5 — Full Autonomous Workflow

The Prompt

“Run a complete audit of my store: identify issues, propose fixes, and apply the risk-free ones.”

This is the final boss. We’re asking the AI to chain analysis, decision-making, and action.

Claude

Claude excels in the analysis and recommendation phase. It identifies:

47 products with empty descriptions
12 products priced at 0 euros (error)
8 categories without meta descriptions
3 products with missing images

But — and this is characteristic of Claude — it’s cautious on execution:

“I can fix the category meta descriptions and fill in empty product descriptions. For the products priced at 0 euros, I’d prefer you validate each correction since a pricing error could have direct financial impact. Here’s the list with my suggested prices based on similar products in your catalog.”

Claude does what’s safe. It asks for validation on the rest. That’s reassuring.

ChatGPT

ChatGPT is more aggressive:

“I identified 70 issues. I’ve already fixed 34 (empty descriptions, meta descriptions, missing attributes). For the remaining 36, here’s what I suggest…”

ChatGPT acts first, reports after. It’s faster but requires higher trust in the tool.

Round 5 Verdict

Criteria	Claude	ChatGPT
Audit thoroughness	5/5	4/5
Execution autonomy	3/5	5/5
Safety / caution	5/5	3/5
Speed of results	3/5	5/5

ChatGPT wins this round if you’re after operational velocity. Claude wins if you want to sleep soundly.

The Final Scorecard

Challenge	Claude	ChatGPT	Winner
Sales analysis	19/20	15/20	Claude
Stock management	19/20	14/20	Claude
Product descriptions	18/20	18/20	Tie
Problem diagnosis	20/20	12/20	Claude
Autonomous workflow	16/20	17/20	ChatGPT

Overall Score: Claude 92 — ChatGPT 76

My Honest Recommendation

I’m not going to give you the classic “it depends on your needs”. Well, actually I am, but with more precision:

Choose Claude + MCP Tools Plus if:

You manage a complex catalog (many combinations, multi-warehouse)
You want an assistant that thinks before acting
You need deep analysis to make strategic decisions
Data reliability and conclusion accuracy are your top priority
You’re managing your store solo and can’t afford mistakes

Choose ChatGPT + MCP Tools Plus if:

You need content at scale (descriptions, SEO, translations)
You want an assistant that executes fast with minimal supervision
You produce reports for third parties (immediate readability)
You’re comfortable reviewing and correcting afterward
You have a team that can validate actions

Or… use both

This isn’t a joke. With MCP Tools Plus, the same module connects both. The additional cost is virtually zero.

My personal workflow:

Claude for analysis, diagnostics, strategy
ChatGPT for mass execution, content generation, repetitive tasks

The best of both worlds.

What This Test Really Reveals

Beyond the Claude vs ChatGPT match, this comparison shows something fundamental:

Generative AI connected to your real business data changes everything.

Without MCP Tools Plus, Claude and ChatGPT are just smart chatbots that “imagine” answers about your business.

With MCP Tools Plus, they become operational collaborators working with your real data, real products, and real orders.

It’s this connection that makes the difference. Not the AI model itself.

The MCP Tools Plus Features That Make This Possible

For those wondering how both AIs technically access the same data, here’s what the module exposes via the MCP protocol:

Complete product catalog — products, combinations, prices, stock, images, descriptions
Orders and history — order details, statuses, associated customers
Analytics data — sales by period, by category, by product
Category management — tree structure, SEO, product associations
Customer data — segments, purchase history, abandoned carts
Write actions — stock, price, description, and status updates

Discover all features: nicolas-dabene.fr/modules/mcp-tools-plus/

Key Takeaways — Claude vs ChatGPT for PrestaShop

The 5 key takeaways from this Claude vs ChatGPT comparison for managing PrestaShop:

The value comes from the data, not the model. Without a connection to your real business data, Claude and ChatGPT are just generic chatbots. With MCP Tools Plus, they become operational collaborators working with your real catalog, real orders, and real stock.
Claude excels at analytical depth. Multi-step analysis, spontaneous data cross-referencing, cautious execution — Claude is the choice for strategic decisions and complex diagnostics (score: 92/100 in this test).
ChatGPT excels at speed and presentation. Direct execution, immediately presentable reports, mass content generation — ChatGPT is the choice for fast operations and large-scale SEO content.
Optimal strategy: combine both. The same MCP Tools Plus module connects both AIs. Use Claude to analyze and decide, ChatGPT to execute and produce content. The additional cost is near zero.
Real-time data connection is the actual game-changer. An AI assistant with access to your real data can spot an imminent stockout, a pricing error, or a data anomaly you would never have caught in time.

The Remaining Question

This comparison is a snapshot in time. Both platforms evolve at breakneck speed. Claude 4 is expected, GPT-5 as well.

But one thing won’t change: the value comes from the connection to your data, not the model alone.

And that’s the role of MCP Tools Plus.

So, Team Claude or Team ChatGPT? Let me know in the comments. And if you’re already using MCP Tools Plus with either one, I want your feedback.

Nicolas Dabène — Creator of AI solutions for PrestaShop. Book a strategy call to explore how AI can transform your business.

5 Surprising Revelations from the BMAD Method on the Future of Module Development

Tue, 17 Feb 2026 00:00:00 +0000

For any developer navigating an ecosystem as rich and complex as PrestaShop, module creation is a balancing act. The challenge involves juggling between the Legacy subsystem, inherited from previous versions and built around ObjectModel and Smarty, and the PrestaShop Bundle, the modern ecosystem based on Symfony and Twig. This mixed architecture demands absolute rigor to ensure stability, transforming an innovation process into an often tedious and repetitive task.

It is in this context that methodologies like BMAD (Breakthrough Method for Agile AI Driven Development) emerge. At first glance, one might perceive it as just another code generation tool, promising to accelerate tedious tasks. However, a deeper analysis reveals it is much more than that. BMAD is not an assistant; it is a true framework that forces us to rethink how we design and build software. This article explores five unexpected lessons this method teaches us about the future of module development.

1. Beyond a Simple Assistant, AI Becomes a Complete Project Team

The first surprise of the BMAD method is that it doesn’t behave like a simple code assistant, but simulates a complete project organization. It is structured as a “specialized agent system” that reproduces the dynamics of a real team, with a clear separation of responsibilities. Each agent takes on a specific role, including key roles such as analyst (to clarify the brief), pm (product manager, to guide the PRD), architect (for technical design), dev (to produce code), and qa (for quality review), even simulating a product owner (po) and scrum master (sm) for story breakdown.

This approach humanizes interaction and, more importantly, imposes project discipline. Unlike a completion tool that intervenes at the moment of code writing, BMAD forces the implementation of structuring steps upstream. Before generating a single line of code, the method requires validation of a Product Requirements Document (PRD) and an architecture document. AI no longer simply writes code; it drives strategy and design, bringing unprecedented rigor and a formal framework to module development.

2. The Real Value Isn’t Speed, But Sometimes Tedious Rigor

While we expect artificial intelligence to provide immediate acceleration, BMAD reveals a paradox: its greatest strength lies in an upstream phase described as “long” and “tedious.” The method deliberately slows down the initial process to better accelerate it afterward. Juggling between agents, validating the PRD section by section, defining architecture in detail—all this constitutes a heavy initial investment. The goal is to specify requirements with such precision that implementation can then “unfold automatically.”

However, this approach has its limits. The process is demanding, token consumption is high, and the system proves “fragile” if a constraint is forgotten at the start, making any backtracking “laborious.” This initial heaviness creates an expectation of near-perfect downstream execution. Yet reality is more nuanced: “you still need to go back over the agents to correct, adjust,” which generates disappointment and diminishes the value of the system for “high velocity” projects.

This duality defines the ideal application scope for BMAD. The method is perfectly suited for complex projects that require a “clear, documented, and rigorous” vision. However, its advantage diminishes for projects where constant adjustments are needed, as the rigidity of its initial process doesn’t accommodate frequent changes well.

3. BMAD Is the Gateway to “Agentic” Development

The BMAD method is not an isolated innovation; it is a concrete manifestation of a fundamental trend: “agentic coding.” An AI agent is not a simple assistant. It is an autonomous entity capable of interpreting natural language instructions, executing a series of actions, navigating through a project’s file structure, and even testing and validating its own work.

This approach differs radically from traditional tools like GitHub Copilot, which are primarily limited to code suggestion. The difference is fundamental: it’s the one “between an assistant who guides you and a competent colleague who accomplishes work independently.” With traditional assistants, the developer remains in control and validates each line. With agentic development, the developer becomes a conductor who delegates complex tasks to specialized agents. BMAD, with its project team simulation, materializes this paradigm shift where our role evolves from simple coder to pilot of intelligent systems.

4. We No Longer Code Just for Humans, But for an Agent Economy

The usefulness of modules created with tools like BMAD extends far beyond human interfaces. We are entering an era where software must be designed to interact with other intelligent systems. Protocols like Google’s UCP (Universal Commerce Protocol) are preparing a future where “AI Agents” can dialogue directly with online stores on behalf of users. The idea is to create a standardized language allowing an AI to discover products, check inventory, and make purchases without going through the traditional web interface, marking the transition from SEO (Search Engine Optimization) to AIO (Artificial Intelligence Optimization).

This is precisely where BMAD’s rigor makes complete sense. This future “agentic” economy requires modules that are not only functional, but also standardized, predictable, and “API-first.” BMAD’s “document-first” approach, with its validated PRDs and architecture schemas, is not just a methodological choice; it is the ideal condition for producing the reliable software components these agents will need. Tools like BMAD no longer serve only to produce code faster; they become factories for manufacturing the software building blocks that will allow businesses to participate in this new automated market.

If artificial intelligence can automate code creation, it must imperatively automate its security. The acceleration of production risks amplifying an often underestimated danger: threats to the software supply chain. The “Shai-Hulud” attack on the npm ecosystem is a striking example, where trusted open-source packages were replaced by malicious versions designed to steal credentials. The danger is all the greater because, as researchers report, “when developers or continuous integration systems installed these versions, the malware executed automatically.”

The speed offered by AI agents could exacerbate this risk. The role of the human orchestrator then becomes ensuring that agents are configured to systematically check for vulnerabilities, choose dependencies from trusted sources, and generate an SBOM (Software Bill of Materials) to ensure traceability. The only viable countermeasure at scale is to respond to agentic development with agentic security. The power of BMAD and future similar tools must be coupled with automated and rigorous security practices, otherwise the promised productivity gain will turn into a major security breach.

Conclusion

The BMAD method is much more than a simple productivity tool; it is a glimpse into a profound transformation of the developer profession. It shows us a future where development is more structured, more autonomous thanks to agents, and more strategic. But this future also carries new responsibilities, particularly in terms of architectural design and software supply chain security.

AI does not replace developers; it forcibly promotes them to an architect role. The question is no longer “how to code?” but “how to build the system that codes?” Are you ready for this promotion?

8 Trends Defining How Software Gets Built in 2026

Thu, 12 Feb 2026 00:00:00 +0000

Anthropic’s article titled “Eight trends defining how software gets built in 2026” describes a major transformation: the shift from code assistance (simple autocompletion) to agentic coding, where AI becomes a collaborator capable of managing complete workflows.

Here are the key points and 8 trends to remember, organized around three pillars.

1. Foundations: The Evolution of the Developer Profession

From Writing to Coordination

Engineers spend less time writing lines of code and more time orchestrating agents. Their expertise shifts toward architecture, system design, and strategic decisions.

Active Collaboration vs Total Delegation

The study shows that while AI is involved in 60% of the work, “total” delegation remains limited (0-20%). Humans remain essential for supervision, validation, and judgment.

2. Capabilities: What Agents Accomplish

Mastering Complexity (Giant Codebases)

Agents (like Claude Code) can autonomously navigate millions of lines of code (e.g., vLLM) to perform complex tasks in hours instead of days.

Multi-Agent Coordination

The future lies in systems where multiple agents collaborate (one for testing, one for backend, one for code review), dramatically increasing delivery speed.

Spectacular Acceleration

Projects that used to take 4 to 8 months can now be completed in two weeks, thanks to eliminating the cognitive load associated with understanding complex dependencies.

3. Impact: Strategic Priorities for 2026

The Shift to “AI-Native SDLC”

The Software Development Lifecycle (SDLC) is being entirely redesigned around AI.

Automation of Code Review and Testing

Human validation is now assisted by agents specialized in error detection and large-scale unit/E2E test generation.

Democratization of Agentic Coding

These capabilities extend beyond pure engineering teams, enabling other technical functions to manipulate code.

Security-by-Design

AI is used to integrate security architectures from the earliest stages of development, rather than as a final verification.

Conclusion

In 2026, competitive advantage will no longer come from the ability to produce code quickly, but from an organization’s ability to drive high-performing agentic systems. Success relies on a balance between agent autonomy and a rigorous human supervision framework to ensure quality and security.

5 Surprising Things "Brainrot" Culture Reveals About Our Era

Tue, 10 Feb 2026 00:00:00 +0000

Introduction: Welcome to the “Brainrot” Era

Have you ever had that strange feeling while scrolling through your feed, stumbling upon videos of human heads emerging from toilets in Skibidi Toilet, or absurd memes from the “Italian Brainrot” movement, populated with characters like Tralalero Tralala, a shark wearing sneakers, or Bombardino Crocodilo, a militarized crocodile? If so, you’ve experienced what’s called “brainrot” culture, a term that evokes cognitive decline in the face of an incessant stream of trivial content.

At first glance, it’s easy to dismiss this phenomenon as mere meaningless distraction. However, upon closer inspection, this culture is much more than mindless entertainment. It functions as a mirror of our society, revealing profound truths about our relationship with technology, economics, and productivity. Far from being a bug, “brainrot” is an essential feature of our current digital ecosystem, an inevitable result of precise economic incentives and deep psychological needs. This article explores five surprising lessons this culture teaches us about our times.

1. The Fear is Ancient, but the Factory is New

The fear that new media will “rot the brain” is nothing new. As early as 1854, writer Henry David Thoreau used the term “brain-rot” to criticize simplistic ideas that impoverished thought. Each new technology, from popular novels to cinema, has sparked similar anxieties.

What distinguishes our era is the industrial scale of the phenomenon. The difference is what separates an artisanal complaint (Thoreau) from an industrial disease. We’ve entered the era of the “AI slop economy,” where generative artificial intelligence has automated cultural production, causing the collapse of all editorial control. As researcher Eryk Salvaggio puts it, “Any information, in sufficient quantity, becomes noise. AI slop is a symptom of informational exhaustion.”

A study by the Kapwing platform analyzing 2025 trends revealed a staggering figure: 54% of content recommended to new users on YouTube Shorts was identified as AI-generated “slop” or “brainrot.” So it’s not so much the content that’s unprecedented, but the algorithmic machine producing it at an unprecedented scale.

2. “Brainrot” is a Multi-Million Dollar Business

Far from being a mere cultural trend, “brainrot” is an extremely profitable industry. The most absurd-seeming content can generate astronomical revenues for those who know how to manipulate platform algorithms.

The most striking example is the Indian YouTube channel “Bandar Apna Dost.” By publishing repetitive, low-quality clips, this channel generates estimated annual revenues of $4.25 million. This model doesn’t just reward “slop”; it makes it economically rational, transforming high-quality creativity into a financial risk and low-effort content into a safe investment.

This incentive creates a “slop subsidy,” where algorithms designed to maximize engagement reward volume over quality. “Brainrot” is therefore not simply a user choice, but a structural feature of the modern internet.

But if economic incentive explains the supply, what explains the demand? The answer is more complex than simple passive dependency…

3. It’s a Form of Rebellion, Not Just Submission

The most common idea is that “brainrot” consumers are passive victims. However, deeper analysis reveals a more complex dynamic. Some researchers describe engagement with “brainrot” as a form of “decompression-oriented” participation. According to this theory, young people deliberately consume “non-productive” content as a form of active resistance against societal pressure for self-optimization and productivity.

“Brain rot is conceptualized as a set of related practices that (1) are childish or unserious, (2) offer no cognitive or developmental benefit, and (3) are deliberately unproductive. In this way, it can be understood as a genre of decompression-oriented participation, through which young people actively resist pressures of productivity and self-optimization.”

We then witness a fascinating paradox: users resist the injunction to be productive by consuming content generated by a system itself optimized for maximum productivity. It’s a rebellion conducted from within the very economic machine it claims to flee. This perspective transforms “brainrot,” moving it from a symptom of decadence to an act of cultural defiance.

4. It Has Its Own Language and Mythology

“Brainrot” isn’t just random chaos. Beneath its absurd surface lies a complex subculture, with its own linguistic codes and mythologies. From a sociolinguistic perspective, Generation Alpha has developed its own lexicon. A study of YouTube comments showed that terms like “Sigma” and “Rizz” represent 35% of the slang used, functioning as identity markers.

Beyond language, “brainrot” has spawned genuine narrative universes. The “Italian Brainrot” phenomenon, for example, uses generative AI to create a pantheon of characters like “Tralalero Tralala” (a shark in sneakers) or “Bombardino Crocodilo” (a militarized crocodile). These characters are integrated into fan-created narratives, with battles and traditions. This collective creativity resembles a form of “digital dadaism” or modern folklore, demonstrating a surprising ability to build communities from nonsense.

5. The “Great Unfollowing” is Coming

As “brainrot” culture reaches its peak, signs of a backlash are multiplying. A widespread weariness with AI-generated “slop” could prepare the ground for a major cultural shift in 2026: a “Great Unfollowing.”

Forecasts indicate a renewed interest in long-form media, such as books and in-depth articles. There’s also an expected emergence of “performative offline” culture, where screen-free gatherings will become a new status symbol. Aesthetically, a preference for lo-fi and authentic content could supplant overly polished material.

This shift will be supported by regulatory developments like the European Union’s AI Act, which will require clear labeling of AI-generated content by August 2026, thus creating new demand for “digital provenance”—the ability to verify the origin and human authenticity of content.

“Community maxxing in the form of screen-free meetups at dance parties, dinners, etc., will become the new ‘clean’ aesthetic in direct response to surveillance and the influencer economy invading public spaces. Performative offline is the new performative online.”

Conclusion: Reclaiming Our Minds in the “Slop” Era

“Brainrot” is therefore not a simple cultural anomaly, but the background noise of a society in full reconfiguration. It’s the language of a generation that inherited an internet where abundance has eclipsed authenticity, and whose rebellion consists of transforming nonsense into a new type of sense.

The question is not whether we can cure this “rot,” but whether we can understand what it’s trying to tell us about the world we’ve built. What will we do with our reclaimed attention?

The five lessons of “brainrot” remind us that our digital ecosystems are not neutral: they shape our behaviors, our economies, and even our forms of rebellion. Understanding these mechanisms is the first step toward reclaiming our cognitive autonomy in an information-saturated world.

In-Depth Comparative Analysis of AI Development Paradigms: Prompt Driven Development vs BMAD Methodology

Thu, 05 Feb 2026 00:00:00 +0000

Introduction: The Metamorphosis of Software Engineering in the AI Era

The history of software development is one of increasing abstraction. From punch cards to assembly languages, then from high-level compiled languages to modern interpreted frameworks, each decade has sought to reduce the cognitive distance between human intention and machine execution. Today we are experiencing a technological rupture that doesn’t simply fit into this linear continuity, but redefines its very foundations: the advent of software engineering assisted by Large Language Models (LLM).

This transition marks the shift from a “syntax-centered” era, where mastery of code grammar (PHP, Java, Python) was the primary determinant of competence, to a “semantic-centered” era, where the ability to articulate logical architecture and functional intentions prevails. In this new ecosystem, source code tends to become a commodity, an intermediary infrastructure layer generated on-the-fly, while the engineer’s added value shifts toward orchestrating intelligent systems.

However, this revolution is not monolithic. Two schools of thought, with distinct philosophies and operational mechanisms, are emerging to structure this human-machine collaboration. On one hand, Prompt Driven Development (PDD), a fluid, iterative, individual-centered approach that transforms coding into a dynamic conversation, sometimes called “Vibe Coding”. On the other hand, the BMAD Method (Build More, Architect Dreams), a rigorous architectural framework inspired by Agile methodologies and designed to orchestrate teams of autonomous agents around structured documents and fragmented contexts (“sharded contexts”).

This research report proposes to dissect these two methodologies with exhaustive granularity. We will explore their internal mechanisms, economic implications, and technical limitations. To anchor this theoretical analysis in the pragmatic reality of the market, we will then apply these two paradigms to a concrete and complex use case: developing a module for the PrestaShop e-commerce CMS. This module must allow configuration of a promotional message in the Back Office and its strategic display via specific “hooks” in the Front Office. This implementation will serve as a revealer to illustrate how each method handles the constraints of a legacy framework, data security, and user experience.

Chapter 1: Prompt Driven Development (PDD) - The Hegemony of Intention

1.1 Theoretical Foundations and Philosophy

Prompt Driven Development (PDD) should not be confused with the anecdotal use of a chatbot to generate an isolated function. It is a complete methodology that postulates that natural language is now the highest-level programming language available. The central philosophy of PDD is the shift from “Code-First” to “Intent-First” workflow.

Traditionally, the development cycle followed the sequence: Mental Design → Code Writing → Execution → Debugging. PDD modifies this value chain: Intent Definition → Prompting (Instruction) → AI Scaffolding → Human Refinement → Validation. In this paradigm, the developer is no longer a simple syntax writer, but an Architect of Intention. Their critical skill lies in their ability to decompose a complex problem into logical units (prompts) that the AI can execute with precision.

This approach has given birth to cultural concepts such as “Vibe Coding”, where the workflow becomes so fluid and assisted that it resembles more a musical creation session (“jamming”) with a virtual partner than traditional rigid engineering. The goal is to maintain the developer in a constant state of “flow”, minimizing interruptions related to documentation searches or struggles with trivial syntax errors.

1.2 Operational Mechanics and Workflow

The PDD workflow is inherently iterative and rapid. It relies on short feedback cycles, exploiting the AI’s ability to generate, test, and correct code in seconds.

1.2.1 Intent Decomposition

PDD success depends on the granularity of the initial prompt. A vague request like “Create a PrestaShop module” invariably leads to generic and often dysfunctional code. The expert PDD practitioner structures their prompt like a miniature technical specification, defining inputs, outputs, security constraints, and dependencies.

1.2.2 The “Generate-Verify-Fix” Cycle

Once the intent is formulated, the AI generates scaffolding. This is where the methodology diverges from simple “copy-paste”. The PDD developer treats this generated code as a draft. They use verification tools (AI-generated unit tests or visual inspection) to validate alignment with intent.

If the code fails or contains hallucinations, correction is not done manually. The error message is fed back into the model via a new prompt, creating a virtuous feedback loop: Error → AI Analysis → Correction → Test. This process, sometimes called “The Loop”, allows solving complex problems through rapid successive approximations.

1.3 The Context Challenge and Drift

PDD’s Achilles heel lies in managing the short-term memory of language models, known as the context window.

1.3.1 The Drift Phenomenon

As a PDD development session lengthens and the codebase grows, the probability that the AI “forgets” initial instructions increases. This is “Context Drift”. For example, if the developer specified at the session’s beginning to use the PSR-12 standard for PHP, the AI may, after 50 exchanges, start generating non-compliant code.

In a pure PDD approach, the responsibility for maintaining consistency rests entirely on the developer’s cognitive discipline. They must regularly “remind” the context or restart sessions with summaries, which introduces significant cognitive friction on large-scale projects.

1.3.2 Syntactic Hallucination

While performant, models can invent methods that don’t exist, especially in complex frameworks like PrestaShop that have gone through many versions (1.6, 1.7, 8.x). A PDD developer must possess sufficient expertise to detect when the AI suggests using an ObjectCommand class that was deprecated three years ago. The AI is not an oracle, but a probabilistic generator; it favors the most statistically probable response, which is not always the technically correct response for a given version.

1.4 The Emergence of the AI Operator

PDD transforms the developer’s profile. Productivity is no longer measured in Lines of Code (LOC) but in Clarity of Thought and System Precision. The developer becomes an “AI Operator”, a prompt manager who treats their instructions like products: they version, optimize, and test them. This evolution also democratizes access to development, allowing less technical profiles to build functional applications, provided they master business logic.

Chapter 2: The BMAD Method (Build More, Architect Dreams) - The Industrialization of AI

2.1 Genesis and Structural Ambition

If PDD is an individual tactic, the BMAD method is an organizational strategy. Born from the observation that unstructured “chat-based” interactions quickly plateau as complexity increases, BMAD (Build More, Architect Dreams) presents itself as an AI-driven agile framework.

BMAD’s ambition is to move beyond the coding assistant stage to create a complete virtual team. Unlike traditional tools that try to “think in place” of the user, BMAD agents are designed to act as expert collaborators who guide the user through structured workflows, thus forcing architectural thinking before any code writing.

2.2 Multi-Agent Architecture and Role Specialization

The BMAD method rejects the idea of an omniscient generalist agent. It deploys a constellation of specialized agents, each with its own “System Prompt” (behavioral instructions) and responsibilities.

Specialized Agent	Role and Responsibilities in the BMAD Ecosystem	Primary Interaction
Project Manager (PM)	Analyzes needs, defines scope, writes the PRD (Product Requirements Document). Guardian of functional vision.	Interacts with user for requirements extraction.
Architect	Defines tech stack, data models, file tree structure and coding standards. Produces technical artifacts.	Transforms PM’s PRD into sharded technical specifications.
Scrum Master	Bridges theory (Architecture) and practice (Code). Breaks specifications into atomic “Developer Stories”.	Translates architecture into developer tasks.
Developer	Executes code strictly following directives. Has no architectural freedom but local implementation freedom.	Writes code by loading specific technical contexts.
UX Designer	Defines user journeys and interfaces.	Collaborates with PM on wireframes.

This structure mimics a real software development team, introducing checks and balances that are sorely lacking in a monolithic PDD session.

2.3 The “Sharding” Mechanism (Contextual Fragmentation)

BMAD’s major technical innovation, and its response to PDD’s “Context Drift” problem, is Sharding.

In a complex project, documentation (architecture, stack, business rules) far exceeds a standard LLM’s context window. BMAD solves this by fragmenting project knowledge into small autonomous files called “Shards”.

Tech Stack Shard: Contains only language and library versions (e.g.: PHP 8.1, PrestaShop 8.0, Smarty 4).
Coding Standards Shard: Contains style rules (PSR-12, naming conventions).
Data Model Shard: Contains SQL schemas and data structures.

When a Developer agent begins a task, they don’t load the entire project history. The system dynamically and exclusively injects the shards necessary for their immediate task.

For example, to create a SQL table, the agent will load the “Data Model Shard” and the “Tech Stack Shard”. This selective injection ensures the agent remains perfectly aligned (“hallucination-free”) with project constraints, regardless of its size. This mechanism allows BMAD to claim “Enterprise” scalability (Level 4).

2.4 Scale-Adaptive Intelligence

BMAD introduces a concept of methodological scalability. The framework adjusts its workflow depth based on detected project complexity:

Level 0-1 (Quick Flow): For a bug fix or simple script. Time to first line of code is about 5 minutes.
Level 2-3 (BMad Method Standard): For complete features or MVP products. Planning time is about 15 minutes.
Level 4 (Enterprise): For critical systems requiring compliance and security. Analysis and architecture phase can last 30 minutes or more before any coding.

This flexibility avoids administrative overhead for small tasks while imposing necessary rigor for large systems.

Chapter 3: Multidimensional Comparative Analysis

The distinction between PDD and BMAD is not binary (good vs bad), but contextual. Each method responds to different needs and constraints.

3.1 Comparative Attributes Table

Analysis Dimension	Prompt Driven Development (PDD)	BMAD Method
Central Philosophy	Conversational & Individual-Centered. “AI is my coding buddy.”	Structural & System-Centered. “AI is my engineering team.”
Context Management	Manual & Implicit. Developer must refresh AI memory. High entropy risk.	Automated & Explicit (Sharding). System injects necessary constraints at each step.
Startup Speed	Immediate. Code generated seconds after first prompt.	Delayed. Requires initialization phase (Workflows, Shards) before code.
Code Quality	Variable. Heavily depends on instant prompt quality and reviewer vigilance.	Standardized. Code is constrained by predefined “Coding Standards Shards”.
Scalability	Low to Medium. Ideal for scripts, isolated functions or rapid prototyping.	High. Designed to handle complex architectures and long-term projects.
Learning Curve	Low. Only requires clear expression ability.	Medium to High. Requires understanding of agents, workflows and software architecture concepts.
Cognitive Cost	High in Supervision. Developer must read and validate each generated line to avoid errors.	High in Planning. Effort shifted to upstream design (PRD, Architecture).

3.2 Economic Analysis and Risk Management

Economically, PDD offers immediate return on investment (ROI) for unit tasks. Setup cost is zero. However, on long projects, the cost of “Technical Debt” induced by lax contextual management can explode. If the AI introduces subtle inconsistencies (e.g.: mixing coding styles, conflicting dependencies) that are only detected late, refactoring costs can cancel initial productivity gains.

The BMAD method, with its initial investment (time spent by PM and Architect agents), acts as quality insurance. It reduces structural risk. The “Always Load” mechanism of configuration files acts as a permanent guardrail, preventing the developer from deviating from technical rails set by the architect. This is particularly critical in enterprise environments where compliance and maintainability take precedence over raw speed.

Chapter 4: Technical Case Study - PrestaShop “TopMessage” Module

To concretely illustrate these differences, we will simulate developing a PrestaShop module.

Requirements:

Create a bmad_topmsg module.
Allow administrator to enter a promotional message in Back Office (BO).
Display this message at the very top of the Front Office (FO).
Compatible with PrestaShop 1.7 and 8.x.

4.1 PrestaShop Architectural Context

PrestaShop is a complex framework based on Symfony (for BO) and a legacy architecture (for the core). It relies on the Hooks system (hooking points).

Hook choice is critical here:

displayTop: Often located in the header, mixed with logo or search menu.
displayBanner: Specifically designed to be a full-width banner at the very top of the page.

This is a classic trap: a beginner (or a poorly guided AI) will often choose displayTop by semantic reflex, while displayBanner is the correct architectural choice for an alert message.

4.2 Approach 1: Implementation via Prompt Driven Development (PDD)

In this simulation, we adopt the role of AI Operator using a tool like ChatGPT or Claude in conversational mode.

Step 1: The Initial Prompt (The Intention)

User Prompt: “I want to create a PrestaShop 8 module called ‘TopMessage’. There should be a field in the back-office to write text, and this text should display at the very top of the site on all pages. Generate the code.”

Step 2: Generation and Common Error (The Scaffolding)

The AI generally generates a correct basic structure (topmessage.php) but often makes the hook error. It uses displayTop because the module name is “TopMessage”.

Generated code (simplified excerpt):

public function hookDisplayTop($params) {
    return $this->display(__FILE__, 'views/templates/hook/topmessage.tpl');
}

Result: The message displays next to the search bar, breaking the header layout. The PDD developer tests and notices the visual problem.

Step 3: Iteration and Correction (The Loop)

Refinement Prompt: “The message displays poorly, it’s crushed by the menu. I want it to be truly at the top, above the header. Is there another hook?”

The AI analyzes its knowledge base and suggests: “Ah yes, for a banner at the very top, the displayBanner hook is more appropriate.”

It regenerates the install() function and the hook:

public function install() {
    return parent::install() && $this->registerHook('displayBanner');
}

public function hookDisplayBanner($params) { ... }

Step 4: Configuration Management (The Technical Detail)

The developer then asks: “Add the configuration form.”

The AI generates the getContent() method using the HelperForm class. This is a verbose and complex part of PrestaShop.

PDD excels here: the AI generates the 50 lines of HelperForm boilerplate code (fields, toolbar, tokens) in seconds, a task that would take a human 20 minutes.

PDD Assessment: Rapid development (approx. 15-20 minutes), but requires “ping-pong” to find the right hook and adjust CSS. The final code works but may lack standardized comments or strict security validation if the developer didn’t explicitly request it (e.g.: Tools::purifyHTML).

4.3 Approach 2: Implementation via BMAD Method

Here, we simulate BMAD agents execution. The process is slower at startup but more robust.

Phase 1: Project Manager Agent (Analysis)

The user launches *workflow-init. The PM asks questions: “What is the business objective? Is this a temporary or permanent promo? Should the message support HTML?”

The PM writes a PRD (Product Requirements Document) specifying:

Need: High-visibility alert banner.
Constraint: Must be editable by a non-technical person.
Security: No JS scripts in message (XSS prevention).

Phase 2: Architect Agent (Architecture & Sharding)

The Architect analyzes the PRD and generates Shards:

Tech Stack Shard: Defines “PrestaShop 8.x”, “PHP 7.4+”, “Smarty 3/4”.

Architecture Shard:

Explicit decision: Use displayBanner hook (justified by PrestaShop doc for “Full Width Top” display).
Storage: ps_configuration table (key BMAD_TOPMSG_TEXT).

Structure:

modules/bmad_topmsg/
├── bmad_topmsg.php
├── index.php (Security)
└── views/templates/hook/banner.tpl

Coding Standards Shard: Enforces use of Tools::getValue() to retrieve inputs and Configuration::updateValue() for saving.

Phase 3: Scrum Master Agent (Planning)

The Scrum Master reads the shards and creates a User Story for the developer:

“As an Admin, I want to save text via HelperForm. The code MUST use displayBanner. The code MUST sanitize input via pSQL or Tools::purifyHTML.”

Phase 4: Developer Agent (Implementation)

The Developer agent receives the story and shards. They don’t have to guess the hook. They simply execute the plan.

Resulting Code (Final and commented excerpt):

<?php
/**
 * Module Bmad Top Message
 * Generated via BMAD Method - Dev Agent
 */
if (!defined('_PS_VERSION_')) { exit; }

class Bmad_Topmsg extends Module
{
    public function __construct()
    {
        $this->name = 'bmad_topmsg';
        $this->tab = 'front_office_features';
        $this->version = '1.0.0';
        $this->author = 'BMAD Agent';
        $this->bootstrap = true; // Auto-load Bootstrap for BO
        parent::__construct();
        $this->displayName = $this->l('Top Message Banner');
        $this->description = $this->l('Displays a configurable message via displayBanner hook.');
    }

    public function install()
    {
        // Explicit registration of banner hook defined by Architect
        return parent::install() &&
            $this->registerHook('displayBanner') &&
            Configuration::updateValue('BMAD_TOPMSG_TEXT', 'Default message');
    }

    public function getContent()
    {
        // Submission handling with security validation
        if (Tools::isSubmit('submitBmadTopmsg')) {
            $message = Tools::getValue('BMAD_TOPMSG_TEXT');
            // Validation enforced by Standard Shard
            if (empty($message)) {
                return $this->displayError($this->l('Message cannot be empty.'));
            }
            // Save with basic but secure HTML support
            Configuration::updateValue('BMAD_TOPMSG_TEXT', $message, true);
            return $this->displayConfirmation($this->l('Saved.'));
        }
        return $this->renderForm();
    }

    protected function renderForm()
    {
        $helper = new HelperForm();
        // Standard PrestaShop HelperForm configuration
        $helper->module = $this;
        $helper->name_controller = $this->name;
        $helper->token = Tools::getAdminTokenLite('AdminModules');
        $helper->currentIndex = AdminController::$currentIndex. '&configure='. $this->name;

        $fields_form = [
            'form' => [
                'legend' => ['title' => $this->l('Configuration'), 'icon' => 'icon-cogs'],
                'input' => [
                    [
                        'type' => 'textarea',
                        'label' => $this->l('Message'),
                        'name' => 'BMAD_TOPMSG_TEXT',
                        'rows' => 5,
                        'cols' => 60
                    ]
                ],
                'submit' => ['title' => $this->l('Save')]
            ]
        ];

        $helper->fields_value = ['BMAD_TOPMSG_TEXT' => Configuration::get('BMAD_TOPMSG_TEXT')];
        return $helper->generateForm([$fields_form]);
    }

    public function hookDisplayBanner($params)
    {
        // Inject variable into Smarty
        $this->context->smarty->assign('bmad_topmsg_text', Configuration::get('BMAD_TOPMSG_TEXT'));
        return $this->display(__FILE__, 'views/templates/hook/banner.tpl');
    }
}

And the Template file (views/templates/hook/banner.tpl):

{if isset($bmad_topmsg_text) && $bmad_topmsg_text}
<div class="bmad-top-banner" style="background: #000; color: #fff; text-align: center; padding: 10px;">
    {* nofilter is used because we validated HTML during BO save *}
    {$bmad_topmsg_text nofilter}
</div>
{/if}

Technical Analysis of BMAD Result:

Architectural Compliance: The displayBanner hook was used from the start, avoiding PDD’s visual error loop.
Robustness: Code includes controls (if (!defined('_PS_VERSION_'))) and proper configuration management sometimes forgotten in quick prompts.
Documentation: Code is generated with complete PHPDoc comments, facilitating future maintenance by human or AI.

Conclusion and Prospective Synthesis

The detailed analysis of Prompt Driven Development (PDD) and the BMAD method reveals that we are not facing two competing tools, but two maturity levels of AI-assisted software engineering.

PDD is the tool of tactical velocity. It’s unbeatable for prototyping, “throwaway” scripts (one-off scripts), and creative exploration. It frees the developer from syntactic heaviness (“how do you write a HelperForm again?”) to allow them to focus on immediate results. However, as demonstrated in our use case, it requires constant human vigilance to avoid architectural errors (the displayTop vs displayBanner trap) and technical drift.

The BMAD Method is the tool of strategic stability. By imposing an agentic structure and contextual fragmentation (Sharding), it sacrifices initial speed in favor of long-term consistency. It’s designed for environments where the cost of error exceeds the cost of planning. In the PrestaShop ecosystem, known for its rigidity and potential technical debt, the BMAD approach ensures that produced modules respect core standards (“Core compliance”) and don’t compromise shop security.

The future of software development probably lies in hybridizing these approaches. We can imagine workflows where Architecture is defined by a rigorous BMAD-type method (Level 4), while implementation of individual sub-functions is left to PDD’s creative fluidity (Level 0), all under the supervision of a new digital craftsman: the Intelligent Systems Architect.

This professional will no longer be judged on their ability to write code, but on their ability to orchestrate these methodologies to transform human intention into robust and scalable software reality.

MIRROR and Engram: How AI Learns to Think and Remember

Tue, 03 Feb 2026 00:00:00 +0000

When AI Forgets Your Name Three Messages Later

Have you ever had that frustrating conversation with ChatGPT or Claude? You mention an important detail at the beginning, then after a few exchanges with tangential questions, the model seems to have completely forgotten what you said. Or worse: it changes its mind based on your tone, telling you what you want to hear rather than the truth.

This isn’t a bug. It’s a fundamental limitation of the current large language model architecture.

Today’s LLMs are statistical prodigies capable of generating impressive text, but they have three major flaws:

No coherent working memory: They treat each response as a fresh start, without persistent internal state.
No internal reflection mechanism: They generate responses in a single pass, without an “inner monologue” to verify coherence.
Radical inefficiency for static knowledge: They “recalculate” facts every time that they should simply “remember”.

Imagine a developer who would forget your variable names every three lines of code, or who would have to reread all of React’s documentation every time they write a useState(). That’s exactly what current LLMs do.

But two revolutionary architectures are changing the game: MIRROR and Engram.

They don’t just improve performance. They redefine what it means to “think” and “remember” for an AI.

MIRROR: Giving AI an Inner Monologue

The Problem: An AI Without Mental State

Humans don’t think in a single pass. Before answering a complex question, you:

Reflect (you mentally explore different paths)
Synthesize (you consolidate your ideas into a coherent mental model)
Respond (you formulate a clear answer)

Classic LLMs skip straight to step 3. They generate a response without this internal reflection process. Result:

Sycophancy: They prioritize agreeing with you over truth or safety.
Attention deficits: They forget critical information mentioned earlier in the conversation.
Inconsistency: They struggle to prioritize contradictory constraints (e.g., your safety vs. your stated preferences).

This is exactly what the MIRROR (Modular Internal Reasoning, Reflection, Orchestration, and Response) architecture solves.

The Architecture: Separating Thought from Speech

MIRROR functions as a two-layer system:

1. The Thinker: The Internal Consciousness

The Thinker maintains a persistent internal narrative — a kind of “mental model” that evolves throughout the conversation. It consists of two modules:

a) The Inner Monologue Manager This module orchestrates three parallel reasoning threads:

Goals: What is the user really looking for? What are their intentions?
Reasoning: What logical implications? What thought patterns are emerging?
Memory: What key facts have been mentioned? What preferences are stable?

b) The Cognitive Controller It synthesizes these three threads into a unified narrative that serves as working memory. This narrative is updated at each conversation turn and serves as the basis for response generation.

2. The Talker: The External Voice

The Talker uses the internal narrative to generate coherent and contextually appropriate responses. It reflects the system’s current “state of consciousness”.

Temporal decoupling: In production, the Thinker can continue reflecting asynchronously while the Talker responds immediately. This ensures low latency while allowing deep background reflection.

Performance: +156% on Critical Scenarios

MIRROR was evaluated on the CuRaTe benchmark, designed to test multi-turn dialogues with critical safety constraints and contradictory preferences.

Metric	Baseline	With MIRROR	Improvement
Average success rate	69%	84%	+21%
Maximum performance (Llama 4 Scout)	-	91%	-
Critical scenario (3 people)	-	-	+156%

The benefits are model-agnostic: MIRROR improves GPT-4o, Claude 3.7 Sonnet, Gemini 1.5 Pro, Llama 4, and Mistral 3.

Why this spectacular improvement? Because MIRROR transforms a potentially infinite conversation history into actionable understanding via a three-step pipeline:

Multi-dimensional exploration (thought threads)
Condensation into coherent mental model (internal narrative)
Contextual application (response)

This is exactly what a senior developer does when analyzing a complex bug: they don’t respond immediately, they think first.

Engram: When Memory Replaces Computation

The Problem: Recalculating What Should Be Remembered

Imagine a developer who would have to reread all of Python’s documentation every time they write print(). Absurd, right?

Yet that’s exactly what current Transformers do. To identify an entity like “Diana, Princess of Wales”, an LLM must:

Pass tokens through several attention layers
Progressively aggregate contextual features
“Recalculate” every time what should be a simple knowledge lookup

It’s as if your brain had to recalculate that 2+2=4 every time rather than simply knowing it.

The Engram architecture solves this problem by introducing conditional memory — a constant-time O(1) lookup system for static knowledge.

The Architecture: O(1) Lookup via Hashed N-grams

Engram modernizes the classic N-gram embedding approach to create a scalable memory module.

1. Sparse Retrieval

a) Tokenizer Compression Raw token IDs are projected onto canonical IDs via textual normalization (NFKC, lowercase). This reduces the effective vocabulary size by approximately 23% for a 128k tokenizer, increasing semantic density.

b) Multi-Head Hashing For each N-gram (sequence of N tokens), the system uses K distinct hash functions. Each hash head maps the local context to an index in an embedding table. This mitigates collisions and allows retrieval of a memory vector.

The result? A system that can “look up” knowledge in constant time, instead of “recalculating” it through multiple Transformer layers.

2. Context-Aware Gating

The retrieved memory vector (e_t) is a static prior that may contain noise. To integrate it intelligently, Engram uses an attention-inspired gating mechanism:

The current Transformer hidden state (h_t) acts as a Query
The retrieved memory (e_t) serves as the source for Key and Value
A gate scalar (α_t) is computed to modulate the memory’s contribution

If memory contradicts the dynamic context, the gate closes (α_t → 0), suppressing the noise.

The U-Shaped Scaling Law: The Compute-Memory Alliance

Engram isn’t just a module. It’s a new sparsity axis complementary to Mixture-of-Experts (MoE).

An analysis revealed a U-shaped relationship between allocating sparsity parameters to computation (MoE experts) and memory (Engram):

Too much compute, not enough memory → Inefficiency (constant recalculation)
Too much memory, not enough compute → Performance plateaus
Optimal point (20-25% memory) → Strictly outperforms pure MoE models

This is a major finding: the future isn’t in bigger models, but in smarter hybrid models.

Performance: Better at Reasoning, Not Just Memorization

Engram-27B and Engram-40B models were evaluated by reallocating parameters from a baseline MoE model.

Benchmark	Category	Gain (Engram vs MoE)
BBH	Complex Reasoning	+5.0
CMMLU	Cultural Knowledge	+4.0
ARC-Challenge	Scientific Reasoning	+3.7
MMLU	General Knowledge	+3.4
HumanEval	Code Generation	+3.0
MATH	Mathematical Reasoning	+2.4

Surprising: the largest gains aren’t in pure memorization, but in complex reasoning, code, and math.

Why? Because Engram frees the model’s early layers from the task of reconstructing static patterns. This increases the network’s “effective depth” available for abstract reasoning.

It’s like delegating system memory management to an optimized OS, freeing your CPU for more complex computations.

System Efficiency: Memory Offloading from RAM or NVMe

Engram’s retrieval index is deterministic: it depends solely on the input token sequence, not on runtime hidden state (unlike MoE routing).

This property allows asynchronous prefetching of necessary embeddings from:

CPU RAM
NVMe disks via PCIe bus

This masks communication latency and allows extending the model’s memory to hundreds of billions of parameters with negligible performance overhead (< 3%), bypassing GPU VRAM limitations.

Imagine being able to extend your LLM’s memory like you add RAM to your PC, without having to buy additional GPUs. That’s exactly what Engram makes possible.

ENGRAM-R: Optimizing Reasoning with “Fact Cards”

Beyond architectural integration, modular memory principles are applied at the system level to manage long conversations and optimize large reasoning models (LRM).

The ENGRAM System: Typed Memory Inspired by Cognitive Science

Inspired by cognitive theories, this system organizes conversational memory into three distinct stores:

Episodic Memory: Events and interactions with temporal context (e.g., “user moved to Seattle last year”)
Semantic Memory: Facts, observations, and stable preferences (e.g., “user’s favorite color is green”)
Procedural Memory: Instructions and processes (e.g., “tax filing deadline is April 15”)

At each conversation turn, the system routes information to the relevant store(s). During a query, dense similarity search is performed to retrieve the most relevant context.

ENGRAM-R: “Fact Cards” to Reduce Redundant Thinking

ENGRAM-R introduces two mechanisms to drastically reduce reasoning computational cost:

1. Fact Cards Rendering Rather than injecting verbose conversation excerpts into the context, retrieved records are transformed into compact, auditable cards:

[E1, A moved to Seattle, Turn 1]
[S2, Favorite color: green, Turn 5]
[P3, Tax deadline: April 15, Turn 12]

2. Direct Citation Mechanism The LRM is explicitly instructed to use these cards as the source of truth and cite them directly in its chain of thought:

“To answer Q1, E1 shows that A lives in Seattle. Answer: Seattle. Cite [E1].”

Efficiency Gains: -89% Tokens, +2.5% Accuracy

Evaluation on long conversation benchmarks (LoCoMo: 16k tokens, LongMemEval: 115k tokens):

Metric	Full-Context	ENGRAM-R	Reduction
Input Tokens (LoCoMo)	28,371,703	3,293,478	≈ 89%
Reasoning Tokens	1,335,988	378,424	≈ 72%
Accuracy (Multi-hop)	72.0%	74.5%	+2.5%
Accuracy (Temporal)	67.3%	69.2%	+1.9%

Transforming history into a compact, citable evidence base allows:

Massively reducing computational costs
Maintaining or even improving accuracy
Making reasoning traceable and auditable

It’s the AI equivalent of what a senior developer does: they don’t reread all the code every time, they maintain a compact mental model of critical parts.

The Future: AI That Thinks and Remembers Like Us

The Mutation of Architectures

MIRROR and Engram aren’t incremental optimizations. They signal a paradigm shift:

From: Monolithic models that recalculate everything each pass To: Hybrid compute-memory systems that think, remember, and reason

This mutation is directly inspired by cognitive science:

Working memory (MIRROR’s Cognitive Controller)
Typed long-term memory (episodic, semantic, procedural)
Information compression (Fact Cards)
Inner monologue (parallel reasoning threads)

Architectures like XMem and Memoria already reproduce human psychological effects: primacy, recency, and temporal contiguity effects.

The RAG vs Full-Context Debate

The Convomem benchmark revealed an important nuance: for the first 150 conversations, a full-context approach (providing all history) outperforms sophisticated RAG systems (70-82% accuracy vs 30-45%).

This suggests that conversational memory benefits from a “small corpus advantage” where exhaustive search is possible and preferable. Direct application of generalist RAG solutions isn’t always optimal.

The future will likely be hybrid:

Full context for short conversations
Typed memory + Fact Cards for long conversations
O(1) retrieval for static knowledge

Impact on Developers and Creators

For us developers and creators, these architectures redefine what we can expect from an LLM:

Today: “ChatGPT is an assistant that sometimes forgets and contradicts itself” Tomorrow: “My AI maintains a coherent mental model of my project over weeks”

Imagine:

A development agent that remembers your code conventions and architectural preferences over months
An e-commerce assistant that maintains a nuanced understanding of your business constraints and customers
A support system that never asks you the same information twice

These architectures aren’t just performance gains. They make AI truly usable for complex long-term tasks.

Conclusion: The Dawn of Truly Cognitive AI

For years, we’ve improved LLMs by making them bigger: more parameters, more data, more compute.

MIRROR and Engram show us another path: making AI smarter, not just bigger.

By giving them an inner monologue, working memory, and efficient lookup capability, we’re not just improving performance. We’re creating systems that can truly think and remember.

The question is no longer “What model size is necessary?” but “What cognitive architecture is optimal?”.

And you? How do you envision exploiting these architectures in your projects? An assistant that maintains coherent memory of your codebase? A support system that truly understands your users long-term? An agent that reasons before acting?

The future of AI is no longer measured in billions of parameters, but in depth of reflection.

More Than Prompts: 5 Revelations About Claude Skills That Will Change How You Work

Mon, 02 Feb 2026 00:00:00 +0000

If you regularly use an AI like Claude, you’re probably familiar with this frustration: having to re-explain the same context, the same rules, or the same workflows with every new conversation. It’s an exhausting cycle of copy-paste that not only wastes time but also exposes the systemic weaknesses of traditional prompting. As the conversation lengthens, initial instructions get buried in the mass of information, a phenomenon known as “context rot,” and results become increasingly less relevant.

To address this problem, Anthropic introduced “Claude Skills.” But this isn’t just a simple update. It’s a necessary architectural evolution, a fundamental solution that radically changes how we interact with AI. This article will reveal 5 impactful and often overlooked aspects of Skills that prove they are much more than simple “reusable instructions.”

Skills Aren’t Prompts, They’re Downloaded Kung-Fu

The first thing to understand is that a Skill is fundamentally different from a saved prompt. A prompt is a one-time instruction. A Skill is a coherent set of specialized knowledge, processes, and expertise that Claude can assimilate and use instantly, like an innate ability.

One user perfectly summarized this concept with a striking analogy:

Think of it like Neo’s “I know kung fu” moment in The Matrix. Just like they downloaded kung fu directly into Neo’s brain and he could use it instantly, you’re downloading specialized knowledge into Claude that it can apply automatically when needed.

This distinction is crucial. It means Claude doesn’t need manual triggering to use a Skill. The knowledge becomes an intrinsic competency, automatically activated as soon as your request’s context makes it relevant. Unlike a “Project’s” custom instructions that are only active in that workspace, a Skill becomes a universal capability, available in any conversation.

The Solution to Context Overload and Exorbitant Costs

One of the biggest technical challenges of large language models (LLMs) is managing the “context window.” When you provide a very long prompt, the model may ignore crucial instructions buried in the middle of the information, a problem known as “lost in the middle.” Moreover, every word (or “token”) has a cost, and loading thousands of tokens of instructions with each request quickly becomes prohibitively expensive.

Skills brilliantly solve this dual problem through the principle of progressive disclosure. The mechanism is remarkably effective:

At startup, Claude only scans the metadata (name and description) of each Skill, an operation that consumes only a handful of tokens.
Only when your request matches a Skill’s description does it load the complete instructions.

The impact is enormous: latency is reduced, the model stays focused on the immediate task, and most importantly, token savings can reach 60% to 90%, making large-scale AI usage economically viable.

The Hybrid Brain: When AI Reasoning Meets Code Precision

LLMs are probabilistic (“stochastic”) by nature. They excel at creativity and language understanding but can be unreliable for tasks requiring absolute precision, such as complex financial calculations or database migrations.

Skills introduce a “hybrid brain” model. A Skill can contain not only natural language instructions but also executable scripts (for example, in Python). This synergy is formidable: Claude handles qualitative reasoning (understanding user intent) while the script provides quantitative precision (deterministic execution that performs perfectly every time).

The open-source project superpowers is an excellent example. It contains a Skill that forces Claude to follow a rigorous development workflow, including writing tests before code (Test-Driven Development), thus guaranteeing software production quality impossible to achieve with AI reasoning alone.

The Metamorphosis: From Passive Assistant to Autonomous Agent

We’ve long thought of AIs as “assistants”: sophisticated auto-completion tools that help us type faster. Skills enable a transition to a much more powerful paradigm: that of the autonomous and proactive “agent.”

A Claude Code user eloquently described this shift:

I felt like Claude Code was like a developer living in my terminal who actually does the work while I supervise.

Skills are the mechanism that makes this autonomy possible. Where an assistant would suggest lines of code to add rate limiting to an API, an agent like Claude, equipped with the right Skills, can take over the entire process: it reads the codebase, implements the limiter, modifies the routes, writes and runs the tests, then drafts the commit message. The human is no longer the one doing, but the one supervising.

From Individual Tricks to Institutional Knowledge

Traditional prompts are often personal “tricks,” fragile and difficult to share or maintain. If their creator leaves the company, this know-how is usually lost.

Skills institutionalize this knowledge. Since they’re file-based (like SKILL.md), they can be stored, versioned, and managed in a version control system like Git. They become lasting assets for the organization:

They can be collaboratively reviewed (for example, a legal Skill validated by the legal department before being deployed company-wide).
They can be shared within teams to ensure consistency.
They can be updated and improved collectively.

This approach transforms “prompting,” often perceived as an obscure art, into a true engineering practice, structured and sustainable.

Welcome to the Era of Intelligence Orchestration

Claude Skills are not just a feature. They mark a fundamental paradigm shift, moving us from simple “prompt engineering” to true “context engineering” and “intelligence orchestration.” By transforming ephemeral instructions into executable capabilities, by moving from probabilistic reasoning to code precision, and by turning individual tricks into institutional knowledge, Skills don’t just improve our work: they re-architect it.

Now that your AI can learn, retain, and perfectly execute your most complex workflows, what’s the first expertise you’re going to “download” to it?

Global Strategic Analysis: Structural Tensions in the RAM and Storage Market in 2026

Thu, 29 Jan 2026 00:00:00 +0000

Global Strategic Analysis: Structural Tensions in the RAM and Storage Market in 2026

1. Introduction: The End of Traditional Cycles and the Advent of the AI-Centric Era

The year 2026 marks a fundamental break in the history of the semiconductor industry. Historically, the memory market — including DRAM (Dynamic Random Access Memory) and NAND Flash — was governed by predictable cycles of expansion and contraction (“boom-and-bust”), dictated by consumer electronics demand (PCs and smartphones). However, analysis of current data reveals that we have left this cyclical model to enter a period of sustainable structural shortage, orchestrated by a massive reallocation of industrial capacities towards artificial intelligence (AI).

This transformation is not a simple cyclical adjustment; it represents a paradigm shift where the “Data Gravity” of AI data centers exerts an irresistible force of attraction on global silicon production. The major memory manufacturers — Samsung Electronics, SK Hynix and Micron Technology — have deliberately pivoted their production lines. Instead of expanding conventional DRAM manufacturing, they now prioritize high bandwidth memory (HBM) and high-density DDR5, essential components for AI accelerators but whose production cannibalizes that intended for consumers.

This report proposes an exhaustive dissection of this multifaceted crisis. It explores not only the economic and technical mechanisms of this shortage, but also its geopolitical ramifications — illustrated by the Nexperia affair — and its concrete consequences for European businesses and consumers. In 2026, memory is no longer a commodity; it has become a critical strategic asset, whose scarcity is redrawing the maps of global technological power.

2. The Physics of Shortage: The HBM Equation and the Crowding-Out Effect

To understand the pressure on RAM prices in 2026, it is imperative to analyze the very architecture of semiconductor production. The current shortage does not result from a factory breakdown or natural disaster, but from a physical and economic constraint imposed by HBM (High Bandwidth Memory) technology.

2.1 Production Asymmetry: The 1 to 3 Ratio

The core of the problem lies in a brutal “capacity asymmetry”. The manufacturing of HBM modules, essential for Nvidia Blackwell and Rubin GPUs, is an extremely “wafer-intensive” process. Technical data indicates that for each bit of HBM produced, the industry sacrifices approximately three bits of conventional DRAM capacity.

This capacity loss is explained by several technical factors:

Die Size (Chips): HBM chips are physically larger than standard DDR chips to accommodate complex connection structures.
Packaging Complexity: Vertical stacking of memory chips and the use of thousands of vertical connection paths (Through-Silicon Vias or TSV) reduce yields. Each defective wafer or additional production step reduces the total volume of memory available for the market.
Line Prioritization: Faced with significantly higher profit margins on HBM (exceeding 50-60% for players like Micron), manufacturers allocate their best production lines and most advanced lithography equipment to AI, leaving older or less efficient technology nodes for consumer DRAM.

2.2 Hyperscale Demand Saturation

At the beginning of 2026, demand for HBM memory is beyond comprehension. Micron confirmed that its HBM production capacity for the entire calendar year 2026 is already sold (“sold out”). This saturation is not limited to a single player; SK Hynix and Samsung face similar order books, filled by the voracious needs of Nvidia, Google, AWS and Microsoft.

This dynamic creates a massive crowding-out effect. Manufacturers refuse to invest in new fabs dedicated exclusively to standard DRAM (“commodity DRAM”) for fear that the AI bubble will burst, which would leave them with costly overcapacities. This defensive strategy, described as “economic rationality” by IDC analysts, ensures that memory supply for PCs and smartphones will remain artificially low, causing structural and non-transitory price inflation.

2.3 Comparative Table: Evolution of Production Priorities

The table below illustrates the shift in production priorities between 2024 and 2026, highlighting the decline in market share allocated to consumer memory.

Memory Segment	Production Share (2024)	Production Share (2026 Est.)	2026 Price Trend	Key Factor
HBM (AI/Data Center)	< 5%	~15-20%	+20% (Contract)	Insatiable Nvidia/Hyperscalers demand
DDR5 (Server)	20%	35%	+40%	CPU server fleet renewal
DDR5 (PC Client)	30%	20%	+50-60%	Wafer reallocation to HBM
LPDDR5X (Mobile)	35%	25%	+25%	Direct competition with HBM lines
DDR4 (Legacy)	10%	< 5%	+70-100%	Accelerated obsolescence and end of life (EOL)

Source: Synthesis of IDC, TrendForce data and Micron financial reports.

3. The Technological Leap: From HBM4 to DDR6 and CAMM2

While the shortage rages, the industry does not slow down innovation. On the contrary, 2026 is the scene of a major technological acceleration, further widening the gap between cutting-edge products (reserved for AI) and consumer products.

3.1 The HBM4 Revolution: Fusion of Memory and Logic

The year 2026 marks the beginning of mass production of the sixth generation of high bandwidth memory, HBM4. Samsung and SK Hynix have accelerated their roadmaps to start production as early as February 2026, aligning with the launch of Nvidia’s “Rubin” GPU platform.

HBM4 introduces a major architectural breakthrough:

Expanded Interface: The memory bus increases from 1024 bits (HBM3e) to 2048 bits, doubling the data “highway” to achieve phenomenal bandwidth of 2.0 to 2.8 TB/s per stack.
The Logic “Base Die”: Unlike previous generations where the base layer was a simple memory chip, HBM4 uses a logic chip etched in 5nm or 4nm. This transforms memory into an active component, capable of performing certain calculations or managing data more intelligently.

This increased complexity divides manufacturer strategies:

SK Hynix has formed a “One-Team Alliance” with TSMC, using the latter’s foundry process for the logic layer, betting on TSMC’s excellence in fine etching.
Samsung plays the vertical integration card (“All-in-One”), using its own 4nm foundries to produce the logic layer and memory internally, hoping to reduce costs and logistics delays.

3.2 The DDR6 Horizon: Preparing for Post-2026

Although DDR5 is still in mass deployment phase, DDR6 specifications are finalized in 2026 by JEDEC, with mass production expected for 2027.

Dizzying Speeds: DDR6 will start with transfer rates of 8,800 MT/s to climb to 17,600 MT/s, doubling the theoretical performance of current DDR5.
Quad-Channel Architecture: DDR6 will adopt four 24-bit sub-channels per module (versus two 32-bit for DDR5), increasing parallelism and efficiency, particularly for AI workloads on client PCs.

3.3 The CAMM2 Format: The End of SO-DIMM

To accommodate these speeds, the physical format of memory modules is evolving. The CAMM2 (Compression Attached Memory Module) standard and its low-power LPCAMM2 variant emerge in 2026 as the solution to the physical limitations of traditional SO-DIMM slots.

Advantages: Thinner (60% space savings), denser (up to 64 GB and more per module), and offering superior signal integrity allowing higher speeds (Micron has already launched LPCAMM2 LPDDR5X modules at 8,533 MT/s).
Adoption: Initially reserved for high-end mobile workstations (Lenovo ThinkPad P1, Dell Precision), CAMM2 should become democratized on “AI” laptops in 2026, although its initial cost remains high (over $450 for 64 GB).

4. Market Analysis: The Economic Impact on Consumers and Businesses

The physical shortage of components translates into severe economic inflation that affects all sectors, from desktop PCs to smartphones, including enterprise servers.

4.1 The PC Market: Contraction and Inflation

The PC market finds itself in a “perfect storm”. The memory shortage collides with the forced renewal cycle due to the end of Windows 10 life and the marketing push for “AI PCs”.

Price Increases: Major OEMs like Dell, HP and Lenovo have warned their customers of price increases of 15 to 20% from the beginning of 2026. Memory, which represented 10-15% of the bill of materials (BOM) cost, now weighs 15-20%, or more.
Volume Contraction: IDC has drastically revised its forecasts downward. In a pessimistic scenario, the global PC market could contract by nearly 9% in 2026, contradicting hopes for a post-Covid recovery.
The AI PC Paradox: To be certified “Copilot+” or “AI PC”, a computer must have at least 16 GB of RAM, and ideally 32 GB. However, this is precisely the component that is becoming unaffordable. Manufacturers risk launching “AI” PCs at prohibitive prices, or compromising the user experience by undersizing memory.

4.2 The Crisis in Japan: A Warning for Europe

Japan often serves as the canary in the coal mine for the global technology market. In late 2025 and early 2026, the shortage has become tangible there.

Order Halt: Major build-to-order (BTO) PC retailers like Mouse Computer and Tsukumo had to completely suspend desktop PC orders for several weeks, unable to secure RAM and SSD stocks.
Rationing: Akihabara shops have imposed strict limits (e.g., two RAM sticks maximum per customer) to combat speculation and hoarding. This rationing phenomenon could extend to Europe if supply chains do not stabilize.

4.3 Smartphones: “Reverse Democratization”

The smartphone market is experiencing technical regression. The historical trend that saw specifications increase while prices decreased is reversed.

Frozen or Reduced Specifications: Analysts predict that 2026 flagship models will remain stuck at 12 GB of RAM (instead of moving to 16 GB), and that entry-level could regress to 4 GB to preserve margins.
Impact on Chinese Brands: Low-margin manufacturers like Xiaomi, Realme or Transsion are most exposed. Unlike Apple or Samsung which secure supply contracts over 12-24 months, these brands will have to fully pass on the cost increase (estimated at +25% for entry-level BOM) to consumers.

5. Geopolitics and Supply Chain Fracture: The Nexperia Affair

Beyond capacity constraints, 2026 is marked by a major geopolitical crisis that illustrates the fragility of global supply chains in the face of Sino-Western tensions.

5.1 The Seizure of Nexperia: Chronology of a Crisis

The Nexperia affair is the culmination of the tech war in 2025-2026.

The Trigger: In September 2025, the Dutch government, under American pressure and citing governance failures, used an emergency law (the Goods Availability Act of 1952) to seize effective control of Nexperia, a semiconductor manufacturer based in the Netherlands but owned by Chinese group Wingtech Technology.
Chinese Retaliation: In October, Beijing reacted by banning the export of chips produced or assembled in Nexperia’s Chinese factories. However, while wafers (raw silicon discs) are produced in Europe (Hamburg, Manchester), 70% of final assembly (packaging) is done in China, in Dongguan.
The Deadlock: This measure cut off the supply of “legacy” chips (MOSFETs, diodes), basic but essential components for power management.

5.2 The Devastating Impact on the European Automotive Industry

The European automotive industry’s dependence on these low-cost chips is total.

Production Halts: The absence of these components, which often cost less than a dollar, has forced major manufacturers (Volkswagen, Honda, and others) to halt electric vehicle production lines in 2026, unable to manage battery systems or LED headlights.
Return to Crisis Management: Automakers, who thought they had turned the page on the Covid crisis, find themselves managing day-to-day inventory, qualifying alternative suppliers in emergency, with delivery times stretching by several weeks.

5.3 American Export Licenses: A Sword of Damocles

In this tense context, the United States maintains constant but calibrated pressure. Washington has granted Samsung and SK Hynix annual export licenses for 2026 (replacing previous indefinite waivers). These licenses allow the two Korean giants to continue importing American equipment for their memory factories in China (which represent a significant share of global DRAM and NAND production).

Strategic Analysis: This shift to an annual regime places global memory supply under constant political threat. Each year, the survival of Samsung and SK Hynix’s Chinese factories will depend on the goodwill of the American administration, adding a structural risk premium to the memory market.

6. Strategies of Major Players: Who’s Winning the Memory War?

In this chaotic environment, the strategies of the main manufacturers diverge, creating clear winners and losers in 2026.

6.1 Micron Technology: The Pivot to Value

Micron appears as the big financial winner of this crisis.

Record Margins: By focusing on the American market and hyperscalers, Micron has seen its gross margins climb towards 60%. Its gradual withdrawal from the consumer market (reduction of offerings under the Crucial brand) confirms its willingness to favor profitability over volume.
HBM3e Leadership: Micron has managed to establish its “12-high” (12-layer) HBM3e modules as a standard for energy efficiency, winning critical market share with Nvidia.

6.2 Samsung Electronics: The Giant’s Awakening

After a difficult 2025 (delays on HBM3e), Samsung is going all-in on HBM4.

“All-in-One” Strategy: Samsung is the only player capable of offering a complete in-house solution: memory production, logic chip manufacturing in 4nm, and advanced 2.5D packaging. This vertical integration is its main argument to reconquer Nvidia and other major customers.
Massive Expansion: The company plans to increase its HBM capacity by more than 50% in 2026, targeting production of 250,000 wafers per month, potentially surpassing SK Hynix in pure volume.

6.3 SK Hynix: The Strategic Alliance

SK Hynix defends its position as current leader (approximately 60% HBM market share in early 2026).

TSMC Partnership: Rather than doing everything alone, SK Hynix relies on TSMC for manufacturing HBM4 logic layers. This “Best-of-Breed” alliance aims to offer the best possible technical performance, even if it is logistically more complex.
Tactical Slowdown: SK Hynix has slightly delayed the maximum ramp-up of HBM4 to the third quarter of 2026, probably to ensure that yields and quality are impeccable in the face of Samsung’s counter-attack.

6.4 CXMT: The Chinese Wildcard

ChangXin Memory Technologies (CXMT) attempts to play a stabilizing role for the entry-level market.

Massive IPO: With an initial public offering aiming to raise $4.2 billion, CXMT is investing massively to increase its conventional DRAM production capacity.
Limitations: Although CXMT can flood the Chinese market with standard DDR4 and DDR5 (partially alleviating the local shortage), technological sanctions prevent it from competing in the HBM or high-performance DDR5 segment, limiting its impact on the overall global crisis.

7. Perspectives and Risks for Digital Infrastructure

The memory crisis goes beyond the simple framework of computer hardware; it now threatens the very stability of global digital infrastructure.

7.1 The Fragile Cloud: Outages and Delays

Cloud providers (Hyperscalers) like Microsoft Azure, AWS and Google Cloud are not immune.

Server Shortage: The difficulty in obtaining enough server memory delays the deployment of new classic (non-AI) instances in data centers. Microsoft has already had to restrict access to certain Azure regions due to these constraints.
Major Outage Risk: Forrester predicts at least two major public cloud outages in 2026. The cause? The diversion of resources (financial and human) towards AI infrastructure at the expense of maintaining and upgrading vital “legacy” infrastructures.

7.2 The Graphics Sector (GPU): GDDR7 Shortage

Nvidia, although a major beneficiary of the AI boom, must manage component shortages for its consumer graphics cards.

Production Cuts: Reports indicate that Nvidia plans to reduce production of its GeForce RTX 50 series GPUs by 30 to 40% in early 2026. The main reason is the shortage of GDDR7 video memory, whose production lines are in direct competition with those of HBM.
Consequence: Gamers should expect limited availability and high prices for next-generation graphics cards, extending the lifespan of current cards.

8. Conclusion

The year 2026 will be remembered as the year when RAM ceased to be a commodity to become a critical resource, on par with energy or rare earths. The convergence of a technological breakthrough (generative AI requiring HBM), brutal industrial reallocation and major geopolitical tensions (Nexperia) has created a structural shortage that usual market mechanisms cannot resolve in the short term.

For European companies, the lesson is clear: securing stocks and diversifying suppliers are no longer options, but survival imperatives. For consumers, technological inflation is the new norm. Resolution of this crisis will only come with the commissioning of massive new production capacities on the horizon of 2027-2028, or, a scenario more feared by the industry, by the brutal bursting of the AI investment bubble. Until then, the world will have to learn to function with a digital resource that has become rare and precious.

Article based on technological and geopolitical market analysis as of January 2, 2026. Data comes from multiple industry sources including IDC, TrendForce and financial reports from major semiconductor manufacturers.

The End of the Lone Coder: Why Future Developers Will Be AI Orchestrators (and how to get started with PrestaShop)

Tue, 27 Jan 2026 00:00:00 +0000

Today, we’re going to be blunt. We hear everything and its opposite about AI: “It will replace devs”, “It’s just a fad”, “You need to bet everything on GPT-5”.

If you’ve been following me a bit, you know I’m a pragmatist. I’m not interested in AI for writing poems, but for optimizing, selling and building. And I have a deep conviction, supported by what’s currently happening in research and industry:

The era of the “Leviathan” (one giant AI that does everything) is an illusion.

The future of e-commerce and PrestaShop development will not be played with a single omniscient digital brain, but with a team of specialized experts. And your new job? It will no longer be just about writing code, but about becoming the Conductor of this team.

Buckle up, we’re going to talk about modular architecture, carbon footprint, latency and above all, how to transform your PrestaShop store into a war machine thanks to AI Agents. 🚀

1. The Myth of the “Swiss Army Knife” AI (and why it doesn’t work in e-commerce)

We’ve all been amazed by ChatGPT. You ask it for a pancake recipe, it gives it to you. You ask it for PHP code, it does it (almost) well. So, the natural reflex is to say: “Great, I’m going to plug this thing into my PrestaShop and it will handle support, inventory, SEO and accounting!”

🛑 Stop. This is a major architectural error.

Why? For a simple reason that mathematicians call the “No Free Lunch” theorem. In short: you can’t be excellent everywhere.

The “Generalist” Problem

Imagine you hire one person to manage your store. They must be an expert in tax law, logistics, Symfony development, persuasive copywriting and customer psychology. It’s impossible. At best, they’ll be “average” everywhere.

A generalist AI (like the giant GPT-5 or Claude 3 Opus models), it’s the same:

It’s slow (Latency): To answer a simple question like “Do you have this T-shirt in red?”, a giant model mobilizes phenomenal computing power. In e-commerce, 100ms of latency is 1% less conversion. Don’t use a bazooka to kill a fly.

It’s expensive and polluting: Each query on a giant model consumes as much energy as a Google search x10. At the scale of a Black Friday, it’s an ecological and financial disaster.

It hallucinates: A model trained on all of the internet might invent promo codes that don’t exist or promise Sunday delivery.

In e-commerce, we don’t want “poetry”. We want precision. We want math. We want binary.

2. The Era of “Specialist Agents”: The Return to Modularity

This is where it gets exciting for us, the PrestaShop community. Our favorite CMS has always been right on one point: modularity.

PrestaShop works with Hooks and Modules. You don’t modify the Core to add a payment method. You graft an expert module.

AI is taking exactly the same path. We’re moving away from big monolithic models towards SLM (Small Language Models) and MoE (Mixture of Experts) architectures.

Concretely, what is it?

Instead of having an “AI God”, you’re going to have a constellation of very fast small agents, hosted locally or at lower cost, that only know how to do one thing, but do it perfectly.

🕵️ The Fraud Agent: It can’t write a poem, but it analyzes thousands of transactions (IP, velocity, average cart) to say “Validated” or “Rejected” in 50 milliseconds.

📦 The Logistics Agent: It knows your carrier’s API and your SQL stock status by heart. It answers factually: “Package shipped, delivery scheduled for Tuesday.”

🎨 The Merchandising Agent: It analyzes vectors (embeddings) of your products to suggest the right accessory.

This is called an agentic architecture. And guess what? It’s much more robust, secure and fast.

3. Concrete Application: How to Build This Today?

Enough theory. How do you set this up when you’re a dev or e-merchant on PrestaShop? The keystone of this new architecture is a concept that’s exploding: MCP (Model Context Protocol).

Think of MCP as a “universal USB plug” for AI. It allows an AI (Claude, ChatGPT, or a local agent) to connect to your tools in a standardized and secure way.

This is precisely to fill this gap that MCP Tools Plus was developed by BusinessTech & PrestaModule.

The idea is simple: transform your PrestaShop store into a real MCP Server. Instead of cobbling together Python scripts everywhere, you install the module, and boom: your store natively exposes its data and actions to your AI agents, in a controlled manner.

Scenario: “Augmented” Customer Support with MCP Tools Plus 🤖

Forget the chatbot that says anything. Here’s the workflow of a modern agentic system that you can prototype right now:

1. The Router (The dispatcher)

The customer sends a message: “Where is my order #12345?”. Your AI assistant (connected via MCP) analyzes the intent.

Verdict: It’s an “Order status” request.

Action: I use the get_order_status tool provided by the PrestaShop MCP server.

2. The Logistics Agent (The expert)

This is where the magic of MCP Tools Plus operates. The agent doesn’t try to guess. It executes the secure function exposed by the module.

It queries your PrestaShop in real time via the protocol.
PrestaShop responds (reliable data from the DB): Status: Shipped, Tracking: 1Z999...

3. The Response (The writer)

The agent takes this raw data and uses a lightweight language model to formulate an empathetic response: “Hello! Good news, your order #12345 is on its way…”

Result:

✅ 0 Hallucination: The AI didn’t invent the status, it read it via the MCP connector.

✅ Security: The agent only has access to the tools you’ve activated in the module. If the AI gets hacked (prompt injection), it can only do what the module authorizes.

✅ Simplicity: No need to code a complex API, the module does the bridging.

4. Vision: Become a Systems Architect

This is where your role changes.

Before, we were paid to write the get_order_status function. Today, AI can write this function in 2 seconds.

Tomorrow, we’ll be paid to design the system where Agent A talks to Agent B without breaking the store.

The key skills of the “E-commerce Developer 2026”:

1. Orchestration (Flow Engineering): Knowing how to design data flows between agents. Using tools like LangChain, n8n or MCP servers.

2. Hybridization: Knowing when to use AI (for fuzzy things, language) and when to use classic code (for math, strict logic). Reminder: Never ask an AI to calculate VAT, it’s a heresy! Make it call a calculator.

3. Data Sovereignty: Knowing how to deploy small models (like Mistral or Llama) directly on your servers. Why? To avoid sending your customers’ data to OpenAI. It’s a massive selling point for GDPR and confidentiality.

The Future Impact

This approach will democratize luxury features. Before, you had to be Amazon to have real-time fraud detection or intelligent 24/7 customer support. With tools like MCP Tools Plus and specialized agents, any PrestaShop store can offer this level of service.

But beware: this requires rigor. A poorly designed automated system can destroy a reputation in minutes. That’s why the human remains at the center, no longer as an executor, but as a supervisor.

Conclusion: Get on the Train Now 🚂

AI is not a magic wand that replaces everything. It’s a technological building block, just like PHP or SQL.

Those who try to solve everything with a “big prompt” in ChatGPT will fail (slow, expensive, imprecise).
Those who will succeed are those who will build modular systems, faithful to PrestaShop’s DNA: one module for each task, one expert for each problem.

My advice for this week?

Take a look at MCP Tools Plus and try to connect your first agent to your store. Start small: a simple agent capable of reading your stock. You’ll see, once you’ve tasted agentic architecture, there’s no going back.

This is the time to move from “AI user” to “AI architect”. And believe me, it’s a lot more fun!

Understanding the Shai-Hulud Malware Worm: When npm install Becomes a Backdoor

Sun, 25 Jan 2026 00:00:00 +0000

Introduction: Welcome to the Era of Supply Chain Attacks

In Frank Herbert’s universe, Shai-Hulud is the name given to the giant sandworms of planet Arrakis, legendary creatures that devour everything in their path. In 2025, this name took on a disturbing new meaning in the world of cybersecurity: that of a sophisticated malicious worm that devours not sand, but sensitive data in the JavaScript ecosystem.

The Shai-Hulud worm represents an alarming evolution of software supply chain attacks. Its diabolical genius? Transforming the npm install command, a daily and trusted gesture for millions of developers, into a direct gateway for malicious code execution. Between September and November 2025, this malware infected over 700 npm packages, compromised 27,000+ GitHub repositories, and exposed approximately 14,000 secrets across 487 organizations.

This technical article details how Shai-Hulud operates, analyzes its evolution from V1 to V2, and explains why every JavaScript developer must understand this threat to protect their projects and organization.

1. What is the Shai-Hulud Worm?

1.1 Definition and Objectives

Shai-Hulud is a sophisticated software supply chain attack that specifically targets the JavaScript ecosystem via the npm package registry. Its primary objectives are multiple:

High-value credential theft: npm tokens, GitHub Personal Access Tokens (PAT), AWS/GCP/Azure keys
Private source code exfiltration: access to private repositories for intellectual property theft
Establishing persistence: installing backdoors for long-term control
Exponential propagation: self-replication across the npm ecosystem

The name “Shai-Hulud” comes from a GitHub repository used by the attackers, a direct reference to the Dune universe that perfectly illustrates the devastating and omnipresent nature of this threat.

1.2 The Attack Vector: npm install as RCE

The danger of Shai-Hulud lies in its exploitation of a legitimate npm feature: lifecycle scripts. These scripts (preinstall, postinstall, preuninstall, etc.) execute automatically during package installation, without user interaction and with the privileges of the user running the command.

This characteristic transforms npm install into an indirect but powerful Remote Code Execution (RCE) vector. Unlike a classic software vulnerability that requires an exploit, here the package manager itself voluntarily executes the malicious code.

2. The Infection Chain: Anatomy of a 4-Step Attack

The Shai-Hulud worm follows a clear and automated process to infect systems and propagate through the ecosystem. Understanding this infection chain is essential to identify defense points.

2.1 Step 1: The Hook - npm Account Compromise

The attack begins when an attacker compromises a legitimate developer’s npm account. This compromise can occur via:

Credential stuffing: use of reused passwords
Phishing: fraudulent emails targeting popular package maintainers
Development machine exploitation: theft of tokens stored locally in ~/.npmrc
CI/CD compromise: access to pipelines containing npm tokens

Once access is obtained, the attacker can publish modified versions of legitimate packages on the public npm registry.

2.2 Step 2: The Trigger - Automatic Installation

When a developer or build system installs the infected package (directly or as a transitive dependency), the malicious script executes automatically.

Shai-Hulud V1 used a postinstall script (executed after package installation):

{
  "scripts": {
    "postinstall": "node malicious.js"
  }
}

Shai-Hulud V2 evolved to preinstall (executed before installation even completes), making detection more difficult since execution occurs even if installation subsequently fails:

{
  "scripts": {
    "preinstall": "bun run malicious.ts"
  }
}

The use of Bun (a JavaScript runtime alternative to Node.js) in V2 was a deliberate attempt to bypass security tools configured specifically to detect suspicious Node.js behaviors.

2.3 Step 3: The Theft - Secret Harvesting

Once executed, the malicious script launches a sophisticated reconnaissance and exfiltration operation. It uses tools like TruffleHog (an open-source secret scanner ironically repurposed for malicious purposes) to scan the system for sensitive data.

Priority targets:

Configuration files
- ~/.npmrc (npm tokens)
- ~/.gitconfig (Git configuration)
- ~/.aws/credentials (AWS keys)
- ~/.ssh/ (private SSH keys)
- .env (environment variables)
Environment variables
- NPM_TOKEN, GITHUB_TOKEN, AWS_ACCESS_KEY_ID
- All variables containing “KEY”, “SECRET”, “TOKEN”, “PASSWORD”
Local Git repositories
- Git history scanned for hardcoded secrets
- In V1, some private repositories were made public to facilitate exfiltration

Exfiltration methods:

V1: External webhook (easily detectable and blockable)
V2: Use of GitHub API to disguise malicious traffic as legitimate activity (“cross-victim exfiltration”)

2.4 Step 4: Propagation - Exponential Self-Replication

The self-replication capability of Shai-Hulud is what distinguishes it from a simple data theft malware. Once it has stolen a valid npm token, the worm:

Queries the npm registry to identify all packages maintained by the compromised account
Clones each package locally
Injects the malicious payload into each package
Increments the version (e.g., 1.0.2 → 1.0.3) to avoid conflicts
Automatically publishes the infected versions on npm

This process creates an exponential chain reaction: each infected developer becomes a new attack vector, propagating the malware to their own packages, which in turn infect their users.

Propagation impact:

~200 infected packages in V1 (September 2025)
700+ infected packages in V2 (November 2025)
27,000+ compromised GitHub repositories
~14,000 exposed secrets across 487 organizations

3. Why is Shai-Hulud So Dangerous?

3.1 Theft of “Keys to the Kingdom”

The tokens and keys stolen by Shai-Hulud are not simple passwords. They are programmatic access keys that grant direct control over:

Cloud infrastructures: ability to deploy AWS/GCP/Azure resources at the victim’s expense
Private source code: access to private GitHub repositories containing intellectual property
CI/CD pipelines: capability to inject malicious code into production builds
Package registries: publishing malicious versions of legitimate packages

A single compromised token can grant access to dozens of critical systems.

3.2 Chain Propagation and Network Effect

The self-replicating nature of Shai-Hulud exploits the network effect of the npm ecosystem:

npm has over 2.5 million packages
Each package has on average 10+ dependencies
A single popular package can have millions of downloads per week

This interconnection means that a single compromised package can reach thousands of projects within hours, and tens of thousands within days.

3.3 Persistence via GitHub Actions Backdoor

Shai-Hulud V2 introduced a sophisticated persistence technique that survives even system disinfection:

Registration of a self-hosted GitHub Actions runner
- Runner name: SHA1HULUD
- Runs as a system service
- Survives reboots
Injection of a malicious workflow
- File: .github/workflows/discussion.yaml
- Triggered by GitHub events (issues, discussions)
- Allows remote arbitrary command execution
Bidirectional communication
- Attackers can send commands via GitHub API
- The runner executes these commands and returns results
- All traffic appears as legitimate GitHub activity

This approach transforms the compromised machine into a permanent zombie under attacker control, even after removal of the malicious package.

3.4 The Dead Man’s Switch

The most disturbing feature of Shai-Hulud V2 is its destructive retaliation mechanism. If the malware fails to authenticate with GitHub or npm (indicating possible detection and token revocation), it activates a self-destruction process:

On Linux/macOS:

find ~ -type f -exec shred -vfz -n 10 {} \;

On Windows:

cipher /w:%USERPROFILE%

These commands perform irreversible erasure of the user’s home directory:

shred overwrites files 10 times with random data
cipher /w performs secure erasure of free space

Consequences:

Total loss of unsaved data
Destruction of local source code
Erasure of configuration files
Impossibility of forensic recovery

This mechanism transforms simple detection into an existential risk for user data, potentially deterring cleanup attempts.

4. The Evolution of the Threat: V1 vs V2

Shai-Hulud V2, detected in November 2025, demonstrates significant tactical evolution. Comparative analysis reveals that attackers methodically corrected V1 weaknesses to create a more stealthy, more destructive, and harder-to-eradicate malware.

4.1 Capability Comparison Table

Capability	Shai-Hulud V1 (Sept. 2025)	Shai-Hulud V2 (Nov. 2025)
Trigger	`postinstall` (after installation)	`preinstall` (before installation, even if it fails)
Runtime	Node.js (standard)	Bun (less common, detection bypass)
Exfiltration method	External webhook (easily blocked)	GitHub API (legitimate traffic)
Exfiltration strategy	On victim’s account	Cross-victim (A’s data on B’s account)
Persistence	None	GitHub Actions backdoor (self-hosted runner)
Failure behavior	None	Dead Man’s Switch (data erasure)
Scale	~200 npm packages	700+ npm packages
GitHub impact	Make private repos public	27,000+ compromised repositories
Exposed secrets	Not quantified	~14,000 secrets across 487 organizations
Detection	Relatively simple (suspicious webhook)	Complex (legitimate GitHub traffic)

4.2 Analysis of Tactical Improvements

4.2.1 From postinstall to preinstall

The shift from postinstall to preinstall has several advantages for the attacker:

Earlier execution: code runs before installation is even complete
Survival on failure: even if installation fails (missing dependency, conflict), the malware has already executed
Reduced detection window: less time for security tools to analyze the package before execution

4.2.2 From Node.js to Bun

Using Bun as runtime is a sandbox evasion technique:

Most npm security tools (Socket.dev, Snyk, etc.) are calibrated to monitor Node.js processes
Bun, being a newer and less widespread runtime, isn’t always covered by detection rules
Suspicious behaviors under Bun may go unnoticed while they would have been flagged under Node.js

4.2.3 Cross-Victim Exfiltration

Cross-victim exfiltration is a sophisticated anti-forensic technique:

Traditional scheme (V1):

Victim A → [Stolen secrets] → GitHub account of A → Attacker

→ Direct trace: A’s secrets appear on A’s account

Cross-victim scheme (V2):

Victim A → [Stolen secrets] → GitHub account of B → Attacker
Victim B → [Stolen secrets] → GitHub account of C → Attacker

→ Trail obfuscation: A’s secrets appear on B’s account, making investigation more complex

This technique breaks the traceability chain and considerably complicates attribution and remediation.

5. Key Concepts for Developers to Remember

5.1 npm install is a Code Execution Command

Fundamental principle: npm install doesn’t just download files, it executes code on your machine with your privileges.

Practical implications:

Treat npm install with the same caution as curl | bash
Never run npm install as root/admin
Verify packages before installation (maintainer history, recent activity, unusual size)
Use isolated environments (containers, VMs) to test new packages

Security checklist before npm install:

# 1. Check package reputation
npm info <package-name>

# 2. Examine package.json content (especially scripts)
npm view <package-name> scripts

# 3. Check dependencies
npm view <package-name> dependencies

# 4. Search for security reports
npm audit

5.2 Tokens are Very High-Value Targets

Reality: A compromised npm or GitHub token is potentially worth millions of dollars to an attacker.

Why?

Access to production infrastructure
Ability to publish backdoors in popular packages
Intellectual property theft
Use for large-scale supply chain attacks

Token management best practices:

Principle of least privilege
- Create tokens with minimal required permissions
- Separate tokens for npm, GitHub, cloud providers
- Time-limited tokens (automatic expiration)
Regular rotation
- Monthly rotation of production tokens
- Immediate rotation on suspicion of compromise
Secure storage
- Never plaintext tokens in source code
- Use secret managers (Vault, AWS Secrets Manager)
- Environment variables for local environments
Monitoring
- Token usage logs (who, when, from where)
- Alerts on unusual usage (abnormal geolocation, high volume)

5.3 Supply Chain Security is Everyone’s Responsibility

Myth to deconstruct: “I’m a junior, security is for seniors/DevOps.”

Reality: Every developer is a link in the security chain. A single mistake (installing a malicious package, committing a token) can compromise the entire organization.

Concrete actions for all developers:

Basic hygiene
- Enable 2FA on npm, GitHub, and all critical services
- Never commit secrets (use .gitignore, git-secrets)
- Keep dependencies up to date (security patches)
Vigilance
- Be suspicious of packages with few downloads or unknown maintainer
- Check maintainer changes on established packages
- Report any suspicious behavior (package requesting unusual permissions)
Security tools
- Use npm audit regularly
- Integrate Socket.dev or Snyk into workflow
- Configure Dependabot/Renovate for automatic updates
Security culture
- Share security alerts with the team
- Participate in awareness training
- Contribute to internal best practices documentation

Conclusion: Security in the Age of Self-Replication

The Shai-Hulud worm marks a turning point in the history of supply chain threats. It is not simply a sophisticated malware; it’s a demonstration of the fundamental fragility of our modern development ecosystem. The implicit trust we place in npm install and the thousands of dependencies we import daily is now an exploitable attack surface at scale.

Lessons from Shai-Hulud:

Automatic code execution is an existential risk: npm lifecycle scripts are a legitimate feature turned weapon of mass destruction. The ecosystem must rethink this model.
Self-replication changes the game: Malware that automatically propagates through dependencies reaches a speed and scale that exceeds human response capabilities.
Persistence redefines remediation: Cleaning a malicious package is no longer enough if a GitHub Actions backdoor survives on the system.
Destructive retaliation deters investigation: The “dead man’s switch” introduces an ethical and operational dilemma for security teams.

Future perspectives:

The industry is responding with initiatives such as:

npm provenance: cryptographic attestation of package origin
Socket.dev: real-time behavioral analysis of packages
GitHub Actions hardening: restrictions on self-hosted runners
AI Act (EU): traceability obligations for critical systems

But the ultimate solution lies in education and collective vigilance. Every developer who understands Shai-Hulud becomes a human detector, capable of spotting weak signals of a compromise before it transforms into catastrophe.

The question is no longer “if” but “when” the next variant of Shai-Hulud will emerge. Our collective ability to detect, analyze, and respond to these threats will determine the resilience of the open-source ecosystem for years to come.

Resources for further reading:

Socket.dev Blog: Detailed technical analyses of Shai-Hulud V1 and V2 campaigns
npm Security Best Practices: Official npm guide to secure your workflow
OWASP Top 10 CI/CD Security Risks: Specific risks to CI/CD pipelines
TruffleHog Documentation: Understanding secret detection tools (and how they’re repurposed)

AI Q1 2026: Towards the Era of Industrialization and Autonomous Agents

Thu, 22 Jan 2026 00:00:00 +0000

📰 The AI Landscape at the Dawn of 2026

After a 2025 marked by the release of foundational models like GPT-5 and Gemini 3.0, the first quarter of 2026 appears less as a race for raw power and more as a crucial phase of consolidation and integration. Major players are pivoting towards ecosystems capable of acting, not just generating.

Here’s the state of play for Q1:

OpenAI: The Rise of Agents

Building on the deployment of GPT-5.1 last November, OpenAI is orienting its Q1 roadmap towards pure utility.

Focus: Deployment of autonomous agents capable of orchestrating tools (calendar, payments, business systems).
Expected innovations: Cross-session persistent memory (finally native) and direct commercial integrations to facilitate transactions.
Strategy: Less “wow effect”, more reliability for enterprises.

Google: Silent Integration

Google continues its continuous deployment strategy. Gemini 3.0 (deployed under the 2.5 label at the end of 2025) is operational.

Q1 2026: Likely arrival of Gemini 3.5 or an ultra-optimized Flash version to reduce inference costs.
Ecosystem: Focus on deep integration into Workspace and Android, as well as the introduction of advertising in generated responses.

Anthropic: Reliability First

With Claude 4 (Opus and Sonnet) already well-established since May 2025, Anthropic aims for operational excellence.

Roadmap: Introduction of native “Voice” and especially multi-agent coordination.
Target: Companies seeking specialized agents (customer service, research) capable of collaborating with shared memory and autonomous conflict resolution.

Mistral AI: Sovereign Power

Mistral made a strong impact in December 2025 with Mistral Large 3 and its suite of dense models (Ministral).

Performance: Large 3 now ranks #2 globally among “non-reasoning” models, surpassing DeepSeek.
Q1 2026: Launch of a “Reasoning” version for Large 3 and especially a massive wave of integrations (Make, n8n, SAP, Stripe).
Infrastructure: Confirmation of work on the European AI Campus (1.4 GW) for total infrastructure sovereignty by 2028.

🔍 Analysis and Context: The End of Experimentation

Why this transition now? We’re moving from the discovery phase into industrialization (LLMOps).

1. From Chatbots to Agents

The major trend this quarter is the shift from “Discussion” mode to “Action” mode. Models are no longer content to respond; they must execute complex workflows. For a developer, this means that the key skill is no longer prompt engineering, but agent orchestration.

2. The Battle for ROI and Regulation

Enterprise budgets are tightening. The time for fun POCs (Proof of Concept) is over; it’s now about measurable ROI. With the gradual implementation of the EU AI Act, traceability and explainability are becoming purchase criteria as important as model performance. This is where Mistral, with its Open Source approach (Apache 2.0) and sovereignty, plays a trump card against American black boxes.

3. Multimodality as Standard

Text, image, audio, video: pipelines are now unified. The ability to natively process video to extract structured data or code is becoming a commodity, opening the door to unprecedented e-commerce use cases (automatic product catalog analysis, technical sheet generation from supplier videos).

🎯 Practical Implications for E-commerce

For the PrestaShop ecosystem and merchants, these Q1 2026 developments open three immediate windows of opportunity:

Agentic Customer Service

With persistent memory capabilities (OpenAI) and multi-agent coordination (Anthropic), we can now deploy customer support that “remembers” a buyer’s history over several months, without hallucinating, and capable of triggering refunds or returns autonomously via API.

Business Automation via Mistral

The announced integrations of Mistral with tools like n8n, Make, or Zapier are a powerful lever.

Use case: A Mistral agent connected to your PrestaShop Back-Office that monitors inventory, drafts supplier orders, and prepares segmented newsletters based on arrivals, all hosted in Europe for GDPR compliance.

RAG 2.0 (Retrieval-Augmented Generation)

Improvements in contexts and “reasoning” enable the implementation of Graphical RAG systems. Instead of simply searching for keywords in your documentation, the AI understands relationships between your products (compatible accessories, collections). This allows creating shopping assistants on the storefront with formidable precision for cross-selling.

🌐 Perspectives

Q1 2026 is not the quarter of a disruptive technological revolution, but one of maturity. The technology is there; the challenge now lies in integration, security, and creating real added value.

For us developers and architects, it’s time to consolidate our infrastructures: move from isolated scripts to robust agentic architectures, and favor models whose lifecycle we control, like those offered by Mistral. AI doesn’t replace the profession; it becomes the nervous system that connects tools together.

📚 Useful Resources

Comparing AI Development Methodologies: BMAD vs. Ralph

Wed, 21 Jan 2026 00:00:00 +0000