DEV Community: Nicolas Dabene

PHP 8.6 Enters Beta: What You Should Actually Start Looking At

Nicolas Dabene — Thu, 13 Aug 2026 04:20:23 +0000

PHP 8.6 has entered Beta, signaling a shift from theoretical RFCs to concrete language changes. This milestone is particularly relevant for maintainers of libraries, frameworks, and CMSs who need early visibility into compatibility issues before the stable release on November 19, 2026. While production upgrades remain premature, now is the ideal time to test existing codebases and dependencies against PHP 8.6 in development environments.

One of the most practical additions in PHP 8.6 is the clamp() function. It replaces nested min() and max() calls with a single, intention-revealing expression. For example, ensuring a percentage stays between 0 and 100 becomes $percentage = clamp($percentage, 0, 100);—clearer at a glance and easier to maintain across large codebases. This kind of improvement doesn’t change what’s possible, but it makes existing patterns more readable.

Another meaningful enhancement is the extension of the #[Override] attribute to class constants. PHP can now validate that a constant in a child class actually overrides a parent or interface constant. This prevents subtle bugs when contracts evolve, catching mismatches earlier than static analyzers alone. It’s a small but powerful way to let the language enforce developer intent automatically.

Behind the scenes, PHP 8.6 includes runtime optimizations for closures and arrow functions. The engine can now reuse stateless closures across invocations when safe, reducing object churn without requiring code changes. These optimizations target real-world patterns used by millions of developers, improving performance transparently—exactly the kind of improvement that benefits everyone without demanding architectural rewrites.

There’s also a subtle but important change to trim(), ltrim(), and rtrim(): the form feed character (\f) is now considered whitespace by default. While rare, this could affect applications that rely on preserving \f in strings. Beta testing is the best way to surface such edge cases before they reach production.

If you maintain a PHP project, now is the time to run your test suite on PHP 8.6 Beta. You might find full compatibility, uncover a deprecation, or identify a dependency blocking upgrade. Either way, you’ll gain months of lead time before the stable release.

https://nicolas-dabene.fr/en/blog/php-86-enters-beta-what-you-should-actually-start-looking-at/

The Sovereignty of E-Commerce: Why Open Source Could Be Tomorrow’s True Answer

Nicolas Dabene — Sun, 09 Aug 2026 18:24:47 +0000

E-commerce merchants today face a critical choice: build on a proprietary platform they don’t control or rely on open-source software that can be inspected, adapted, and evolved by their own teams. As cloud giants and SaaS vendors consolidate power, the question of digital sovereignty has moved from AI models to the very foundations of online retail. Open-source platforms like PrestaShop are not relics of the past; they may well be the building blocks of e-commerce’s next decade.

Open source gives merchants something rare in today’s tech landscape: the ability to understand, modify, and steer their digital commerce stack. While closed platforms promise convenience, they often come with hidden dependencies and opaque roadmaps. In contrast, a thriving open-source project like PrestaShop—now evolving under the stewardship of cyber_Folks, Sylius, and BitBag—offers both a proven track record and a path to future-proofing. The recent creation of an .ai directory in the PrestaShop repository signals a deliberate move toward integrating AI agents and assistants directly into the platform, ensuring merchants—not external vendors—control the intelligence layer of their stores.

The recent Performance and Sustainability Plan (PSE) at PrestaShop has understandably raised concerns, but it may also reflect a necessary pivot in response to rapid industry shifts. The tech world is undergoing a brutal transformation driven by AI, new architectures, and changing user expectations. Organizations that resist change risk irrelevance, while those that adapt—even through difficult transitions—can emerge stronger. PrestaShop’s evolution is not a retreat, but a strategic repositioning to meet the demands of AI-augmented e-commerce.

Ultimately, the future of e-commerce won’t be a binary choice between open source and SaaS. Both models will coexist. But in a world where every business depends on its digital tools, sovereignty—the ability to control your infrastructure—is becoming a strategic necessity. Merchants who prioritize platforms they can understand, extend, and govern will be better positioned to innovate, scale, and respond to change.

https://nicolas-dabene.fr/en/blog/the-sovereignty-of-e-commerce-why-open-source-could-be-tomorrows-true-answer/

Preparing Your Project Before Asking an AI for Code

Nicolas Dabene — Fri, 07 Aug 2026 22:15:03 +0000

Series "Learning to Code with AI" — Article 2/7

TL;DR

A coding agent works best when the need, stack, conventions, and validation criteria are explicit. Preparing the project isn’t about writing a fifty-line prompt. It’s about making the decisions that structure learning yourself.

The First Prompt Shouldn’t Ask for Code

When discovering Claude Code or Codex, the temptation is immediate: describe an application and watch the agent build it.

For our mini-dashboard, this might look like:

Create a modern Next.js dashboard that displays the status of my servers.
Add API calls, tests, and a nice interface.

This prompt can generate many files. Yet it says almost nothing.

Which metrics should be displayed? Where do they come from? What does the user see while loading? How to signal an unavailable API? Is authentication part of the scope? What allows us to consider the work complete?

When these decisions are missing, the agent makes them. The junior then discovers an architecture they neither chose nor understood.

Start with a Short Requirements Sheet

Our first version can fit into a few lines:

# Mini-dashboard — V1 Scope

## Objective

Display a synthetic server status from a simulated API.

## Metrics

- service status;
- CPU load as a percentage;
- used and total memory;
- used and total disk space.

## States to Handle

- loading;
- success;
- API unavailable;
- invalid response.

## Out of Scope

- real authentication;
- database;
- metric history;
- real-time graphs.

This document forces us to distinguish the real need from ideas that might come later.

Define What "Done" Means

A vague task encourages the agent to stop when it deems the result satisfactory. A verifiable task gives it a limit.

For the CPU card:

## Acceptance Criteria

- The card displays a value between 0 and 100.
- A `%` unit is visible.
- A missing or invalid value doesn’t cause a crash.
- An explicit state replaces the invalid metric.
- The main behavior is covered by a test.

These criteria aren’t reserved for project managers. They teach developers to turn an intention into observable behavior.

Choose a Stack Without Collecting Dependencies

Our foundation will be intentionally classic:

TypeScript to make data structures explicit;
React to build components;
Next.js for the application framework;
Vitest and React Testing Library for targeted unit tests;
runtime validation for external data, if the need is confirmed.

Next.js directly integrates TypeScript and provides its configuration when creating the project. Its TypeScript documentation remains the reference for current behavior. For testing, the official guide presents several options, including Vitest, Jest, Playwright, and Cypress.

The choice of a tool should answer a question. "The AI knows this library" isn’t an architecture criterion.

Design an Architecture Small Enough to Be Understood

A first organization could be:

src/
  app/
    page.tsx
  components/
    MetricCard.tsx
    ServerOverview.tsx
  features/
    server-status/
      api.ts
      schema.ts
      types.ts
  test/

This structure isn’t a universal truth. It simply materializes three responsibilities:

fetch data;
verify its shape;
display it.

If the junior can’t explain the reason for a folder, that folder may be premature.

Write the Repository’s Permanent Rules

Claude Code can read project instructions in CLAUDE.md. Codex notably uses AGENTS.md for the repository’s durable conventions. The official documentation describes Claude Code’s memory and instructions as well as Codex customization.

Our rules file could contain:

# Project Rules

- Use TypeScript in strict mode.
- Don’t use `any` without written justification.
- Don’t add a dependency without explaining the need and alternatives.
- Separate API access from display.
- Validate all external data before use.
- Modify few files per step.
- Present a plan before any significant modification.
- Run typing, linting, and relevant tests.
- Clearly signal what couldn’t be verified.

This file shouldn’t become an unreadable constitution. A rule deserves to be included when it’s stable, concrete, and verifiable.

Ask for an Analysis Before Implementation

The first useful exchange with the agent might look like this:

Analyze the requirements sheet and repository rules.
Don’t modify any files.

I want you to:
1. identify any missing decisions;
2. propose a breakdown into tasks of less than one hour;
3. list technical risks;
4. indicate how to verify each step;
5. ask me questions instead of choosing silently.

The junior should then challenge the plan. Why this dependency? Why a client component? Why this test? What happens with an invalid response?

Prepare Git Before Letting the Agent Act

Before the first modification:

initialize the repository;
check tracked files;
create a clean first commit;
ensure secrets and local files are ignored;
learn to display a diff and return to a known state.

A clean history isn’t just for fixing errors. It allows comparing what the agent announced with what it actually modified.

Preparation Is Already Part of Learning

At this stage, we’ve barely coded anything. Yet we’ve worked on fundamental skills: scoping, breaking down, choosing, anticipating, and verifying.

This is precisely what the prompt "build me the whole application" would have made invisible.

In the next article, we’ll see how to find, inspect, and adapt skills without turning the project into a collection of contradictory rules.

You Have PrestaShop and ChatGPT? Here Are 6 Ways You Can Use AI Today Without Installing a Single Module

Nicolas Dabene — Fri, 31 Jul 2026 22:15:03 +0000

When we talk about artificial intelligence in e-commerce in 2026, the discussion quickly becomes very technical. We talk about agents, MCP, automation, API connections, RAG, and orchestration. All of these topics are interesting and open up real possibilities, but they also have one drawback: for a merchant who does not yet use artificial intelligence in their daily work, they can create the impression that you need to launch an IT project before you can even test anything.

However, your first use of AI with PrestaShop will probably not involve an integration. You do not necessarily need to install a module, give an agent access to your store, or ask your agency to develop a connector.

A ChatGPT, Claude, or Gemini account is already enough to get started.

The principle of this article is therefore deliberately simple. You are going to take a task that you already perform in your day-to-day work as a merchant, gather the information you have available, provide it to a conversational AI, and use the result in your work. There will be no automation and no direct connection to your store.

For each example, I will also give you a prompt that is ready to copy and paste. You can obviously adapt it to your business, but the goal is for you to be able to genuinely test the use cases presented here as soon as you finish reading this article.

Turn a supplier product sheet into a real product page
Prepare the SEO elements of a product page
Respond more easily to an unhappy customer
Get insights from a PrestaShop CSV export
Understand an error message before contacting your developer
Go further: turn a product photo on a white background into a lifestyle visual

Before You Start: AI Does Not Know Your Store by Magic

Before testing the first use case, you need to understand one rule that will apply throughout this article. ChatGPT, Claude, or Gemini do not automatically know your company, your customers, your catalog, or the way you communicate.

If you simply write, “write me a product description,” the AI will have to fill in a large part of the missing context. The result may be well written while still being completely generic. This is often the point at which some people conclude that AI-generated texts are empty or all sound the same.

The problem often comes from the initial request.

In the prompts suggested in this article, you will notice that I regularly specify the role expected from the AI, the company context, the target audience, the objective, and above all the limits that must be respected. One of the most important limits in e-commerce is very simple: never invent a product characteristic that is not present in the information provided.

You should also keep another precaution in mind. Avoid copying personal or confidential data without thinking about the tool and account you are using. Data processing policies and privacy settings differ between services. If you need to work on a customer message, anonymize it. “John Smith” can become “the customer,” an order number can become “the relevant order,” and there is no reason to provide a postal address in order to improve the wording of a customer service response.

Now that these two rules are clear, we can start with one of the simplest use cases.

1. Turn a Supplier Product Sheet Into a Real Product Page

If you manage a large catalog, you probably know the problem. A supplier sends you a title, a few technical specifications, and a description that sometimes reads more like an instruction manual than a sales pitch.

The quickest reaction is often to reuse that description almost as it is. However, PrestaShop’s own documentation recommends taking care with product descriptions and reminds merchants that a description should be commercially useful and unique. It specifically warns against simply copying supplier product sheets.

This is exactly the kind of work where conversational AI can save you time. Its role is not to invent a better product than the one you actually sell. However, it can take raw information and reorganize it to make it easier for your customer to understand.

Imagine that your supplier sends you a highly technical description of a hiking backpack. You can copy the content, open a new conversation, and use the following prompt.

Ready-to-Copy Prompt

You are an e-commerce copywriter helping me prepare a product page for my PrestaShop store.

My business: [DESCRIBE YOUR BUSINESS]

My target customer: [DESCRIBE YOUR CUSTOMER]

I am going to provide you with the raw information sent by my supplier.

Using only this information, write:

- a short description designed to present the product quickly;
- a structured and natural long description;
- a clear presentation of the main customer benefits;
- a summary of the technical characteristics that are genuinely present in the information provided.

Do not invent any characteristic, material, certification, dimension, compatibility, or promise that is absent from the source content.

If an important piece of information appears to be missing, tell me separately instead of inventing it.

Avoid exaggerated advertising expressions such as “revolutionary,” “exceptional,” or “must-have” unless they are justified by the information provided.

Here is the information from my supplier:

[PASTE YOUR CONTENT HERE]

This prompt contains an instruction that I consider fundamental: if information is missing, the AI should tell you instead of filling in the gap.

This is a habit worth keeping in almost all of your professional uses of artificial intelligence. A perfectly written text can still contain false information. On a product page, an invented material, incorrect compatibility, or non-existent certification does not become true simply because the sentence sounds convincing.

Once you have the result, reread the product page while keeping the supplier information in front of you. Your job is no longer necessarily to write every sentence from a blank page. It becomes more about checking, correcting, and adapting an initial draft.

For a merchant managing dozens or hundreds of products, that difference is far from insignificant.

2. Prepare the SEO Elements of Your Product Page Without Starting Over

Once your product description is ready, do not immediately close the conversation.

This is a fairly common mistake when people first start using conversational AI. They ask a question, get an answer, and then open a new conversation for the next task. However, in our example, the AI has just worked on your product. It already has the context from the conversation.

PrestaShop includes dedicated SEO fields in the product page, including the meta title and meta description. Its documentation also recommends customizing this content and indicates that a meta description should ideally remain under 155 characters.

You can therefore simply continue the previous conversation with a new request.

Ready-to-Copy Prompt

Using only the product page we have just prepared, help me now complete the SEO elements of my PrestaShop product page.

Suggest:

- 3 meta title variations;
- 3 meta description variations under 155 characters;
- one simplified and readable URL suggestion.

Do not add any product characteristics that are absent from the product page.

For each meta title and meta description suggestion, explain in one sentence the angle you chose.

Avoid keyword stuffing and prioritize wording that is understandable to a human.

The value of this example goes beyond SEO. It helps you understand a much more natural way of working with AI: the conversation can progress alongside your task.

You started with supplier information. You created a product page. You are now using that product page to prepare the SEO elements. You could then ask for a shorter version for a newsletter or prepare three social media post suggestions.

This is still not automation. You are still copying the result into the corresponding fields in your PrestaShop back office. However, you are already starting to build a real AI-assisted workflow.

3. Prepare a Response to an Unhappy Customer Without Replying While You Are Frustrated

Customer service is probably one of the areas where conversational AI can become useful very quickly, as long as you do not delegate the commercial decision to it.

Let us take a classic situation. A customer writes to you because their parcel is late. Their message is particularly aggressive. You have just processed several orders, a supplier has announced an out-of-stock situation, and you have already answered the same question three times since the beginning of the day.

This may not be the best moment to write a perfectly measured response.

PrestaShop natively includes customer message management and also allows you to prepare reusable messages for similar situations. AI can step in before this stage to help you formulate a response that fits the situation.

Start by anonymizing the message. Remove the name, address, phone number, email address, and any references that are not necessary to understand the issue.

You can then use this prompt.

Ready-to-Copy Prompt

You are an assistant helping me prepare a customer service response for an e-commerce store.

I am going to send you an anonymized customer message.

Prepare a short, human, and professional response.

I want to acknowledge the customer’s dissatisfaction without admitting fault that has not yet been verified.

Do not promise any refund, credit, goodwill gesture, or specific deadline unless that information is included in the context I provide.

Do not invent any information about the order or the carrier.

If I am missing information required to respond correctly, first tell me which questions I need to check before sending the response.

Here is the context I have:

[ADD YOUR CONTEXT]

Here is the anonymized customer message:

[PASTE THE MESSAGE]

The most interesting part of the prompt may not be the writing request. It is the possibility for the AI to tell you that it does not have enough information to prepare a final response.

If the customer asks where their parcel is and you have not yet checked the tracking information, the correct AI response is not to invent that the parcel is on its way. It should remind you that a verification is necessary.

You remain the person who decides on a refund, a goodwill gesture, or the final response. The AI simply helps you turn the facts you have into a clearer and more measured message.

Over time, you can also identify recurring situations and improve your standard responses before saving them among your organization’s reusable messages.

4. Get Insights From a PrestaShop CSV Export, Even If You Are Not a Data Analyst

Here we reach one of the use cases that most often surprises people who use AI only for writing text.

Modern conversational AI can also work with files.

PrestaShop’s documentation states that most of the data available in its statistics can be downloaded in CSV format. ChatGPT explicitly documents spreadsheet and CSV file analysis. Claude also supports CSV files among its accepted formats, and Gemini allows users to import spreadsheets and other files in order to generate answers and analyses.

In other words, you do not have to manually turn your file into twenty charts before you can start asking questions.

Export the relevant data from PrestaShop, check what the file contains, and send it to the AI you use. Once again, pay attention to the possible presence of personal or confidential data. For a first test, prioritize catalog data, stock data, or aggregated statistics that do not require identifying your customers.

Then attach the file to your conversation and use this prompt.

Ready-to-Copy Prompt

You are an e-commerce analyst helping me understand a file exported from my PrestaShop store.

I am a merchant and not a data analyst. Use simple vocabulary and explain technical terms when necessary.

Start by examining the structure of the file and tell me:

1. what data it contains;
2. which columns appear to be important;
3. any limitations in the file that could affect the reliability of the analysis.

Then analyze the data and present the 5 most important observations.

For each observation, clearly separate:

- the fact directly visible in the data;
- your possible interpretation;
- the business question I should ask myself.

Never turn a hypothesis into a certainty.

Finish with 3 additional analyses we could perform using this file.

The file to analyze is attached to this conversation.

Why do I ask it to separate facts from interpretations? Because an AI can very easily produce a plausible explanation.

Imagine that a product has been selling less for three months. The data may indeed show a decline in sales. However, if the file contains no information about your prices, traffic, advertising campaigns, or market conditions, the AI cannot claim that the decline was caused by a price increase or a competitor.

It can suggest that as a possible avenue to investigate. It should not present it as a fact.

This is where AI becomes interesting for a merchant. You do not necessarily ask it, “tell me what to do with my business.” You can ask it to help you better understand your own data and, above all, surface the right questions.

5. Understand a PrestaShop Error Message Before Writing “It Doesn’t Work Anymore” to Your Agency

I will probably make a few friends among PrestaShop developers and agencies with this fifth example.

A merchant encounters an error on their store. They take a screenshot and send a message to their provider: “Hello, it doesn’t work anymore.”

The developer naturally replies: “What doesn’t work anymore?”

Then begins an investigation to determine which page is affected, what action was performed before the problem occurred, the approximate time of the error, and the message that was displayed.

PrestaShop includes logging mechanisms, and its technical documentation also explains that debug mode can provide useful information for resolving a problem. Be careful, however: I do not recommend enabling debug mode yourself in production if you do not know exactly what you are doing. The purpose of this example is not to turn a merchant into a system administrator.

However, if you already have an error message or a log extract provided by your service provider, you can ask an AI to help you understand it.

Ready-to-Copy Prompt

You are an assistant helping me understand a technical problem on a PrestaShop store.

I am a merchant and not a developer.

I am going to provide you with an error message.

I do not want any commands to run on my server, and I do not want to modify my store’s code.

Explain to me simply:

- what the message appears to relate to;
- whether the error appears to be related to PrestaShop, a module, the theme, or the technical environment, only when the message makes it possible to identify this;
- the apparent level of severity, with all necessary reservations;
- the additional information I need to collect;
- the clear message I can send to my developer or agency.

Do not invent the cause of the problem if the error message does not make it possible to determine it.

Here is the message:

[PASTE THE ERROR MESSAGE]

The goal is not for ChatGPT, Claude, or Gemini to repair your store based on a random copied line. The goal is to improve the quality of the initial diagnosis.

Instead of sending “payment no longer works,” you may be able to explain that the problem appears after cart validation, that a message seems to mention a specific module, and that the error has been reproduced twice since 10 a.m.

For the developer who needs to intervene, the difference is considerable. It is also useful for the merchant, because they better understand which information is valuable to provide when an incident occurs.

If the AI spontaneously suggests modifying a PHP file, running an SQL command, or deleting a folder on your server, do not do it simply because the answer sounds convincing. At this stage of your learning, use AI to understand the problem and communicate more effectively with the person maintaining your store.

6. The Cherry on Top: Turn a Product Photo on a White Background Into a Lifestyle Visual

If you have tested the previous examples, you already understand the general principle. You provide context, give the AI a source to work from, and clearly define what it is and is not allowed to do.

We can now go a little further with images.

Do not worry, there is still no need to install a module in PrestaShop or connect your catalog to an API. ChatGPT currently allows you to import an existing image and describe the modifications you want. Gemini also allows you to upload an image and request changes.

We are simply going to start with an existing product photo.

Let us take the example of a handmade candle photographed on a white background. The photo is clean, the product is clearly visible, and it perfectly fulfills its role as a catalog image. The problem is that it does not say much about the kind of environment in which the product could fit.

You may be tempted to upload the image and write, “make this photo more appealing.” That is exactly the kind of request you should avoid.

To get a usable result, you need to distinguish between two things: your product and its staging. The product must become the reference that needs to be preserved. The setting, lighting, atmosphere, and framing are the elements that the AI can work on.

In other words: the product is the constraint, the setting is the variable.

Add your product photo to the conversation and then use this prompt.

Ready-to-Copy Prompt

You are a product photographer and art director specializing in e-commerce.

I am attaching to this conversation the real photo of a product sold in my store.

I want to transform this photo on a white background into a professional lifestyle product photograph.

Product: [DESCRIBE THE PRODUCT]

Target customer: [DESCRIBE THE CUSTOMER]

Brand universe: [DESCRIBE YOUR BRAND UNIVERSE]

Desired atmosphere: [DESCRIBE THE SCENE]

The product shown in my photo is the absolute visual reference.

Strictly preserve its shape, proportions, colors, packaging, label, logo, and visible details.

Do not add any characteristics to the product and do not modify its design.

Only modify the staging, setting, lighting, and framing.

The product must remain the main subject of the image.

I want a realistic photographic result suitable for an e-commerce product page, not an illustration.

Desired format: [1:1 / 4:5 / OTHER]

No additional text in the image.

For our candle example, the atmosphere could be described as follows: “a cozy interior at the end of the day, a natural wooden table, warm and soft lighting, with a blanket slightly visible in a blurred background.”

This description provides an artistic direction without asking the AI to modify the candle.

The first image may not be perfect. That is normal. A common mistake at that point is to abandon the result and start again with a completely different prompt. Instead, continue the conversation.

You can ask: “Keep exactly the same product and scene, but make the lighting slightly warmer.” Then: “Remove the book located to the right of the product.” Or: “Slightly widen the framing while keeping the product as the main subject.”

You are working through iterations, exactly as you might comment on a creative proposal.

Now Look at Your Product. Really Look at It.

This is probably the most important part of this sixth example.

An AI-generated image can look visually stunning while showing a product that is slightly different from yours. A label can change. A seam can move. A zipper can appear on a bag. The number of buttons on a garment can change. A pattern can be slightly redrawn.

For a creative image used to illustrate a blog article, these variations may sometimes be acceptable. On an e-commerce product page, the issue is completely different.

You are showing the customer what they are going to buy.

Before using an AI-generated or AI-modified visual in PrestaShop, systematically compare the original product with the result. Zoom in on the logo, text, shapes, visible materials, and small details.

If the product has been modified, you can continue the conversation with this request:

The generated product is not strictly identical to my original photo.

Compare the result with the reference image I provided.

Start again while preserving the original product exactly.

Do not modify its shape, proportions, colors, label, or logo.

Only modify the setting, lighting, and staging.

I would also keep the real product photo in the PrestaShop gallery. The lifestyle visual complements the product presentation and adds visual context. It does not necessarily need to replace all of your original photographs.

AI can help you explore an artistic direction and produce staged visuals that would previously have required more resources. It does not remove your responsibility to verify that the image actually shows the product being sold.

You Have Just Used AI With PrestaShop Without Connecting AI to PrestaShop

This is probably the most important point of this article.

We worked on a product page, prepared its SEO elements, drafted a customer service response, analyzed a CSV file, interpreted an error message, and even worked on visual staging.

At no point did we install an AI module. We did not configure MCP. We did not give an agent an API key. We did not connect ChatGPT to the store database, and we did not launch an automation project.

And that is perfectly fine.

If you have never yet integrated artificial intelligence into your daily work as a merchant, your priority is probably not to immediately automate your business. Start by identifying repetitive tasks, moments when you begin from a blank page, and situations where you spend a lot of time understanding or reformulating information.

Then take just one of those tasks and test it with conversational AI.

Automation may come later. Once you have repeated the same process ten, twenty, or fifty times, you will naturally start wondering whether some tools could be connected or whether certain copy-and-paste steps could be avoided.

At that point, talking about APIs, modules, agents, or MCP will make much more sense, because you will no longer be asking, “how can I put AI into PrestaShop?”

You will already know exactly which task you want to improve.

And that is generally a much better starting point.

Claude Opus 5 and PrestaShop: When a More Powerful Model Becomes Truly Useful

Nicolas Dabene — Sat, 25 Jul 2026 22:15:03 +0000

Claude Opus 5 can save time on the most complex PrestaShop topics. But deploying it everywhere would be a bad idea: its price, reasoning mode, and required level of control make it a precision tool, not the default engine for every automation.

TL;DR

Claude Opus 5 is particularly interesting when a developer needs to understand a large codebase, trace the real cause of a bug, arbitrate a redesign, or verify a modification affecting multiple layers of PrestaShop.

For a merchant, the value doesn’t lie in a "smarter" chatbot. It emerges in high-impact operations where AI must correlate data, follow a procedure, and flag what requires human decision-making: catalog anomalies, conversion discrepancies, order incidents, or pre-production checks.

However, generating a product description, summarizing a ticket, or rephrasing an email with Opus 5 is often too costly and ambitious for the need. A smaller model, a business rule, or classic automation will do the job better, with a more predictable bill and latency.

The Subject Isn’t "A Better Chatbot"

With every release of a high-end model, the same shortcut resurfaces: if it’s more powerful, it should be used everywhere.

This reasoning doesn’t hold up long in an e-commerce environment.

A PrestaShop store doesn’t need an advanced reasoning model to classify a customer service request, standardize a product sheet, or draft a response. These tasks are numerous, repetitive, and measurable. Above all, they must be fast, stable, and inexpensive.

However, some situations resist rule-based workflows. A bug doesn’t come from an isolated line but from the interaction between an override, a hook, a module, a cache, and a version quirk. A migration affects the theme, the funnel, payment modules, and data. A commercial anomaly can only be understood by cross-referencing orders, traffic, stock, promotions, and a recent change.

The problem isn’t producing more text.

The problem is maintaining a hypothesis, verifying it, finding the missing evidence, and not declaring a subject resolved too soon.

This is precisely the angle highlighted by Anthropic for Claude Opus 5: more verification, more rigorous iterations, and better performance on long, multi-step tasks. The announcement doesn’t replace testing in your own stack, but it accurately describes the type of work for which a model of this class can change the quality of the result: root cause analysis, agentic development, deliverable control, and tool chaining. Anthropic, July 24, 2026

What Opus 5 Can Bring to a PrestaShop Developer

PrestaShop is a good revealer of the limits of a generalist model used too quickly.

The visible code isn’t always the executed code. A rule can be modified by a module, an override, a hook, a Symfony service, a database configuration, or the cache. And a fix that seems to work on one page can degrade the cart, the back office, or a multilingual store.

In this context, the expected strength of Opus 5 isn’t generating more code. It’s reducing the number of steps where the agent concludes before verifying.

Understand Before Fixing

For a difficult incident, you can ask it to map the execution path before any modification: entry point, relevant hooks, called services, read data, involved caches, and missing tests.

The right result isn’t an immediate patch. It’s an explicit hypothesis, accompanied by the inspected files and the means to disprove it.

This way of working is particularly useful for:

a regression after a PrestaShop or module update;
a cart that behaves differently depending on the customer group, currency, or carrier;
degraded performance whose cause may lie in the code, database, or infrastructure;
a migration to PrestaShop 9 that requires identifying legacy usages before replacing them.

Anthropic notably mentions progress on debugging and root cause analysis tasks, as well as cases where the model builds its own test bench when a validation system is missing. This is interesting for a developer, provided they understand the limit: a generated test bench only proves what it covers. It doesn’t replace business acceptance testing or production observation.

Maintain a Redesign Across Multiple Layers

The model also becomes relevant when an evolution spans more than a single file or prompt.

Take a payment module redesign. You need to understand existing contracts, preserve stored data, adapt the front end, verify webhooks, anticipate refunds, and create a rollback strategy. The difficulty isn’t writing a Symfony controller. It’s keeping everything consistent as details accumulate.

Opus 5 seems designed for this type of long-term work: planning, acting with tools, noting discrepancies, correcting, and then resuming the thread. This can reduce the artificial splitting of a complex task into dozens of micro-prompts, without eliminating human code review.

To be truly useful, the agent must have a framework: read access to the repository, explicit test commands, an isolated staging environment, limited rights, and a log of its actions. The model’s power doesn’t negate any of these rules. It simply makes it more credible that it can use them correctly.

Conduct a Review That Goes Beyond Style

A high-end model can become a second set of eyes on a risky pull request: consistency with the architecture, side effects on multistore, PHP and PrestaShop compatibility, absence of sensitive data in logs, test coverage, and failure behavior.

This isn’t an automatic merge validation.

It’s an additional filter, useful when the cost of a defect exceeds the cost of an analysis: payment, order, price, stock, consent, customer data, or module security.

Here again, the interesting promise isn’t "Opus 5 finds all bugs." Anthropic indicates the model is stronger at verifying and iterating. This capability must be transformed into a process: asking for remaining risks, untested cases, and missing evidence, rather than a simple "is this code good?"

What a PrestaShop Merchant Can Actually Gain

A merchant shouldn’t buy a powerful model to have a better-speaking assistant.

They should use it when the decision or alert it produces has measurable operational value.

Investigate a Commercial Anomaly Without Inventing an Explanation

A drop in conversion rate doesn’t have a single cause. It can come from traffic, a campaign, a stockout, a price, a payment method, mobile slowdown, or a funnel modification.

An agent connected to controlled sources can prepare an investigation: compare periods, isolate affected segments, note configuration changes, and produce a list of hypotheses ranked by evidence. Opus 5 can be relevant if this investigation involves multiple sources and multiple verification rounds.

The decision, however, remains human. The model can say: "abandonments increased after the payment step on mobile since this deployment." It shouldn’t cancel a promotion, modify prices, or disable a provider without clear safeguards.

Control Operations That Cost Dearly When They Fail

The same reasoning applies to exceptional operations: massive catalog import, price rule migration, carrier change, central module update, or preparing a high-traffic campaign.

Before the action, Opus 5 can verify an execution plan, flag inconsistent data, generate test scenarios, and produce a checklist understandable by the e-commerce team. After the action, it can help reconcile expected and actual signals.

For a store handling a few dozen orders per week with simple processes, this level of tooling will often be excessive. For a merchant who concentrates revenue on peak times, manages multiple stores, or depends on numerous integrations, it can prevent a barely visible issue from becoming a revenue loss.

Assist Support, But Without Letting It Decide Alone

For complex requests, an assistant can retrieve useful elements from authorized tools: order status, carrier tracking, credit notes, payment history, and applicable rules. It can prepare a sourced response for a human.

This use case requires particular caution. Customer data must be minimized, access segmented, irreversible actions protected, and sources displayed. A more competent model improves analysis quality; it doesn’t make an integration that exposes too much information or confuses a suggestion with a decision acceptable.

Where Opus 5 Is Oversized

The announced API pricing is $5 per million input tokens and $25 per million output tokens. The fast mode costs double. These are the prices announced by Anthropic at launch; they should be verified before deployment. Official announcement

The cost isn’t limited to this rate. An agent that inspects a repository, calls tools, redoes an analysis, and produces a report can consume much more than a conversation. At high volume, a few cents per task quickly become a budget line.

But the real question is even simpler: do you need reasoning, or just execution?

Need	Often More Rational Choice
Generate or rephrase a product sheet	Lighter model, with tone validation and brand rules
Classify recurring customer service tickets	Business rules, fast model, and confidence threshold
Extract a reference from a clean email or PDF	Structured extraction, OCR if needed, strict validation
Answer a stable FAQ	Document search and economical model
Update a field according to a known rule	Deterministic automation, not an agent
Diagnose a regression involving multiple modules	Opus 5, read tools, and tests in an isolated environment
Prepare a migration or risky operation	Opus 5, but with mandatory human validation

Using Opus 5 for a simple task can produce an excellent response. That doesn’t mean it’s the right architecture.

In an e-commerce platform, the best model is rarely the one that solves the most difficult benchmark. It’s the one that meets the need with the expected level of quality, latency, and cost.

Who Is Opus 5 Really For?

For Developers and Agencies

Opus 5 is for developers working on topics where understanding time exceeds writing time: historical codebase, critical modules, migrations, cross-cutting debugging, pull request audit, or architectural evolution.

It becomes cost-effective when better investigation avoids a day of trial and error, a production regression, or endless acceptance testing. This assumes a team capable of framing it: available tests, project conventions, access to the right sources, and human review.

It’s not primarily for developers who just want to speed up their daily snippets. In that case, a faster and cheaper model will likely be more comfortable to use all day.

For Merchants

Opus 5 is for merchants whose operations are complex enough that multi-source analysis brings real decision-making value: large catalog, multiple channels, high volume, logistical or payment dependencies, sensitive commercial operations, and teams already spending time investigating.

It’s not a prerequisite for running a PrestaShop store properly. A store that needs to improve its product sheets, customer service, or reminders will often get better results by solidifying its data, rules, and processes than by plugging in a cutting-edge model.

The Right Model in the Right Place

Claude Opus 5 is interesting because it seems to reduce a very common flaw in code agents: producing a plausible solution, then stopping before verifying sufficiently.

For PrestaShop, this is a concrete improvement. The most costly problems aren’t those that prevent writing code. They’re those where a local fix masks a deeper cause, or where automation acts without understanding the business consequences.

But this gain doesn’t justify using Opus 5 as a universal model.

Reserve it for investigations, risky changes, and workflows where the cost of a wrong conclusion clearly exceeds the cost of its reasoning. For the rest, keep lighter models and deterministic automations.

This is how a powerful model becomes a lever. Not a new source of hard-to-explain expenses.

Getting Started with Claude Code or Codex Without Becoming Dependent on AI

Nicolas Dabene — Sat, 25 Jul 2026 06:45:04 +0000

"Learning to Code with AI" Series — Article 1/7

TL;DR

Claude Code and Codex can accelerate a junior developer's learning. But they can also create the illusion of progress simply because an application works. The right method comes down to five verbs: understand, attempt, ask, verify, explain.

A Working Application Doesn’t Prove You Know How to Code

Today, a beginner developer can ask an agent to create a complete application in just a few minutes.

A login page. A dashboard. API calls. Some tests. A clean interface.

Everything works. Yet, it often takes just three questions to uncover the problem:

Why is this component executed client-side?
What happens if the API returns invalid data?
How can you modify the behavior without regenerating the entire feature?

If the developer can’t answer, they haven’t yet learned how to build the application. They’ve learned how to ask for one.

The issue isn’t Claude Code or Codex. The issue is the disappearance of the learning loop: try, fail, search, understand, correct.

AI Removes Friction—Including the Kind That Helps You Improve

Some of the difficulty in development is unnecessary. Spending an hour finding a typo doesn’t make anyone a better architect.

AI can eliminate this friction. It can explain an error, locate a file, prepare a test, or compare two solutions.

But some challenges are formative:

breaking down a problem that’s too broad;
reading documentation;
formulating a hypothesis;
understanding a type error;
choosing between multiple implementations;
measuring the consequences of a dependency.

If the agent also makes these decisions, the junior gets the result without building the reasoning.

Our Guiding Example: A Mini-Dashboard

In this series, we’ll follow the construction of a mini-dashboard with TypeScript, React, and Next.js.

It will display a few metrics fetched from an API: service status, simulated CPU load, memory usage, and disk space. It will need to handle loading, errors, invalid data, and several useful tests.

This project is intentionally simple. Yet, it contains everything needed to learn:

turning a requirement into small tasks;
distinguishing data from display;
typing an external response;
managing interface states;
writing and verifying tests;
debugging an error;
refactoring without rewriting everything.

The goal will never be to go as fast as possible. It will be to know what we’ve learned at each step.

The Five-Verb Method

1. Understand

Before writing a prompt, rephrase the problem. What are the inputs? What result do you expect? What cases could fail?

You can use the agent to clarify a concept, but not to silently decide what you wanted to build.

2. Attempt

Write a first version. It can be incomplete or awkward.

This attempt gives the AI something much more useful than a vague request: your current reasoning. The agent can then review it, identify a misunderstanding, and explain a precise improvement.

3. Ask

Don’t automatically ask for the complete solution.

Ask for a hint, an explanation, a review, or two possible approaches. The more targeted the request, the more educational the response can be.

4. Verify

Read the diff. Run the code. Check the types. Run the tests. Observe the behavior in case of an error.

An agent can be wrong with great confidence. The quality of a response isn’t measured by its appearance, but by what you can verify.

5. Explain

After making the change, close the AI’s response and explain the code in your own words.

If you can’t explain an important line, you haven’t finished the task. You’ve only identified what’s left to learn.

A First Prompt That Protects Learning

I’m new to TypeScript and React.

Don’t modify any files yet.
Start by asking me the questions needed to verify my understanding of the requirement.
Then ask me to propose a breakdown myself.

When I share my approach:
1. point out what’s correct;
2. flag the risks without immediately giving the solution;
3. give me a first hint;
4. wait for my next attempt.

If I finally ask for a modification, present the plan and the affected files before acting.

This prompt doesn’t make the agent less powerful. It gives it a different role: it becomes a teaching partner instead of an automatic generator.

Claude Code or Codex: The Method Remains the Same

Both tools can explore a repository, modify files, execute commands, and participate in validation. Their interfaces, instruction mechanisms, and permissions differ, but the principle of control remains the same.

The junior must know:

what the agent is going to do;
which files have changed;
how the result was verified;
how to revert changes;
what they personally understood.

The official documentation presents the main workflows for Codex and Claude Code. They should remain the references for current capabilities and configuration.

The Right Metric Isn’t the Number of Lines Produced

At the end of a session, don’t just ask: “Does the feature work?”

Ask yourself instead:

Can I explain the key choices?
Could I trace the origin of a bug?
Can I modify this feature without regenerating everything?
Did I learn something transferable to another project?

AI can speed up production. Your role is to ensure it also speeds up your understanding.

In the next article, we’ll prepare the mini-dashboard before letting an agent write a single line of code.

Agile is Dead? Welcome to the Era of Agent-Driven Development

Nicolas Dabene — Fri, 17 Jul 2026 22:15:03 +0000

For several months now, a recurring theme has been cropping up more and more often in discussions about software development: Agile is dead. As is often the case in our industry, the statement is deliberately provocative. It works well in a headline, sparks debates, and above all, highlights a real discomfort. Because while Agile may not be dead, part of how we organize software development—something we’ve been practicing for twenty years—is starting to show its limits in the face of AI agents.

The issue doesn’t necessarily lie with Agile principles themselves. Rather, it stems from the fact that we’ve built methods, ceremonies, and habits around a very specific constraint: the human capacity to produce software. A team has a limited number of developers, each developer has limited time, and so we must organize this scarce capacity. We break down work, estimate, prioritize, plan, and try to measure what the team can handle in a given period.

For a long time, this logic made sense. But in 2026, a new variable is profoundly changing the equation: development agents.

The Bottleneck Is Shifting

We’re no longer just talking about autocompletion or an assistant capable of generating a PHP function from a comment. Today’s tools are starting to explore entire codebases, analyze architecture, modify multiple files, write tests, fix errors, and execute relatively long tasks with increasing autonomy.

GitHub now publicly uses the term "Agent-Driven Development" to describe some of these new practices. OpenAI is pushing multi-agent workflows around Codex, while Anthropic is already studying how developers use Claude Code in real-world situations. We’re still far from a fully stabilized model, but the direction is clear: the developer is no longer systematically the sole execution unit in the software production process.

For a long time, code was one of the main bottlenecks. A feature could be perfectly defined, validated, and prioritized, but it still had to wait for a developer to have the time to implement it. With agents, this constraint is gradually shifting.

The problem is no longer "Who will write the code?" but rather "Have we properly defined what needs to be built, with what constraints, and how will we validate the result?"

This nuance is important because it directly changes how we should think about organizing work.

Yes, a Certain Form of Agile Is Probably Dying

Let’s take the most radical thesis. A feature is identified on Monday. It needs to be described in a ticket, go through refinement, be estimated, prioritized, and then integrated into a sprint based on the team’s available capacity. In some organizations, several days—or even weeks—can pass before work even begins.

Meanwhile, a properly equipped developer can now ask an agent to explore the project, identify the relevant components, propose several implementation strategies, and prepare a first version of the change. Depending on the complexity, all of this can sometimes happen before the next refinement meeting.

It would obviously be dishonest to claim that all features can now be developed in a few minutes. That’s not the case, and agents still face many limitations. But the gap between the potential speed of execution and the speed of some organizational processes is becoming hard to ignore.

We’ve gradually built significant bureaucracy around software production. This bureaucracy was often justified by the need to protect limited development capacity. When a resource is scarce, it makes sense to try to optimize it as much as possible.

But what happens when this execution capacity becomes partially elastic?

In this context, a two-week sprint can sometimes become less of an acceleration tool and more of a simple queue. The process then starts moving slower than the tools it’s supposed to organize.

No, Agile Is Probably Not Dead

Now, let’s do the exact opposite exercise and return to principles rather than implementations.

Delivering working software quickly, collaborating with users, reducing feedback loops, and embracing change are ideas that remain extremely relevant. One could even argue that AI agents make some Agile principles even more compelling.

If the cost of a change decreases, it becomes possible to test a hypothesis faster, get feedback, correct, and repeat. The loop between building, feedback, and adaptation can become much shorter. On this point, agents are not in opposition to Agile. They can, in fact, reinforce its original philosophy.

The problem may lie elsewhere. Over the years, we’ve sometimes confused Agile with the set of ceremonies and management mechanisms that have built up around it. Meetings have become automatic, story points have sometimes been turned into productivity metrics, and some tickets are now so detailed that they almost tell the developer which line of code to modify.

So Agile may not be dead. However, the bureaucracy built around Agile could soon face a much less comfortable reality.

Our tools are changing faster than our work methods.

From Tickets to Intent

One of the evolutions that interests me most is the level of abstraction at which we define work.

In a traditional workflow, we tend to break down features into extremely precise tasks: Add a CSV export button. Create an API route. Add a column to a table. Modify a page’s display.

This approach still responds to a human constraint. A person must pick up the task, understand what’s expected, and then execute it. The more precise the task, the more we reduce the risk of misinterpretation.

With agentic systems, we could gradually move up a level and define the intent rather than the task itself.

Instead of simply asking to add a CSV export button, we could explain that the goal is to allow a merchant to use their order data outside the software. We would then specify the constraints: respect the existing architecture, avoid exposing sensitive data, support large volumes, and prevent adding external dependencies.

Finally, we would define success conditions: the export must be usable, performance validated, tests present, and security checked.

The difference may seem subtle, but it’s fundamental. In the first case, we describe a task to execute. In the second, we define a decision space in which a system can explore multiple solutions.

This model doesn’t eliminate the developer. It even increases their level of responsibility, because someone must properly define the boundaries of this decision space.

The Real Problem Will Be Validation

This is usually where I start to be wary of overly enthusiastic discourse about AI agents.

Producing more code isn’t necessarily good news. DORA’s work describes AI as an amplifier. It can enhance an organization’s strengths but also accelerate its dysfunctions.

A bad architecture doesn’t become better just because an agent can produce code faster. Insufficient test coverage becomes even more worrying when the volume of changes increases. And a fragile deployment process won’t be fixed by adding five agents capable of generating pull requests in parallel.

We could very quickly discover that code production was only part of the problem.

The new bottleneck may shift toward decision-making, context understanding, security, review, and especially validation. The more execution capacity increases, the more critical our ability to control that execution becomes.

In a world where a developer produces ten changes per week, an imperfect review already represents a risk. In a world where multiple agents can produce dozens of changes in parallel, validation becomes a central discipline.

This is probably where agentic development will truly become an engineering topic rather than just an impressive demo feature.

The Developer Won’t Become a "Prompt Engineer"

I’ve never really believed the idea that developers would become prompt engineers, spending their days searching for the magic formulation to get good code.

The profession is probably moving up a level of abstraction.

An experienced developer will still need to understand architecture, identify dependencies, anticipate side effects, and evaluate the quality of a solution. However, they will also need to learn how to properly define intent, provide usable context, set clear constraints, and determine the acceptable level of autonomy for an agent.

They will also need to know how to organize multiple execution capacities and, above all, retain the ability to look at a technically functional result and say no.

The developer of tomorrow may no longer be the one who writes the most code. They could become the one who knows how to properly govern a massive capacity to produce it.

This skill is very different from simply mastering a language or framework. It requires a broader system vision, the ability to reason about constraints, and a much finer understanding of risk.

Welcome to the Era of Agent-Driven Development

I don’t think Agile will disappear overnight in 2026. However, I do believe our work methods will need to catch up with our tools much faster than expected.

Agents are starting to explore, code, test, and work in parallel. Meanwhile, many organizations continue to measure their development capacity using models built at a time when code production depended almost exclusively on the number of hours available in a human team.

This gap will become increasingly visible.

Perhaps tomorrow we’ll talk less about sprint capacity and more about validation capacity. Maybe concepts like agentic budget, autonomy level, context quality, or governance will become as important as velocity has been over the past twenty years.

I’m still very wary of those who claim to have already invented the universal method for agentic development. We’re at the beginning of this transformation, and it would probably be dangerous to replace Agile bureaucracy with a new AI bureaucracy before even understanding what really works.

But after fifteen years in software development, I’ve rarely seen our execution capacity evolve so quickly.

So no, Agile is probably not dead.

Software development has simply changed engines. And continuing to drive exactly the same way might be our biggest mistake.

Why 2026 Proved PrestaShop Right

Nicolas Dabene — Fri, 10 Jul 2026 22:15:02 +0000

One year after writing "PrestaShop vs Hype," the facts are more compelling than any opinions.

In 2025, I defended a simple idea: stability is often underestimated in the software industry.

In 2026, this idea is no longer just an opinion.

PrestaShop's acquisition by cyber_Folks, the strategic partnership with Sylius, the energy seen at EO2S, and the launch of the PS Summit reveal a reality that many market players tend to overlook:

The value of a platform is not measured solely by its architecture or perceived modernity.

It is measured by its ability to endure, evolve, and unite a community.

And in this regard, PrestaShop is probably stronger today than it has ever been.

🔄 Revisiting a 2025 Prediction

At the end of 2025, I published an article titled:

"PrestaShop vs Hype: Why Stability Beats Modernity"

At the time, the debate kept resurfacing.

On one side, platforms considered "modern."

On the other, PrestaShop, often portrayed as a historical player, sometimes even labeled as legacy by those who only scratched the surface.

My argument was simple:

The software industry regularly overestimates novelty and underestimates durability.

A platform that has existed for fifteen years is not necessarily outdated.

It has simply survived fifteen years of technological changes, economic crises, market shifts, and evolving user expectations.

This survival is not an accident.

It is proof.

One year later, events seem to have confirmed this intuition.

🤝 The False Debate Between PrestaShop and Sylius

For a long time, part of the ecosystem presented PrestaShop and Sylius as opposing visions.

PrestaShop represented accessibility, ecosystem, merchant volume, and maturity.

Sylius embodied flexibility, an API-first approach, modern architecture, and complex projects.

This opposition was always reductive.

Because it assumed you had to pick a side.

Yet the market sent a very different message.

The partnership between PrestaShop and Sylius shows that these two platforms are not enemies.

They address different needs while sharing common foundations: open source, Symfony, a strong technical culture, and a commitment to long-term building.

The question is no longer:

Which platform will replace the other?

The question becomes:

How can two complementary ecosystems create more value together?

This is a far more interesting evolution.

And probably much more mature.

🌍 What EO2S Really Demonstrated

When discussing a community event, it’s easy to focus on the conferences, announcements, or numbers.

For me, the most important aspect was elsewhere.

EO2S reminded us of something that comparison charts systematically overlook:

A platform is not its code.

A platform is a community.

Behind every store are developers, integrators, agencies, module publishers, freelancers, hosting providers, contributors, and merchants.

It is this collective that creates value.

Not just the GitHub repository.

Not just the features.

Not just the technology.

The PrestaShop ecosystem has sometimes been criticized.

But when you physically bring its players together, you quickly realize the scale of the network built over nearly two decades.

And this is precisely the kind of asset that cannot be bought.

A community is built year after year.

Contribution after contribution.

Project after project.

Trust after trust.

🏛️ The Real Asset: Longevity

In the startup world, novelty is often seen as a virtue.

In commerce, it’s often the opposite.

A merchant doesn’t look for the trendiest platform.

They look for one that will still be there tomorrow.

Then in five years.

Then in ten years.

This difference is fundamental.

E-commerce is a business of continuity.

Switching platforms is costly.

Training teams is costly.

Migrating data is costly.

Rebuilding processes is costly.

Companies naturally seek platforms capable of standing the test of time.

And this is where the Lindy effect becomes interesting.

The longer a technology survives, the higher its probability of continuing to exist.

PrestaShop is no longer a promise.

PrestaShop is proof.

🤖 The AI Paradox

One of the surprises of recent years concerns artificial intelligence.

Many assumed AI would favor the newest platforms.

In practice, the opposite is often observed.

AI agents excel when they have rich context.

They need:

documentation,

examples,

history,

discussions,

feedback,

existing code,

accumulated best practices.

In other words, they perform particularly well in ecosystems that have already built significant collective memory.

This is precisely what PrestaShop and Sylius possess.

Years of documentation.

Thousands of projects.

Thousands of developers.

Millions of lines of usable context.

AI does not replace this legacy.

It amplifies it.

🚀 The Signal Sent by the PS Summit

The announcement of the PS Summit powered by PrestaShop & Sylius is probably more significant than it appears.

Because it tells a story.

For years, the industry sought to pit platforms against each other.

Open source vs. SaaS.

Monolithic vs. headless.

Legacy vs. modern.

PrestaShop vs. Sylius.

Today, the market seems to favor a different logic.

Cooperation over opposition.

Complementarity over replacement.

Building over destruction.

This approach is less spectacular.

But it is often more effective.

🎯 The Real Lesson of 2026

I don’t think 2026 proved that PrestaShop is perfect.

No platform is.

I also don’t think modernity is useless.

It remains essential.

Architectures evolve.

Uses evolve.

Expectations evolve.

But 2026 reminded us of something important.

Technology alone does not create sustainability.

What creates sustainability is the balance between innovation and stability.

Between vision and execution.

Between evolution and continuity.

While the industry chased the next revolution, PrestaShop continued to do what it has done for years:

evolve gradually,

modernize its foundation,

strengthen its ecosystem,

and unite its community.

Today, with Sylius by its side, this balance seems stronger than ever.

Conclusion

In 2025, I wrote that stability often beats modernity.

In 2026, I would say something slightly different.

Stability alone is not enough.

Modernity alone is not enough either.

The platforms that win are those that manage to evolve without losing what made them strong.

The partnership between PrestaShop and Sylius, the vitality seen at EO2S, and the momentum of the PS Summit tell exactly this story.

A story less spectacular than trends.

But much harder to replicate.

And in software as in e-commerce, it’s often the stories that last that ultimately win.

Nicolas Dabène

PrestaShop developer, open-source e-commerce observer, and passionate about systems that outlast hype cycles.

ChatGPT Work: The Chatbot Becomes a Work System

Nicolas Dabene — Fri, 10 Jul 2026 16:15:03 +0000

TL;DR

ChatGPT Work is no longer limited to answering: it researches, plans, acts, and produces finalized deliverables.

The real change doesn’t come solely from GPT-5.6, but from the connection between the model, files, applications, plugins, and scheduled tasks.

OpenAI now clearly separates three uses: Chat for conversing, Work for producing, and Codex for developing.

The more autonomous the agent becomes, the more permissions, traceability, and human validation become important.

For a long time, using ChatGPT meant asking it a question and getting an answer.

A good answer, sometimes excellent.

But always just an answer.

With ChatGPT Work, OpenAI is trying to move this boundary. The product introduced on July 9, 2026, no longer just wants to participate in a conversation. It aims to take charge of an objective, gather the necessary context, work across multiple tools, and turn it all into a usable result.

The change may seem subtle.

It is not.

The problem was no longer really about generating text. The models could already do that. The problem was everything surrounding it: finding the right information, understanding its context, switching between applications, maintaining a project over time, and producing a truly usable deliverable.

ChatGPT Work is precisely trying to become this orchestration layer.

🧠 This is not a new conversation mode

OpenAI presents ChatGPT Work as an agent capable of staying on a project for several hours, breaking down an objective into steps, and producing documents, spreadsheets, presentations, reports, or web applications.

In other words, we no longer just ask it:

“What do you think of this data?”

We can ask it:

“Analyze this data, compare it with last month’s results, identify discrepancies, prepare the summary table, and turn the conclusions into a presentation for management.”

The difference is not in the length of the prompt.

It’s in the responsibility entrusted to the system.

OpenAI also clarifies the separation between its three main experiences in its ChatGPT Work and Codex documentation:

Experience	Primary Use	Expected Outcome
Chat	Question, quick search, reflection, or conversation	An answer
Work	Long research, analysis, and creation of deliverables	A finalized work product
Codex	Development, testing, commands, and work on a repository	A verified software modification

This separation is important.

Not all requests require an autonomous agent. Asking a simple question in Work would be as relevant as launching a multi-agent architecture to correct a typo.

Chat remains the space for quick exchanges. Codex retains software work. Work takes the area in between: long, documentary, cross-functional tasks that are often difficult to contain within a single application.

🔌 The real product is the connected context

A powerful model without context remains an excellent generator of generalities.

This is probably the most important point about ChatGPT Work.

The product can retrieve information from the tools where work already exists: messaging, emails, calendars, document spaces, CRMs, project management tools, or local files on the desktop application. OpenAI also announces over 1,400 plugins capable of providing skills, application connections, and workflow templates.

The model is therefore no longer isolated in a conversation window.

Depending on the connections and permissions granted, it can find a decision in Slack, consult a document in Google Drive, analyze data, and then produce a support adapted to the project’s context.

This is where ChatGPT Work can truly save time.

Not by writing a sentence faster than a human.

But by eliminating some of the invisible work that precedes that sentence: searching, opening, copying, cross-referencing, reformatting, and verifying that you’re working with the latest version.

In many companies, the knowledge already exists. It’s simply scattered across ten tools and twenty conversations.

ChatGPT Work doesn’t automatically create a perfect corporate memory. It offers a layer capable of mobilizing this knowledge when a task needs it.

This nuance is essential.

Connecting tools isn’t enough to structure information. An outdated document remains outdated. A contradictory decision remains contradictory. Overly broad permissions remain dangerous.

The agent can better leverage context.

It doesn’t relieve the company of governing it.

📄 The output is no longer text, but a deliverable

The promise of ChatGPT Work doesn’t stop at synthesizing information.

The system can create or modify documents, spreadsheets, presentations, reports, and analyses. It can also use a reference file, adhere to an existing template, and preserve important elements like formulas, structure, tone, or visual identity.

The official documentation on file creation clearly shows the shift in logic: you must describe the deliverable’s use, provide sources, specify the output format, and indicate what must remain unchanged.

You’re no longer just writing a prompt.

You’re defining a performance contract.

This way of working closely resembles what developers already know with code agents: giving an objective isn’t enough. You also need to provide context, constraints, validation criteria, and a definition of what “done” means.

ChatGPT Work generalizes this approach to finance, marketing, sales, operations, or data analysis professions.

However, the result must remain verifiable.

A well-presented table can contain a bad formula. A convincing presentation can rely on an outdated source. A perfectly structured report can hide a fragile assumption.

A finalized deliverable doesn’t mean human validation disappears.

It means humans can shift their attention from creation to verification and decision-making.

⏱️ Scheduled tasks transform the assistant into a process

Creating a report once is useful.

Maintaining it automatically is much more interesting.

With Scheduled Tasks, ChatGPT Work can execute a one-time action, repeat a task on a schedule, react to an event, or monitor changes. It then becomes possible to ask the system to track new customer feedback, update an agenda based on the week’s exchanges, or generate a report when data changes.

This is where we truly leave the chatbot behind.

A conversation waits for a prompt.

A process continues to exist between prompts.

For an e-commerce team, you could imagine recurring incident tracking, a weekly support feedback summary, or updating a risk table based on connected tools.

But automating a bad process doesn’t make it better.

Before scheduling a task, you still need to define its frequency, sources, stop conditions, recipients, authorized actions, and cases requiring human validation.

Without this, you don’t gain an autonomous assistant.

You gain a recurring error.

🛡️ More autonomy means more governance

The presentation page emphasizes ChatGPT Work’s ability to act within a company’s tools. This is obviously what makes the product interesting.

It’s also what increases its risk level.

An agent capable of reading a file, modifying a spreadsheet, consulting a CRM, or triggering an action should not have more rights than the task requires.

OpenAI indicates that Enterprise and Edu administrators can control authorized users, accessible context, available connections, and permitted actions. The browser, network access, plugins, and certain sensitive operations can also be restricted. A self-review mechanism should examine important actions before execution.

These protections are necessary.

They don’t replace a clear internal policy.

The right question isn’t:

“Can ChatGPT Work access our CRM?”

The real question becomes:

“Which data should it access, for which task, for how long, and with what revocation possibilities?”

A serious agent-based architecture always relies on the same principles: minimal permissions, traceable actions, isolated secrets, risk-proportionate validation, and the ability to interrupt the workflow.

ChatGPT Work makes agent-based systems accessible to more professions.

It therefore also makes its governance essential for more teams.

⚠️ A powerful launch, but still fragmented

We must finally distinguish the product’s vision from its state at launch.

As of July 10, 2026, ChatGPT Work is being rolled out according to plans and platforms. The web and mobile experience works in the cloud, while the desktop application can access local files and applications with user permission.

Continuity isn’t yet complete: Work conversations created in the cloud don’t initially appear in Work on desktop, and local projects remain on the relevant machine. The web and mobile versions can’t directly access computer files.

File creation also depends on format, plan, and workspace settings. Google Docs, Sheets, and Slides are supported when the corresponding applications are connected. Excel can be controlled via its add-in, but PowerPoint isn’t integrated into the desktop Work flow at launch.

These aren’t details.

They determine where context is located, where deliverables are saved, and what a workflow can truly automate.

It’s therefore best to avoid designing critical processes now by assuming all surfaces, files, and conversations are perfectly synchronized.

The direction is clear.

The experience is still under construction.

🚀 What ChatGPT Work really changes for businesses

The main change isn’t that every employee will be able to generate more content.

That would be a very limited view of the product.

The challenge is to transform certain repetitive and cross-functional tasks into explicit workflows capable of gathering context, producing a result, and maintaining that result over time.

This forces companies to better define their own operations.

Which sources are authoritative? Who owns the decision? Which template must be followed? What can the agent modify? What evidence must accompany the result? At what point should a human take over?

These are organizational questions before being artificial intelligence questions.

The teams that will get the most value from ChatGPT Work probably won’t be those that write the most impressive prompts.

They’ll be those that know how to turn their know-how into usable context, controlled permissions, validation criteria, and observable processes.

Conclusion

ChatGPT Work isn’t just ChatGPT with an extra button.

It’s the materialization of a deeper change: AI no longer just wants to participate in work. It wants to execute part of it.

The model answered.

The agent produces.

The work system, however, gathers the context, tools, files, automations, and controls needed to reach the result.

This evolution can truly increase teams’ capacity. But it won’t eliminate the need for framing, responsibility, or human validation.

On the contrary.

The more capable AI becomes of acting, the more precisely the company must know where it can act, with what rights, and according to which rules.

The next competitive advantage won’t come from the number of tasks entrusted to ChatGPT Work.

It will come from the quality of the systems built around those tasks.

Official Sources

5 Claude Code Features That Many Developers Underutilize

Nicolas Dabene — Tue, 30 Jun 2026 16:00:06 +0000

Most developers use Claude Code as a simple assistant capable of generating code.

Yet, the biggest gains don’t come from code generation itself.

They come from how you structure the context, protect the project, delegate tasks, and manage the agent’s working memory.

After several weeks of intensive use, five features stand out: CLAUDE.md, Hooks, ultrathink, /compact, and Subagents.

Used together, they transform Claude Code from a simple conversational tool into a true AI-assisted development environment.

🧠 The Problem Is Almost Never the Model

When a developer claims that Claude Code produced bad code, the issue rarely lies with the model itself.

In most cases, Claude works with incomplete context, implicit rules it doesn’t know, or memory cluttered by hours of exchanges.

This is exactly the same problem as with a human developer joining a project without documentation, conventions, or an overview.

The difference is that a human eventually understands the environment over weeks.

The AI, however, starts almost from scratch with each session.

This is why the most important features of Claude Code aren’t those that generate code.

They’re the ones that structure its working environment.

📄 CLAUDE.md: The File That Avoids Repeating the Same Things

Many teams spend their time reminding the agent of the same information:

how to run tests;
which commands to use;
which conventions to follow;
which architecture to adhere to.

This is a considerable waste of time.

Claude Code offers a much simpler approach: place a CLAUDE.md file at the root of the project.

At each startup, the agent automatically reads this document and immediately retrieves the necessary context.

The benefit isn’t just about saving time.

The real advantage is reducing response variability.

When development rules are written in black and white, Claude no longer needs to deduce them. It applies them directly.

For complex projects, especially those with specific architectures or strong business conventions, this simple file quickly becomes one of the most valuable assets in the project.

🔒 Hooks: When Rules Become Automatic

Another common pitfall is asking the AI to follow certain rules while hoping it never forgets them.

This is rarely a reliable strategy.

Hooks allow you to move these rules out of the conversation to make them automatic.

Imagine a project containing critical files, environment variables, or infrastructure secrets.

Instead of constantly reminding Claude never to modify these elements, it becomes possible to technically block these operations.

The same principle applies to code quality.

Every modification can automatically trigger a linter, formatter, or a battery of checks before validation.

This shifts from a trust-based logic to a control-based one.

And as in any mature software architecture, automatic controls are generally more reliable than human reminders.

🤔 Ultrathink: A Resource to Use Sparingly

One of the most common mistakes is using deep reasoning capabilities for absolutely everything.

It’s tempting.

When a feature promises more reasoning, the instinct is to enable it permanently.

Yet, this is often counterproductive.

Requesting a complex architectural analysis to rename a variable is like convening the entire management committee to choose a button’s color.

Additional cognitive resources should be reserved for situations where they truly add value.

Architecture overhauls.

Particularly difficult debugging.

Risky technical migrations.

Analysis of a distributed system.

In these contexts, advanced reasoning mode can save considerable time.

For daily tasks, it mostly slows execution and increases context consumption.

As often in engineering, maximum power isn’t the optimal solution. The right strategy is to use the right power at the right time.

🧹 /compact: The Feature Many Discover Too Late

After several hours of work, a Claude Code session inevitably accumulates noise.

Logs.

Already resolved errors.

Abandoned hypotheses.

File excerpts that are no longer useful.

All of this consumes context and eventually degrades response quality.

The /compact command addresses this problem precisely.

It allows condensing the history while retaining only the truly important information.

But the mistake is running the command without prior thought.

The real trick is to explicitly guide the compaction.

Specify what should be kept.

Recall architectural decisions made.

Identify the project’s critical constraints.

The difference is huge.

Instead of getting a generic summary, you create a working memory optimized for the rest of the session.

👥 Subagents: The Feature That Scales

When a project becomes large, context becomes a precious resource.

Every file read, every log analyzed, and every library explored consumes part of this resource.

Subagents provide an elegant solution to this problem.

Rather than cluttering the main session with thousands of lines of logs or a full exploration of an external dependency, Claude can delegate this work to a secondary agent.

The latter performs its research in its own context space and returns with a usable summary.

The parallel with an engineering team is interesting.

The lead developer doesn’t necessarily read every line of documentation for every system component.

They delegate certain investigations to specialists and only retrieve the useful conclusions.

Subagents apply this exact principle to the world of AI agents.

🚀 The Real Productivity Multiplier

These features may seem independent.

In reality, they form a coherent system.

The CLAUDE.md file provides context.

Hooks ensure rule compliance.

ultrathink intervenes when complexity demands it.

/compact maintains a clean context.

Subagents absorb secondary tasks without polluting the main session.

Individually, each brings measurable gains.

Together, they completely change how you work with Claude Code.

Most developers are still trying to optimize prompts.

The most advanced teams are already optimizing the environment in which the agent works.

And that’s probably where the real competitive advantage lies today.

— Nicolas Dabène

Why You Should Almost Never Send a PDF, DOCX, or Image to ChatGPT or Claude

Nicolas Dabene — Sat, 27 Jun 2026 16:45:02 +0000

TL;DR

Most users try to reduce their AI bill by switching models.

GPT or Claude?

Pro version or API?

Smaller or larger context?

Yet in many cases, the real problem isn't the model.

The problem is what you send to it.

PDF, DOCX, PowerPoint, screenshots, images... all these formats were designed for humans. Not for LLMs.

Result:

more tokens consumed;
more context wasted;
higher costs;
sometimes even less relevant responses.

The best optimization is often not changing the model.

It's preparing documents better before sending them.

🚨 The Hidden Token Tax

When you send a document to an LLM, it doesn't "read" the file like you do.

Before even analyzing the content, it must understand:

where the text begins;
where the text ends;
which elements are headings;
which elements are paragraphs;
which areas represent a table;
which parts are decorative;
in what order the elements should be read.

In other words, some of your tokens are used solely to reconstruct the document's structure.

So you're paying for noise.

📄 Why PDFs Are Particularly Inefficient

PDF is probably the world's most popular document format.

But it was designed for printing.

Not for artificial intelligence.

A PDF mainly describes:

positions;
coordinates;
graphic blocks;
layout elements.

For a human, this is perfect.

For a model, it often requires preliminary reconstruction work:

determining the reading order;
reconstructing tables;
identifying headings;
understanding columns;
linking captions to images.

Some of the context is consumed before the business content is even analyzed.

📝 DOCX Files Aren't Much Better

Many think DOCX is naturally suited for LLMs.

That's not really the case.

A DOCX file contains:

text;
styles;
metadata;
layout information;
XML representation elements.

Even if the cost is generally lower than that of a complex PDF, a significant portion of the data sent doesn't directly contribute to understanding the document's business content.

🖼️ Images Are Often the Worst Case Scenario

The situation becomes even more costly when sending:

screenshots;
photos;
scanned documents;
slides exported as images.

Before understanding the content, the model must:

detect text;
perform OCR;
identify important areas;
reconstruct the logical structure.

You're asking the model to solve a vision problem before even addressing the business problem.

It's like photographing a sheet of paper and then asking someone to copy it before reading it.

📊 Not All Formats Are Equal

If the goal is to efficiently transmit information to an LLM, some formats are much better suited than others.

Format	Useful Signal	Structural Noise	Token Impact
Markdown	Very High	Low	Excellent
TXT	High	Very Low	Excellent
DOCX	Medium	Medium	Fair
Native PDF	Medium	High	Poor
Scanned PDF	Low	Very High	Very Poor
Image	Low	Extremely High	Catastrophic

This table summarizes a simple principle:

The closer a format is to structured plain text, the more efficient it is for an LLM.

💰 The False Debate: Changing Models

Most discussions revolve around questions like:

Which model consumes the least?

Which provider is the cheapest?

Which subscription offers the most context?

These questions matter.

But they often come too early.

Because before optimizing the engine, you need to optimize the fuel.

Reducing a model's cost by 30% is interesting.

Reducing the tokens sent with each request by 30 to 40% is often much more cost-effective.

And it generally improves response quality.

🚀 A Smarter Approach: Preparing Documents for LLMs

For a few months now, a new category of tools has begun to emerge.

Their goal isn't to create a new model.

Their goal is to better represent documents for existing models.

This is exactly the philosophy behind the DocLang project:

https://github.com/doclang-project/doclang

DocLang is an open-source project supported by the Linux Foundation AI & Data that starts with a simple observation:

PDF was designed for printing;
DOCX for editing;
HTML for display;
none of these formats were designed for LLMs.

DocLang's goal is therefore to provide an intermediate representation better suited to artificial intelligence.

Specifically, DocLang preserves:

document hierarchy;
headings;
sections;
tables;
metadata;
logical relationships between elements.

While removing much of the noise related to visual presentation.

The result:

more compact documents;
fewer tokens consumed;
better content understanding;
more effective context for AI agents and RAG pipelines.

According to figures published by the project, this approach significantly reduces the volume of tokens needed to represent a document while preserving its semantic structure.

🎯 The Real AI Challenge in 2026

For a long time, we optimized infrastructure.

Then we optimized models.

The next step is to optimize data.

In many AI projects, the biggest waste doesn't come from the model used.

It comes from how documents are prepared before ingestion.

Before searching for the next miracle model:

look at your prompts;
look at your workflows;
look at the files you send.

Because the easiest way to reduce your AI bill is often not to change models.

It's to stop sending it noise.

E-commerce Compliance: Why Some PrestaShop Modules Become Essential Building Blocks

Nicolas Dabene — Sat, 20 Jun 2026 08:00:02 +0000

Introduction: E-commerce Enters a New Phase

For a long time, the success of an online store has been associated with highly visible aspects: catalog performance, checkout optimization, SEO, or traffic acquisition. These elements remain fundamentally important, but modern online commerce now relies on a much broader set of constraints.

An e-commerce store is no longer just a showcase for selling products. It is an environment where customer experience, regulatory obligations, security, data protection, and technical quality converge. Even the slightest regulatory change can have concrete consequences on how a merchant must design their user journey.

The right of withdrawal is a particularly interesting example of this evolution. On paper, it is an obligation that merchants have long been aware of. In practice, integrating it into a PrestaShop store requires considering multiple dimensions: customer information, accessibility of the action, user journey, and consistency with the existing technical architecture.

It is in this context that certain modules take on particular value. Not because they add a spectacular feature, but because they transform a complex constraint into a simple experience for both the merchant and their customers.

The MedRetractation module, developed by Mediacom87, perfectly illustrates this approach.

Module link: https://www.prestatoolbox.fr/fonctionnalites-front-office/486-medretractation-bouton-de-retractation-legal-conformite-au-droit-de-retractation.html

When Compliance Becomes a Development Issue

Compliance in e-commerce has often been seen as a purely legal matter. However, in an online store, a regulatory obligation almost always ends up becoming a technical problem.

Information must be displayed in the right place. An action must be accessible. A journey must be adapted. Data must be stored or displayed correctly. Behind every business rule lies an implementation.

This is precisely where the expertise of a PrestaShop editor becomes crucial.

The merchant’s role is not to analyze regulatory changes, understand the subtleties of hooks, modify their theme, or maintain compatibility with different versions of the solution. Their job is to run their business.

The editor’s role is to take this complexity and make it invisible.

A good module is therefore not just an additional feature installed in a store. It is a layer of expertise that solves a specific problem without requiring the merchant to become a developer.

The Invisible Work Behind a PrestaShop Module

What is interesting about the work done by editors like Mediacom87 is that the real value of the product is not limited to what is visible in the interface.

Creating a PrestaShop module that meets a business need requires understanding multiple things simultaneously: the platform, merchant habits, technical constraints, version updates, and end-user expectations.

The difficulty is not just making a feature work today. The real challenge is creating a solution that continues to work tomorrow.

In the PrestaShop ecosystem, maintenance is essential. A store can remain in production for several years. A module must therefore evolve with it, keep up with version changes, and avoid becoming technical debt.

This is part of the editors' work that often goes unnoticed when everything functions correctly.

And ultimately, this might be the best sign of quality: when complexity disappears entirely for the end user.

MedRetractation: An Example of a Problem-Focused Module

What I find interesting about MedRetractation is not just the functionality it offers, but the problem it solves.

The module does not seek to transform the shopping experience with an additional marketing feature. It addresses a concrete need for merchants: properly integrating a legal obligation into the customer journey.

This approach represents a current trend in the e-commerce ecosystem. The best tools are not always those that add the most features, but those that reduce risks, simplify operations, and allow merchants to focus on their business.

In an environment where regulatory and technical expectations are increasing, these specialized building blocks are gradually becoming indispensable.

PrestaShop’s Strength Also Lies in Its Editors

One of PrestaShop’s great strengths is its ecosystem. The platform allows merchants to adapt their store to a wide variety of needs thanks to the modules developed around it.

But this ecosystem only works because editors invest time in creating and maintaining specialized solutions.

Behind every useful module, there is an understanding of the field: the problems merchants face, the technical constraints, and the necessary updates to keep a store reliable over time.

MedRetractation is a good example of this category of modules that do not necessarily seek to be the most visible but address a real operational need.

Conclusion: Value Often Lies in the Problems No One Wants to Handle

The future of e-commerce will not be built solely around new visible features. It will also depend on the ability to properly manage all the complexity behind an online sale.

Compliance, security, and reliability are becoming differentiating factors.

In this context, the role of PrestaShop editors becomes even more important: transforming sometimes complex constraints into simple, maintained, and accessible solutions.

This is exactly the kind of work that helps make an ecosystem like PrestaShop sustainable.

DEV Community: Nicolas Dabene

PHP 8.6 Enters Beta: What You Should Actually Start Looking At

The Sovereignty of E-Commerce: Why Open Source Could Be Tomorrow’s True Answer

Preparing Your Project Before Asking an AI for Code

TL;DR

The First Prompt Shouldn’t Ask for Code

Start with a Short Requirements Sheet

Define What "Done" Means

Choose a Stack Without Collecting Dependencies

Design an Architecture Small Enough to Be Understood

Write the Repository’s Permanent Rules

Ask for an Analysis Before Implementation

Prepare Git Before Letting the Agent Act

Preparation Is Already Part of Learning

You Have PrestaShop and ChatGPT? Here Are 6 Ways You Can Use AI Today Without Installing a Single Module

Table of Contents

Before You Start: AI Does Not Know Your Store by Magic

1. Turn a Supplier Product Sheet Into a Real Product Page

Ready-to-Copy Prompt

2. Prepare the SEO Elements of Your Product Page Without Starting Over

Ready-to-Copy Prompt

3. Prepare a Response to an Unhappy Customer Without Replying While You Are Frustrated

Ready-to-Copy Prompt

4. Get Insights From a PrestaShop CSV Export, Even If You Are Not a Data Analyst

Ready-to-Copy Prompt

5. Understand a PrestaShop Error Message Before Writing “It Doesn’t Work Anymore” to Your Agency

Ready-to-Copy Prompt

6. The Cherry on Top: Turn a Product Photo on a White Background Into a Lifestyle Visual

Ready-to-Copy Prompt

Now Look at Your Product. Really Look at It.

You Have Just Used AI With PrestaShop Without Connecting AI to PrestaShop

Claude Opus 5 and PrestaShop: When a More Powerful Model Becomes Truly Useful

TL;DR

The Subject Isn’t "A Better Chatbot"

What Opus 5 Can Bring to a PrestaShop Developer

Understand Before Fixing

Maintain a Redesign Across Multiple Layers

Conduct a Review That Goes Beyond Style

What a PrestaShop Merchant Can Actually Gain

Investigate a Commercial Anomaly Without Inventing an Explanation

Control Operations That Cost Dearly When They Fail

Assist Support, But Without Letting It Decide Alone

Where Opus 5 Is Oversized

Who Is Opus 5 Really For?

For Developers and Agencies

For Merchants

The Right Model in the Right Place

Getting Started with Claude Code or Codex Without Becoming Dependent on AI

TL;DR

A Working Application Doesn’t Prove You Know How to Code

AI Removes Friction—Including the Kind That Helps You Improve

Our Guiding Example: A Mini-Dashboard

The Five-Verb Method

1. Understand

2. Attempt

3. Ask

4. Verify

5. Explain

A First Prompt That Protects Learning

Claude Code or Codex: The Method Remains the Same

The Right Metric Isn’t the Number of Lines Produced

Agile is Dead? Welcome to the Era of Agent-Driven Development

The Bottleneck Is Shifting

Yes, a Certain Form of Agile Is Probably Dying

No, Agile Is Probably Not Dead

From Tickets to Intent

The Real Problem Will Be Validation

The Developer Won’t Become a "Prompt Engineer"

Welcome to the Era of Agent-Driven Development

Why 2026 Proved PrestaShop Right

🔄 Revisiting a 2025 Prediction

🤝 The False Debate Between PrestaShop and Sylius

🌍 What EO2S Really Demonstrated

🏛️ The Real Asset: Longevity

🤖 The AI Paradox

🚀 The Signal Sent by the PS Summit

🎯 The Real Lesson of 2026

Conclusion

ChatGPT Work: The Chatbot Becomes a Work System

🧠 This is not a new conversation mode