DEV Community: Nicolas Dabene

Using Claude Code or Codex as a Teacher, Not an Autopilot

Nicolas Dabene — Sat, 29 Aug 2026 04:54:34 +0000

Learning to code with AI doesn’t mean letting the AI do the work for you. It means using AI as a thought partner that sharpens your reasoning, uncovers gaps in your understanding, and guides you toward solving problems yourself. When you treat an AI coding agent like a teacher—not an autopilot—you build deeper knowledge, avoid shallow fixes, and gain confidence to tackle new challenges.

Here are four ways to turn your AI assistant into a powerful mentor instead of a shortcut.

1. Make the AI Ask You the Questions

Instead of asking for code immediately, ask the AI to guide you through the problem by asking you questions. For example, if you’re building a dashboard that fetches metrics, prompt the AI to verify your understanding of where the API call should happen, how to handle loading and error states, and why TypeScript types alone aren’t enough to validate real-world data. This forces you to articulate what you know—and exposes what you don’t—before seeing a single line of code.

2. Demand Progressive Hints, Not Instant Fixes

When you’re stuck on an error, resist the urge to ask for a full solution. Request a sequence of help: first a guiding question, then a conceptual hint, then a minimal example, and only finally the correction—if you still need it. This scaffolding ensures help arrives only when your own attempts have failed, reinforcing problem-solving habits rather than dependency.

3. Analyze Your Flawed Attempts

Share your imperfect code with the AI and ask it to rephrase what your code does, identify what’s correct, highlight the two biggest risks, and pose a question that leads you to the next fix. This turns your mistakes into learning material. You’ll realize, for instance, that fetch can fail, HTTP errors must be handled, and response.json() returns unvalidated external data—lessons that stick when you discover them through reflection, not correction.

4. Compare Trade-offs, Don’t Just Accept the First Answer

AI often presents one solution as “the right way.” But real development is about trade-offs. Ask the AI to generate two approaches—like fetching metrics directly in a server page versus through an API route—and compare them based on simplicity, security, caching, testability, and error handling. The goal isn’t to pick the fanciest solution, but to understand why one fits your context better than another.

The key isn’t to avoid AI, but to use it in a way that strengthens your judgment. Over time, your prompts will become sharper, your understanding deeper, and your reliance more intentional. You’ll learn to spot when the AI is steering you right—and when it’s missing the mark.

https://nicolas-dabene.fr/en/blog/using-claude-code-or-codex-as-a-teacher-not-an-autopilot/

Contrib.: When E-commerce Speaks Up from the Field

Nicolas Dabene — Sat, 22 Aug 2026 04:34:10 +0000

E-commerce is flooded with hype cycles that promise quick fixes through AI, SaaS, or automation. Yet behind every “definitive narrative” lurks real consequences: platform lock-in, hidden costs, and irreversible technical debt. Few voices cut through the noise by focusing on the field-level realities merchants and agencies face daily.

Contrib. is a long-form podcast that bridges this gap. Produced by Friends of Presta, it pairs deep technical insight with hands-on business experience to ask the questions that matter: who controls your stack, who owns your data, and what happens when a platform changes the rules? It’s not about endorsing or rejecting technology—it’s about understanding the trade-offs before they become crises.

Here are four takeaways from the show that reframe how we think about e-commerce decisions:

Dependency is the silent killer of margins
Episodes like “Shopify Cuts You Off Overnight, Google Finishes the Job” expose how platform policies or API changes can erase years of visibility and revenue overnight. The cost isn’t just downtime—it’s the loss of control over your own customer journey.
AI won’t replace strategy—it demands it
In “Will AI Replace Everything? SEO, Agencies, Redesigns: Debunking 3 Myths,” the hosts dismantle the myth that AI eliminates the need for foundational work. Instead, they argue that AI amplifies the importance of clear goals, accountability, and reversibility in any redesign.
Sovereignty isn’t automatic
Open source doesn’t guarantee independence, and proprietary tools don’t always create captivity. The real test is reversibility: can you migrate your data, skills, and processes without catastrophic disruption? Contrib. forces this conversation into the spotlight.
Europe’s window to act is closing
With “AI, Sovereignty, and E-commerce: Europe Has 2 Years to React,” the podcast highlights how cloud and AI model dependencies threaten European brands and agencies. The message is clear: the time to build alternatives is now, before external shocks force the issue.

The podcast’s strength lies in its hosts. Thomas Rayrat brings infrastructure and cybersecurity expertise from Profileo and Friends of Presta, while Christophe Vidal combines hands-on e-commerce operations (€7M+ revenue store) with SEO and agency leadership. Their complementary perspectives avoid both blind techno-optimism and reflexive resistance, grounding each topic in real operational constraints.

Contrib. isn’t here to sell a solution—it’s here to sharpen your decision-making. Whether you’re a merchant, developer, or agency leader, the show equips you to ask better questions before committing to a platform, tool, or trend.

Listen to the first five episodes on YouTube, Spotify, or your preferred podcast app, and follow Contrib. on LinkedIn for ongoing insights.

Vibe Coding vs Prompt-Driven: One Year Later, the Debate Is Already Outdated

Nicolas Dabene — Thu, 20 Aug 2026 06:51:38 +0000

A year ago, the debate between “vibe coding” and “prompt-driven development” felt like the right lens for using AI in software. Today it’s outdated. The real frontier is no longer how to phrase a request, but how to build an environment that lets an AI agent explore, modify, and verify code safely. The shift from conversational prompts to structured development harnesses changes what it means to ship reliable software.

Below are four concrete ways this evolution is reshaping daily work.

From Prompt to Harness
A finely crafted prompt can still produce a working feature, but it won’t prevent an agent from inventing APIs, skipping tests, or misreading business rules. The new bottleneck is the harness: Git for traceability, tests for feedback, linting for style, and explicit rules for constraints. When these elements are in place, even a short instruction like “fix the bug” can trigger a reliable, auditable workflow.
Code is Abundant; Good Software is Rare
Generating hundreds of lines of code costs almost nothing, but verifying that those lines align with product history, security policies, and hidden constraints is still manual. The developer’s scarcest resource is now judgment: deciding what to automate, what to document, and when to override the agent’s plausible but wrong solution.
Documentation is Now for Machines
README files and ADRs used to serve only humans. Today they also feed the agent’s context. A well-maintained AGENTS.md, coherent tests, and executable examples let an AI act with minimal prompting while remaining aligned with the team’s conventions. The repository becomes a self-explaining environment.
Supervision is the Next Skill
Single-agent workflows are giving way to multi-agent orchestration. Frontend, API, test analysis, and incident triage agents must coordinate without stepping on each other. Observability, conflict detection, and rollback mechanisms replace prompt tuning as the critical layer of control.

The center of gravity has moved from “how to ask” to “how to let the AI work safely.” If you’re still optimizing prompts, you’re optimizing the wrong layer. Invest instead in tests, rules, and traceability—the new primitives of agentic development.

https://nicolas-dabene.fr/en/blog/vibe-coding-vs-prompt-driven-one-year-later-the-debate-is-already-outdated/

Finding, Verifying, and Adapting the Right Skills for Your Project

Nicolas Dabene — Sat, 15 Aug 2026 03:57:35 +0000

Skills are reusable workflows, not magic knowledge pills. Before you install one, inspect its source, versions, and effects to confirm it fits your project. Start with a few focused skills and adapt them to what already exists.

A skill is a set of instructions and scripts that lets an agent reproduce a specialized method. It doesn’t guarantee best practices or compatibility with your repository. The official documentation for tools like Claude Code and Codex explains how skills work under the hood.

Project rules, documentation, and skills serve different purposes. Official documentation describes technology features, repository conventions are captured in files like AGENTS.md, and skills provide reusable workflows. Mixing these roles leads to confusion and wasted context.

Start your search in this order: official skills from the tool’s publisher, official technology docs, resources from recognized organizations, manually inspected community skills, and finally skills you create specifically for your project. Stars and downloads can signal adoption, but they don’t prove correctness.

Before adding a skill, verify its origin, technical currency, possible actions, and compatibility with your project. Ask who maintains it, which versions it targets, whether it contains executable scripts, and whether it respects your existing architecture. If a script is unclear, don’t run it just because it comes with a skill.

Contradictory skills increase noise and make decisions harder to explain. Two or three reliable workflows are more useful than a collection of twenty skills. For a mini-dashboard, start with a TypeScript review, a React and Next.js review, and a testing strategy tailored to expected behaviors.

If no reliable skill matches your needs, write a short procedure adapted to your repository. A minimal skill can formalize a specific review, like verifying that a dashboard metric is typed, validated, displayed, and tested correctly. This keeps the workflow focused and reproducible.

Test a skill without entrusting it with your project. Start with a read-only task that asks the agent to apply the workflow and report observations without modifying files. Evaluate the results for accuracy, specificity, and compatibility before giving the skill more influence.

For an existing project, inventory dependencies, conventions, scripts, tests, and architectural decisions. Adapt skills to what already exists rather than replacing existing tools without reason. The skill serves the project; the project shouldn’t warp to satisfy the skill’s preferences.

A good skill reduces repetitive errors and makes a method explicit, but it doesn’t replace human oversight. Junior developers build competence by learning to decide whether an instruction is correct, current, useful, and verifiable.

https://nicolas-dabene.fr/en/blog/finding-verifying-and-adapting-the-right-skills-for-your-project/

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.

DEV Community: Nicolas Dabene

Using Claude Code or Codex as a Teacher, Not an Autopilot

Contrib.: When E-commerce Speaks Up from the Field

Vibe Coding vs Prompt-Driven: One Year Later, the Debate Is Already Outdated

Finding, Verifying, and Adapting the Right Skills for Your Project

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