DEV Community: Nicolas Dabene

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.

Contrib.: When Media Must Evolve with Communities

Nicolas Dabene — Thu, 18 Jun 2026 03:45:03 +0000

Introduction

We live in a time when access to information has never been easier. In just a few seconds, it’s possible to find an analysis, a video, a podcast, or a summary on almost any topic. Yet, this abundance creates a new challenge: it’s no longer information that’s lacking, but our ability to understand it, sort through it, and give it meaning.

Current technological transformations, particularly around artificial intelligence, are profoundly changing our relationship with knowledge. Tools are becoming increasingly powerful and accessible, but the real value is gradually shifting toward the ability to analyze, question, and participate in the decisions that will shape our future.

It’s in this context that the Contrib. initiative is interesting. The project doesn’t position itself solely as a podcast or a media outlet covering tech, business, and digital sovereignty. It seeks to experiment with a different relationship between those who produce information and those who consume it.

From Audience to Community

For a long time, the traditional media model relied on a fairly simple relationship: people produced content, and an audience came to consume it. This model enabled the creation of many benchmarks, but the digital world has deeply changed expectations.

Today, a community no longer just wants to receive information. It wants to understand, exchange, challenge ideas, and sometimes participate directly in shaping the topics. The value is no longer found solely in the published content but also in the interactions it sparks.

This is precisely what makes Contrib.’s approach so interesting. The project’s name itself carries an intention: to put contribution at the center. The idea isn’t just to create a media outlet that talks about transformations but a space where those involved can participate in the reflection.

This approach echoes certain principles found in the open-source world. A project doesn’t progress solely thanks to its initial creators but through all the people who use it, test it, propose improvements, and enrich the ecosystem.

Technology Advances, but Understanding Remains Essential

Artificial intelligence perfectly illustrates this evolution. Models are now capable of producing text, images, code, or analyses at an impressive speed. But having a powerful tool doesn’t automatically mean knowing what to do with it.

The central question is no longer just: "What technology is coming?" It has become: "How will we intelligently integrate it into our professions, businesses, and society?"

Specialized media thus have an evolving role. Their mission can no longer be limited to reporting on new developments. They must help us understand the implications, provide context, and enable people to step back from rapid changes.

This is also why topics around digital sovereignty are becoming important. Sovereignty isn’t just about infrastructure or data. It’s also about our collective ability to understand the tools we use and to avoid letting only a few actors decide the direction we take.

Building the Reflection Spaces of the Future

The next generation of media will likely be defined less by the quantity of content produced than by the quality of the communities built around that content.

In a world where artificial intelligence will be able to generate ever more information, what will become rare is high-quality human exchange: discussions, shared experiences, constructive disagreements, and the ability to develop a common vision.

Initiatives like Contrib. are exploring this direction by trying to bring media closer to its community. Content becomes a starting point, not an end in itself. Discussion becomes an integral part of the value created.

This is an interesting evolution because major technological transformations won’t be defined solely by the tools we use. They’ll also be defined by the spaces we build to discuss them and the collective decisions we make.

Conclusion

We cannot stop the transformations that are coming. Artificial intelligence, new technologies, and new economic models will continue to evolve.

However, we can choose our stance in the face of these changes. We can be mere spectators, or we can actively participate in shaping the future.

The approach taken by Contrib. offers an interesting perspective: in a world where information is becoming abundant, contribution may become a new form of value.

Understanding the future isn’t just about observing it.

It’s also about taking part in building it.

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

Nicolas Dabene — Wed, 17 Jun 2026 16:30:02 +0000

Introduction: After AI Sovereignty, E-Commerce Sovereignty

For the past few months, one word has been coming up more and more in discussions about artificial intelligence: sovereignty.

Who owns the models?
Who controls the data?
Who sets the access rules?
What happens when a critical technology depends on an external player?

These questions don’t just apply to AI.

They’ve existed for a long time in the world of e-commerce.

When a merchant builds their business on a platform, they make a strategic choice. They choose a technical foundation, an ecosystem, a vision of digital commerce.

And behind this choice lies a fundamental question:

Are we the owners of our digital commerce, or merely users of a service we depend on?

This is precisely why the future of open source in e-commerce deserves close attention.

A Question I Receive Regularly: Is PrestaShop Still Viable?

Lately, I’ve received several messages from merchants asking a simple but revealing question:

"Is PrestaShop still viable today?"

This question doesn’t come out of nowhere.

The e-commerce market is accelerating. Artificial intelligence is transforming usage. Architectures are evolving. Major cloud and SaaS platform players are strengthening their positions.

In this context, some may feel that historical open-source solutions are doomed to disappear.

My answer is clear:

Yes, PrestaShop is still viable. In fact, I think we’re at a new stage in its history.

Not because the past must be preserved at all costs.

But because open source addresses an issue that is becoming increasingly important: maintaining control.

The Acquisition of PrestaShop: A Transition to View Differently

The acquisition of PrestaShop by the ecosystem led by cyber_Folks, Sylius, and BitBag has naturally sparked many reactions.

Some saw it as a loss of independence.

For my part, I think we need to look at this development through a different lens.

The issue isn’t just about who owns a company.

The real issue is understanding the direction the ecosystem is taking.

And what’s interesting today is the meeting of two complementary worlds.

On one side, PrestaShop has a strong history in online commerce, with a community, thousands of stores, and an ecosystem built over the years.

On the other, Sylius offers a more modern vision of e-commerce development, with a framework-oriented approach, flexibility, and scalable architectures.

This combination could open a new chapter.

Not the disappearance of PrestaShop.

An evolution.

The challenge isn’t to remain frozen in what e-commerce was ten years ago.

The challenge is to build the foundation for the next ten years of e-commerce.

Open Source as a Strategic Answer

In a world where businesses are becoming dependent on technological building blocks they don’t always control, open source offers something rare:

the ability to understand, adapt, and evolve your tool.

This doesn’t mean open source is magical.

An open-source solution can fail if it doesn’t evolve.

It can become obsolete if its community disappears.

It must continue to innovate.

But it has a structural strength: it doesn’t rely solely on a commercial promise.

It relies on an ecosystem.

This is also why the activity around PrestaShop remains an important signal.

Communities like Friends of Presta continue to unite field players. Events like EO2S 2026 show that there’s still energy around this technology.

A living project isn’t just source code.

It’s a community that continues to build.

The PSE: A Negative Signal or a Difficult Choice in a Time of Acceleration?

The announcement of PrestaShop’s PSE (Performance and Sustainability Plan) has obviously raised concerns.

This is understandable.

When a company reduces its workforce, the first reaction is often to interpret it as a sign of retreat.

But I think we should also consider this decision in the current context.

The tech industry is going through a period of brutal transformation.

Artificial intelligence is changing development methods, production cycles, user expectations, and business models.

In this context, all organizations must rethink how they operate.

This doesn’t automatically mean the end.

It can also be an attempt at deep transformation.

Is it a risky bet? Yes.

But sometimes, not changing is an even greater risk.

The Interesting Signal: PrestaShop Begins to Look at the AI Era

Another element seems particularly interesting to me: the presence of the .ai directory in the PrestaShop repository.

This is not a trivial detail.

The e-commerce of tomorrow won’t just be a store with a catalog and a checkout process.

It will be augmented by agents, assistants, automations, and systems capable of helping make decisions.

The real question will then be:

Who will control these intelligences?

A closed platform that imposes its own rules?

Or an open ecosystem where merchants can choose, adapt, and integrate their own solutions?

E-commerce sovereignty and AI sovereignty will likely converge.

Will the Future of E-Commerce Be Open?

I don’t think the future will simply pit open source against SaaS.

Both models will likely continue to coexist.

But in a world where every business is becoming dependent on its digital tools, the ability to maintain control is becoming a strategic advantage.

E-commerce is no longer just about selling online.

It’s a question of infrastructure.

And critical infrastructure must be mastered.

This is why I believe PrestaShop, with its history, its community, and this new phase alongside players like Sylius, has an important card to play.

Not by looking at the past.

But by building the next chapter.

The real question may no longer be:

"Which platform should we choose?"

But rather:

"Who do we want to let control the digital commerce of tomorrow?"

PrestaShop #OpenSource #Ecommerce #AI #DigitalSovereignty

The CRT Method for Developers: Mastering the Art of Prompt Engineering

Nicolas Dabene — Sun, 07 Jun 2026 09:00:03 +0000

1. Introduction: Moving Beyond the "Fuzzy Prompt" in Development

In today's software engineering ecosystem, productivity no longer depends solely on mastering syntax but on the ability to transform a vague intention into an actionable technical instruction. The major challenge developers face isn’t what they ask AI, but the imprecision of the request.

When a developer submits a "Fuzzy Prompt," the AI instantly becomes a guessing machine. It must fill in the user’s gaps by improvising on technical level, coding standards, or architectural constraints. For developers, this "guesswork" translates into costly operational friction: off-topic code, immediate technical debt, or dangerous hallucinations in business logic. The CRT method (Context, Role, Task) acts as a "mini-request architecture," structuring the exchange to shift from a mere text generator to a true engineering partner.

2. Anatomy of the CRT Method: Context, Role, Task

The CRT method is a minimal framework designed to eliminate ambiguity. In prompt engineering, the goal isn’t to write novels but to clarify critical variables so the AI stops interpreting and starts executing.

Breakdown of the Three Pillars

Context: Defines the request’s environment. Who is the target audience? What is the tech stack? What is the overall goal? Context fuels the response by providing the necessary data for reasoning.
Role: The identity adopted by the AI calibrates tone, precision level, and standards. Requesting an expert role avoids outdated solutions (e.g., PHP 5.6 instead of 8.2) and ensures professional rigor.
Task: The precise action. Pro tip: The "next-level" approach is to not ask for the final code immediately but to first demand a plan, structure, or clarification questions.

Summary: Fuzzy Prompt vs. CRT Prompt

Aspect	Fuzzy Prompt (Guessing Machine)	CRT Prompt (Engineered Request)
Example	"Help me with an API."	C: Beginner video on digital culture. R: Technical popularization expert. T: First propose a structured script outline.
Effect	AI improvises level and format.	AI produces a result aligned with the goal.
Risk	Hallucinations and mismatched code.	Surgical precision and time savings.

This structure is the bulwark against unusable results that clutter the development cycle.

3. Practical Case 1: Developing a Prestashop Module

Working with a CMS like Prestashop requires strict contextual rigor to avoid code incompatible with modern versions (Prestashop 8.x).

CRT Application

Prompt:

Context: Creating a promotions management module for Prestashop 8.1, targeting B2B merchants.
Role: Senior Prestashop Expert adhering to PSR-12 standards and the CMS’s Symfony structure.
Task: First propose the list of required hooks (e.g., actionCartSave) and the file tree before generating any code.

Analysis: By forcing the AI to validate the technical structure and hooks before implementation, we prevent it from generating obsolete monolithic code. The Senior Expert role ensures the use of namespaces and modern service containers instead of legacy static classes.

4. Practical Case 2: Laravel Architecture and Logic

In modern frameworks, AI excels at structuring business logic—if guided on architectural patterns.

CRT Application

Prompt:

Context: Payment microservice in a Laravel 11 application following hexagonal architecture principles.
Role: Software Architect specializing in Clean Code.
Task: Sketch the interface contract and PaymentService class structure with dependency injection. Ask me 3 clarification questions about payment gateways (Stripe/Adyen) before proceeding.

Justification: Here, the Task prioritizes design. Requesting an "interface contract" enforces decoupling rigor that the AI would overlook in a fuzzy prompt. This prevents spaghetti code and reduces technical debt from the outset.

5. Practical Case 3: Brainstorming a New Feature

AI isn’t just an executor—it’s a co-creation partner. Using CRT in brainstorming turns the tool into a strategic consultant.

CRT Application

Prompt:

Context: Gamification feature for a B2B productivity SaaS. Goal: Increase monthly retention.
Role: Product Designer specializing in engagement psychology (Gamification).
Task: Don’t propose solutions yet. Ask me 5 critical questions to identify my technical constraints and the user behaviors I want to encourage.

The Collaborative Approach: This method flips the burden of proof. Instead of expecting a perfect answer on the first try, we use AI to spotlight the project’s blind spots, refining the initial intent before production.

6. The Collaborative Approach: Using AI to Refine the Prompt

Shifting from a "command prompt" to a "conversational prompt" is the real paradigm shift. The first prompt should often just initiate a clarification phase.

Collaborative Optimization Strategies

Mirror Prompt: "Here’s my technical intent [Intent]. Identify the fuzzy areas you’d have to guess to respond, and ask me questions."
Triangulation: "Propose a simple, precise, and advanced version of this prompt for my needs."
Self-Improvement: "Act as a Prompt Engineering expert. Rephrase my initial request to maximize generated code quality per SOLID standards."

Beyond the Prompt: Context Engineering
If Prompt Engineering structures the request, final quality also depends on the data provided. The "next level" is Context Engineering: feeding the AI your own documentation, config files, or style guides so it stops guessing and reasons within your actual environment.

7. Practical Tool: Universal CRT Prompt Template

Use this template to standardize exchanges and automate clarity in your daily workflow.

# CONTEXT
[Project, tech stack, version, target audience, overall goal]

# ROLE
[Expert/Architect/Educator – Defines standards and tone]

# TASK
[Precise action. Request structure/questions before the final output]

# CONSTRAINTS & FORMAT
[Output format (JSON, Markdown, Code), what to avoid, PSR standards, etc.]

Golden Rules for Execution:

Precision beats length: Don’t write a novel—clarify friction points.
Humans are sovereign: AI proposes and rephrases; the developer validates and directs. Human validation remains the only safeguard against business logic errors.
Iterate systematically: The best prompt is rarely the first; it’s the product of mutual clarification.

AI performance isn’t about "magic"—it’s a direct reflection of your instructions’ intelligence. By structuring requests with the CRT method, you stop enduring the machine’s guesswork and start piloting a robust, predictable work assistant.

AI is a Super-Fuel, Don't Let It Turn Into a "Slop" Factory

Nicolas Dabene — Sat, 06 Jun 2026 09:45:03 +0000

People talk about Artificial Intelligence all day long. For some, it’s a magical revolution; for others, an invisible threat. In reality, AI is neither: it’s an amplifier.

When used wisely, it boosts our creativity and productivity. Left to its own devices, without human oversight, it generates a new kind of nuisance that is starting to flood our daily lives: "AI Slop" (or digital sludge).

Here is why it’s urgent to understand this phenomenon and learn how to protect ourselves from it.

1. AI as a Co-pilot: The Bright Side

Before talking about what goes wrong, let's remember an essential truth: generative AI (like ChatGPT) is a fantastic tool. It doesn't replace humans; it’s an idea accelerator.

Got writer's block? It can give you an outline in three seconds.
Need a sounding board? It helps structure your arguments, find counter-arguments, or simplify a complex concept.
Writing issues? It polishes the tone of an important email.

In these cases, humans remain in control: you bring the expertise, the direction, and the critical thinking. AI is just the pen.

2. "AI Slop": When the Machine Runs on Empty

The problem arises when humans are removed from the equation. That’s where Slop comes from.

Definition: AI Slop is any text, visual, or audio content generated in bulk by AI and dumped onto the web without any verification, review, or added value.

It’s the fast food of information. We find it in several forms:

Endless blog posts that beat around the bush just to please Google's search algorithms.
Weird images on social networks (like those bizarre AI-generated photos of children or strange structures) designed solely to trick unsuspecting users into clicking.
Error-ridden practical guides sold on Amazon, written in three clicks by robots.

The goal of Slop is never to inform, educate, or entertain. Its sole purpose is to take up visual space to generate ad revenue from your clicks.

3. Why Is This Dangerous?

If it were just poor-quality content, it would only be an aesthetic issue. But Slop poses three major risks for all of us:

Information drowning: It’s becoming increasingly harder to find reliable, human-verified information in an ocean of text generated by the mile.
Trust pollution: By constantly encountering empty or false content, users end up doubting everything, even legitimate sources.
Lack of substance: An AI doesn’t "think." It predicts logical words one after another. Without control, it can state absurdities with perfect confidence (what we call hallucinations).

4. Survival Guide: How to Spot Slop

To avoid getting fooled, develop a few simple reflexes:

The "lukewarm water" style: Does the text use grandiose but empty phrases? (e.g., "In the ever-evolving landscape of...", "It is crucial to understand that..."). If the text is polite, long, but takes no stance and provides no concrete anecdotes, be suspicious.
Lack of a real source or author: Who wrote this article? Is it a real researcher, a journalist, an expert with a track record, or an anonymous profile created three days ago?
Absurd visual details: For images, look closely at the hands (often six fingers or strange shapes), blurry or illogical backgrounds, and textures that are too smooth, almost "plastic-like."

In Conclusion: Demand Substance, Stay Human

Artificial Intelligence is a historic opportunity to free ourselves from repetitive tasks and stimulate our intellect. But just like with food, we must become demanding consumers. Reject textual sludge; look for critical thinking, nuance, and the human touch. This is the only way to ensure that AI remains at our service, not the other way around.

AI at the Crossroads: Between the Profitability Mirage and the Reality of Efficiency

Nicolas Dabene — Thu, 04 Jun 2026 22:15:03 +0000

Generative artificial intelligence is undergoing a brutal transition phase. The euphoria of early deployments is giving way to an uncompromising demand for financial return. As a FinOps strategist, my observation is clear: AI is not a magic solution; it is a power infrastructure. Without rigorous resource management and a dedicated architecture, it risks becoming the greatest value destroyer of the decade. The time for experimentation is over; the focus is now on the industrial mastery of ROI.

1. The Profitability Paradox: From "Capex" to the Wall of Realities

The enthusiasm for generative AI is colliding today with a fundamental question posed by Jim Covello (Goldman Sachs): "What $1 trillion problem does AI actually solve?". The gap between massive investments and actual revenues is abyssal. According to Sequoia Capital, the industry must generate $600 billion per year to justify current infrastructure expenditures (Capex). However, the market leader OpenAI peaks at $3.4 billion in revenue. By comparison, Microsoft alone forecasts $190 billion in Capex for calendar year 2026 to expand its computing capabilities.

We are reliving the railway analogy: a phase of massive over-investment necessary to build a foundational infrastructure, where only the players capable of mastering their operational costs will survive the bursting of the bubble.

This discrepancy illustrates the "Solow Paradox," updated by McKinsey: AI is everywhere except in productivity statistics. Two factors explain this lag:

The "J-Curve" of adoption: As indicated by Governor Michael Barr (Fed), initial adjustment costs lead to short-term losses before real gains materialize.
Competitive erosion: Horizontal productivity (simple chatbot usage) does not create a sustainable advantage. It becomes "table stakes," with the gains captured by the end consumer rather than by the company's margins.

Transition: This lack of profitability is not a technological fatality, but the symptom of unmanaged resource consumption.

2. The Token as a Natural Resource: Toward an Ethic of Consumption

We must stop viewing the "Token" as an IT abstraction. Every token is the physical product of massive energy and freshwater consumption. AI's ecological footprint is now an operational reality: pollution in rural communities adjacent to data centers and skyrocketing electricity bills.

From a FinOps perspective, algorithmic inefficiency must be treated as industrial waste. A prompt of 1,000 tokens where 50 would suffice is not a mistake; it is a waste of financial and natural capital. Every unnecessarily verbose interaction reduces your margins and degrades your carbon footprint. The sustainability of businesses will depend on their ability to establish consumption discipline: every generated token must have clear attribution and demonstrable business value.

Transition: The solution to this waste lies in education: Prompt Engineering must become an organizational survival skill.

3. The Professionalization of AI: Prompt Engineering for All

Prompt Engineering training is not a luxury for developers; it is the bedrock of operational efficiency. The lack of expertise is the primary failure factor in AI projects. Data from FullStack and Gartner leave no room for doubt:

85% of AI projects fail due to poor data quality or a lack of skills.
A 50% talent gap paralyzes the deployment of solutions.

Without training, AI remains a "gadget" whose logical errors prove costly. Prompt Engineering allows a transition from generalist AI (Horizontal AI)—which dilutes value—to precision AI (Vertical AI). A trained employee knows how to reduce informational "noise," thereby limiting token consumption while increasing the relevance of the output. This is where waste reduction occurs: moving from a trial-and-error approach to response engineering.

Transition: However, human skill must be backed by a software architecture designed for yield.

4. The Architecture of Efficiency: Specialized Agents and FinOps

To maximize ROI, we must abandon the "one model for everything" paradigm. Using a Frontier model (such as GPT-4o or Claude Opus) for a simple classification task is an economic aberration. The winning strategy relies on Model Tiering and technical optimization.

Using tools like vLLM, throughput can be multiplied by 3 to 6 times, while prompt compression via LLMLingua reduces input size by a factor of 20 with minimal performance loss. Implementing semantic caching (Alice Labs) completely eliminates inference costs for recurring queries, reducing API expenditures by up to 80%.

Dimension	Uncontrolled AI (Shadow AI)	Architected AI (FinOps)
Cost Model	Explosive and unpredictable API costs	Mastered Unit Economics
Model Selection	Systematic use of Frontier models	Model Tiering (Nano vs Frontier)
Token Cost (1M)	~$15.00 (Frontier)	$0.10 (Nano/Small)
Governance	No visibility	Tagging, Attribution & Showback
Efficiency	Redundant inferences	Semantic caching
Latency	High (heavy models)	Optimized via compression & cache

This approach transforms AI from a speculative cost center into a sustainable infrastructure capable of absorbing scale without a linear correlation in costs.

5. Conclusion: Defining a Framework for Reasoned AI

The success of AI will not be measured by the volume of your investments, but by the precision of your management. A successful adoption rests on three non-negotiable pillars:

FinOps Governance: Implement a systematic tagging and attribution system for every API call to enable chargeback/showback between departments.
Mass Training: Elevate the skill level in Prompt Engineering to transform every employee into a digital resource manager.
Specialized Architecture: Deploy micro-agents and small models (Small Parameter Models) for vertical tasks, reserving expensive models for complex problems.

AI is no longer a bubble to be contemplated, but a resource to be administered. Shift from being a passive consumer suffering from bills to a responsible driver of your digital efficiency.