🎁 Perplexity PRO offert

30 jours gratuits

Téléchargez Comet, connectez votre compte et posez votre première question.

Activer l'offre →

Code Rigor vs AI Chaos: Should We Reinvent PHP Standards for PrestaShop Merchants?

Let’s not kid ourselves, modern PHP development has become an art form.

If you’re like me, you’ve spent the last ten years celebrating the rise of our favorite language. With PHP 7, then PHP 8, we finally got the tools to compete on equal footing with Java or C#. We adopted strict typing (declare(strict_types=1)), we built hexagonal architectures, we sanctified Value Objects and banished “fuzzy” data.

We built fortresses. And it was necessary for the stability of our PrestaShop stores.

But here’s the thing… Artificial Intelligence entered the room. 🤖

And AI, by nature, is a turbulent guest. It doesn’t respect our strict types. It’s probabilistic, creative, and sometimes, frankly messy.

Recently, I dropped a small bombshell on LinkedIn by suggesting that “Loose Typing” (weak typing) in PHP, often criticized, could be our best ally against LLM uncertainty. An idea that sparked reactions (rightfully so!) from a colleague, who perfectly summarized the “purist” mindset:

“I’d rather question ≈10 years of PHP improvements […] than write Value Objects and DTOs that would properly handle casting.”

His remark is excellent. It raises the real question that drives us today: Should we sacrifice the rigor of our software engineering to satisfy AI’s whims and merchants’ automation needs?

Spoiler: The answer isn’t binary. It’s a third way.

Part 1: The Culture Clash (Engineer vs Robot)

To understand the current friction, we need to look at where we came from.

In the PrestaShop ecosystem, stability is key. A type error on a price, and the average cart value collapses or an order goes through at €0. That’s why we, collectively, hardened our code. We want predictability. If a function expects a float, it must reject a string. It’s healthy. It’s clean.

But the LLM doesn’t care.

When you connect an AI agent (via n8n, Make, or a custom module) to automate product sheet creation, you’re not talking to a structured database. You’re talking to a language model.

If you ask the AI for a shipping weight, it might respond:

0.5 (Perfect) “0.5” (String, acceptable) “0.5 kg” (Ouch) “approximately 500 grams” (Disaster)

The problem: If your code is a rigid fortress that throws a TypeError at the slightest misplaced comma, your automation fails.

For the developer, the exception is a safety net. For the PrestaShop merchant, the exception is lost productivity.

The merchant doesn’t care if your DTO is pure. They want their 10,000 product descriptions generated and imported while they sleep. If the AI sends “10 euros” instead of 10.0, they don’t want the script to crash. They want the system to “understand.”

Part 2: The Return of “Diplomatic PHP”

This is where my theory of Diplomatic PHP comes into play. And this is where we need to nuance our “best practices.”

PHP has a historical superpower that other strict languages secretly envy: Type Coercion. This ability to say: “Okay, you gave me the string ‘15.5’, I’ll make the effort to treat it as the number 15.5 so the calculation works.”

For 10 years, we’ve been taught to hate this feature because it hid bugs. But in an AI-driven world, it becomes an ingestion asset.

It’s not about regressing, but about cushioning.

I’m not saying we should remove strict types from our Domain Cores. Absolutely not! Our tax calculations, our stock management in PrestaShop must remain absolutely rigorous.

However, we need to build a new layer, a “Decompression Chamber.”

Imagine your application as a fortified castle:

The Throne Room (The Core): Here, everything is strict. We speak in Value Objects, in strong types. We don’t mess around with data.

The Drawbridge (The Input Layer / AI): This is where AI arrives with muddy boots. If we keep the drawbridge closed (Strict Types), nothing gets in.

The solution isn’t to open the drawbridge and let mud into the throne room (what Francescu feared). The solution is to create a chamber where we use PHP’s flexibility to clean the boots before entering.

Part 3: Concrete Application (The “Fuzzy DTO”)

How does this translate into code for a modern PrestaShop module?

Instead of feeding AI data directly into a strict ProductPriceVO, we’ll go through an intermediary I call the Fuzzy DTO (Fuzzy Data Transfer Object).

The classic failing scenario

AI generates JSON for a product.

{ “price”: “19.90 €”, “stock”: “in stock (50)” }

If you map this directly into PrestaShop with strict typing… Fatal Error. The merchant calls you, furious.

The “Orchestrator” approach

We’ll use PHP’s flexibility at the input to “massage” the data.

// This isn’t “dirty code”, it’s “resilience by design”

class AiProductInput { // We deliberately accept ‘mixed’ or ‘string’ because AI is unpredictable public function __construct( public string|int|float $rawPrice, public mixed $rawStock ) {}

// The "Diplomatic" method that transforms chaos into order
public function toStrictDTO(): ProductDTO {
    // PHP helps us clean without immediately crashing
    $sanitizedPrice = (float) str_replace([',', ' €', ' EUR'], ['.', '', ''], $this->rawPrice);

    $sanitizedStock = (int) filter_var($this->rawStock, FILTER_SANITIZE_NUMBER_INT);

    // NOW, we can safely instantiate our strict object
    return new ProductDTO($sanitizedPrice, $sanitizedStock);
} }

See the nuance?

We’re not sacrificing the quality of the final model (ProductDTO remains strict). But we accept that the input interface (the contact point with AI) must be tolerant.

That’s what responding to the merchant’s need means. It’s creating a system that doesn’t crash at ChatGPT’s first minor hallucination, but silently corrects it so business keeps running.

Part 4: Vision & Future (From Developer to Flow Architect)

This discussion goes far beyond declare(strict_types=1). It touches the very evolution of our profession.

Automation and generative AI (GenAI) are transforming the PrestaShop developer. We’re no longer just code writers validating forms. We’re becoming Flow Orchestrators.

Tomorrow’s developer (and today’s, really) is one who knows how to combine:

Technical robustness (so the store doesn’t break). Operational agility (so AI can work).

We’ll need to learn to “let go” of certain dogmas at our application boundaries. Accept that incoming data is dirty, and build the most robust washing machines (intelligent parsers) possible.

AI won’t replace the need for rigor. On the contrary, it makes rigor even more precious, but it shifts it. Rigor should no longer be an entry barrier (“You don’t have the right format, you can’t enter”), but a transformation process (“You don’t have the right format, I’ll help you become it”).

That’s the whole difference between a fragile system and an antifragile one.

Conclusion

So, is my colleague right? Absolutely. We don’t throw 10 years of security in the trash.

Am I right to advocate “Loose Typing”? Yes, but only in strategic places: at the boundaries.

For our PrestaShop merchants, the goal is clear: efficiency. They need modules and automations that absorb shocks, forgive AI errors, and deliver results.

Our job is to make this magic happen without ever compromising database integrity. It’s a new balance to find. A balance between the temple guardian (strict code) and the diplomat (AI interface).

And you, in your modules, are you more Impregnable Fortress or Decompression Chamber? Let’s talk about it in the comments, the debate is far from over! 👇

Summary (Excerpt)

The arrival of AI in the PrestaShop ecosystem challenges developers’ certainties. Should we sacrifice PHP’s strict typing rigor to adapt to LLM chaos? Discover why the answer isn’t to regress, but to adopt a “diplomatic” architecture capable of transforming fuzzy AI data into robust code.

Keywords

PrestaShop, Artificial Intelligence, PHP 8, Loose Typing, E-commerce Automation, Module Development, n8n, Best Practices, Software Architecture, LLM.

Article published on December 22, 2025 by Nicolas Dabène - PHP & PrestaShop Expert with 15+ years of experience

Questions Fréquentes

Should we abandon PHP strict typing with the arrival of AI?

No, you should not abandon strict typing in your application’s core. The recommended approach is to create an intermediate layer (Fuzzy DTO) that accepts flexible data as input and transforms it into strictly typed objects for the rest of the application. This way, you maintain rigor where it matters while allowing AI to function without constant crashes.

What is a Fuzzy DTO?

A Fuzzy DTO (Data Transfer Object) is an input layer that accepts mixed or flexible types (mixed, string int float) from AI, then transforms them into strictly typed objects for your business domain. It’s a “decompression chamber” that cleans and validates data before it enters your application’s core.

How to handle unpredictable LLM data in PrestaShop?

Create an orchestration layer that uses PHP’s Type Coercion to transform fuzzy data (like “19.90 €” or “in stock (50)”) into strict types before injecting them into PrestaShop. Use functions like filter_var(), str_replace(), and PHP casting to clean data without crashing your application.

Is PHP's Loose Typing an advantage with AI?

Yes, but only at your application’s boundaries. PHP’s ability to perform type coercion (automatically transforming “15.5” into 15.5) becomes an asset for absorbing variations in AI responses. However, this flexibility should remain confined to the data ingestion layer, not in your critical business logic.

How to orchestrate AI agents with PrestaShop?

Use tools like n8n or Make to create automation workflows that connect LLMs (ChatGPT, Claude) to PrestaShop. Implement Fuzzy DTOs to transform AI responses into data compatible with your PrestaShop modules. Ensure you have robust validation and logs to trace transformation errors.

Is PrestaShop free?

Yes, PrestaShop is an open-source and free e-commerce CMS. You only pay for hosting and premium modules.