DEV Community: Nicolas Dabene

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.

`/grill-me`: The Command That Stops AI Agents From Coding the Wrong Thing

Nicolas Dabene — Fri, 29 May 2026 05:22:18 +0000

TL;DR

Most AI agent failures don’t come from bad code.
They come from bad assumptions.

In Antigravity, the /grill-me command forces the agent to stop executing… and start thinking.

Instead of generating code immediately, the agent:

asks questions,
clarifies requirements,
identifies blind spots,
challenges technical decisions,
validates the architecture before writing a single line of code.

And honestly?

It’s probably one of the best habits you can adopt when working with AI agents.

🤖 The Real Problem With AI Agents

Modern AI agents are impressive.

You tell them:

“Build me a PrestaShop module with API synchronization and an admin dashboard.”

And they immediately start building.

The problem:
they often start moving… in their own direction.

Why?

Because an AI agent:

fills in the blanks,
interprets intent,
assumes constraints,
invents business behaviors.

The result:
you sometimes end up with:

the wrong architecture,
incorrect business assumptions,
an unwanted tech stack,
unmaintainable technical decisions,
or simply… something that doesn’t match your real need.

The worst part?

The code can still be technically good.

But completely off target.

🔥 `/grill-me` Completely Changes the Dynamic

The /grill-me command changes how the agent behaves.

Instead of:

“I’ll start coding immediately.”

The agent switches to:

“First, I need to fully understand what you want.”

It becomes a technical interrogation.

The agent starts to:

ask targeted questions,
request examples,
clarify edge cases,
verify constraints,
identify ambiguities,
validate priorities,
anticipate architectural problems.

And that changes everything.

🧠 Why This Approach Is Extremely Powerful

1. It Reduces Business Hallucinations

AI agents rarely hallucinate syntax.

They mostly hallucinate:

intent,
requirements,
workflows,
implicit business rules.

/grill-me drastically reduces this problem.

2. It Forces Requirement Clarification

Most projects start with vague specifications.

And very often:
even the human developer hasn’t fully clarified the need yet.

/grill-me then acts like:

an architect,
a Product Owner,
a tech lead,
a functional challenger.

The agent becomes a requirement refinement tool.

3. It Prevents Bad Starts

A bad AI-driven start is expensive:

refactoring,
rewrites,
context loss,
technical debt,
fragile architecture.

A few minutes of intelligent questioning can save hours of corrections later.

⚙️ A Concrete Example

You ask:

“Build me an ERP synchronization system for PrestaShop.”

Without /grill-me, the agent could:

choose the wrong sync strategy,
assume real-time flows,
ignore scalability constraints,
create a non-scalable architecture,
forget retries,
ignore data conflicts.

With /grill-me, the agent could ask:

What is the source of truth?
Is synchronization bidirectional?
What is the product volume?
Real-time or batch processing?
Conflict resolution strategy?
Expected SLA?
Multi-store support?
Target PrestaShop compatibility?
REST or SOAP API?
Retry management?
Queue system?
Is idempotency required?
Failure tolerance expectations?

And suddenly:
we’re no longer just talking about “generating code”.

We’re talking about:
designing a system correctly.

🚀 Other Essential Commands in Antigravity

`/goal`

/goal is basically the opposite of /grill-me.

Here:
the agent receives a final objective and operates autonomously until the task is complete.

Example:

/goal Fix all broken tests and stabilize the CI pipeline

The agent:

plans,
executes,
fixes,
iterates,
validates.

Without asking for intermediate approvals.

This is extremely powerful for:

refactoring,
CI/CD fixes,
migrations,
repetitive tasks,
well-scoped workflows.

`/schedule`

This command allows background task scheduling.

Typical use cases:

scheduled jobs,
delayed execution,
recurring automations,
AI cron jobs.

Example:

/schedule Analyze logs every night at 2 AM

Very useful for:

monitoring,
automated QA,
audits,
technical watch,
proactive maintenance.

`/browser`

This command explicitly forces the use of the web browsing sub-agent.

The agent can then:

navigate websites,
interact with pages,
test interfaces,
perform research,
inspect rendering.

Example:

/browser Test the mobile checkout flow

Very useful for:

frontend QA,
scraping,
UI debugging,
SEO verification,
automated user testing.

🏗️ The Real Shift: From Prompting to Orchestration

Developers who perform best with AI agents are no longer just people who “write good prompts.”

They are people who know how to:

orchestrate,
frame problems,
break down tasks,
supervise,
validate assumptions,
control context.

/grill-me is interesting because it formalizes this mindset.

The developer does not become less important.

Quite the opposite.

Their role evolves toward:

arbitration,
clarification,
architecture,
strategic supervision.

The agent executes.
The human pilots.

✅ When To Use `/grill-me`

Use it systematically for:

complex architectures,
e-commerce modules,
business workflows,
API integrations,
multi-service systems,
migrations,
AI projects,
automation pipelines,
anything where bad assumptions are expensive.

❌ When Not To Use `/grill-me`

It’s unnecessary for:

a tiny isolated function,
a trivial bug fix,
a highly constrained task,
a simple mechanical operation.

In those situations:
/goal will usually be faster.

🎯 Conclusion

The biggest risk with AI agents is not that they code poorly.

It’s that they code fast…
in the wrong direction.

/grill-me acts like an intelligent safeguard:

it intentionally slows down the beginning,
to massively accelerate everything afterward.

And the more autonomous agents become,
the more critical this clarification phase becomes.

Because in the end:

A very fast AI agent with bad assumptions is still… an error accelerator.

— Nicolas Dabène

PHP 8.6 introduces `clamp()` : a small function that greatly improves code readability

Nicolas Dabene — Thu, 28 May 2026 23:30:04 +0000

PHP 8.6 introduces a very simple new native function… but one that is extremely useful in day-to-day development:

clamp()

Its purpose is straightforward:

Keep a value within a defined minimum and maximum range.

In other words:

if the value is too low → return the minimum
if the value is too high → return the maximum
otherwise → return the value itself

It sounds simple.

But in practice, it significantly improves:

readability
business intent clarity
maintainability
bug reduction

Documentation:
https://php.watch/versions/8.6/clamp

PHP 8.6 release timeline

The current planned GA (General Availability) release date for PHP 8.6 is:

November 19, 2026

Official schedule:

Alpha 1: July 2, 2026
Feature Freeze + Beta 1: August 13, 2026
GA (General Availability): November 19, 2026

As always with PHP:

the schedule may still change
features may evolve before final release

The problem before PHP 8.6

Until now, most PHP developers wrote code like this:

$value = max($min, min($max, $value));

Example:

$score = max(0, min(100, $score));

This works perfectly.

But:

it is not intuitive to read
you must mentally parse max(min())
the business intent is not explicit
beginners often get confused by parameter order

Another very common pattern:

if ($score < 0) {
    $score = 0;
}

if ($score > 100) {
    $score = 100;
}

This is correct, but verbose and noisy for such a simple rule.

The new syntax

With PHP 8.6:

clamp($value, $min, $max);

Example:

$score = clamp($score, 0, 100);

Immediately:

intent becomes obvious
code becomes self-documenting
business logic is clearer

How `clamp()` works

Case 1 — value already within range

echo clamp(50, 0, 100);

Result:

The value is already valid.

Case 2 — value too small

echo clamp(-20, 0, 100);

Result:

The value is clamped to the minimum.

Case 3 — value too large

echo clamp(250, 0, 100);

Result:

The value is limited to the maximum.

Mental model

          clamp(value, min, max)

                ▼
        ┌─────────────────┐
        │ value < min ?   │──► return min
        └─────────────────┘

                ▼
        ┌─────────────────┐
        │ value > max ?   │──► return max
        └─────────────────┘

                ▼
            return value

Real-world use cases

Progress percentage

$progress = clamp($progress, 0, 100);

Useful for:

progress bars
scoring systems
XP systems
discount percentages

Pagination safety

$page = clamp($page, 1, 999);

Prevents:

negative pages
invalid inputs
pagination bugs

CSS opacity

$opacity = clamp($opacity, 0.0, 1.0);

Amount limits

$amount = clamp($amount, 10, 5000);

Common in:

payments
transfers
API quotas
rate limiting systems

Game stats

$health = clamp($health, 0, 100);
$mana = clamp($mana, 0, 200);

`clamp()` supports integers and floats

Integers

clamp(15, 0, 10);

Result:

Floats

clamp(3.14, 0.0, 10.0);

Result:

3.14

Float exceeding range

clamp(15.7, 0.0, 10.0);

Result:

10.0

Important rule: `$min` must be ≤ `$max`

This is invalid:

clamp(10, 100, 0);

PHP will throw:

ValueError

Because:

the minimum cannot be greater than the maximum

Official signature

function clamp(mixed $value, mixed $min, mixed $max): mixed

This means it accepts multiple types.

However…

Practical recommendation: prefer `int` and `float`

Although PHP allows:

clamp("50", 0, 100);

Or even:

clamp(true, false, false);

Mixing:

booleans
strings
loosely typed comparisons

…can lead to confusing behavior in real-world codebases.

Best practice:

use integers
use floats
avoid mixed-type comparisons

Before vs After

Before PHP 8.6

final class DiscountCalculator
{
    public function normalize(int $discount): int
    {
        return max(0, min(100, $discount));
    }
}

With PHP 8.6

final class DiscountCalculator
{
    public function normalize(int $discount): int
    {
        return clamp($discount, 0, 100);
    }
}

The improvement in readability is immediate.

Polyfill for PHP < 8.6

If you want to use clamp() today:

if (!function_exists('clamp')) {
    function clamp(mixed $value, mixed $min, mixed $max): mixed
    {
        if ($min > $max) {
            throw new ValueError(
                'clamp(): Argument #2 ($min) must be less than or equal to argument #3 ($max)'
            );
        }

        if ($value < $min) {
            return $min;
        }

        if ($value > $max) {
            return $max;
        }

        return $value;
    }
}

This replicates the expected behavior of PHP 8.6.

Why this small feature matters

This is not a revolutionary language change.

But it meaningfully improves:

code clarity
intent expression
developer experience
long-term maintainability

It is exactly the kind of function that is:

simple
universal
immediately useful

Comparison with other languages

clamp() already exists in many modern ecosystems:

C++
Rust
Kotlin
Swift
C#
JavaScript (via helpers)
Python (via libraries)

PHP is finally aligning with this common pattern.

Conclusion

clamp() is one of those small additions that quickly becomes everywhere in your codebase.

Before:

$value = max($min, min($max, $value));

After:

$value = clamp($value, $min, $max);

More readable.
More explicit.
Less error-prone.
Better intent.

And honestly…
once you start using it, going back feels unnecessarily complex.

Nicolas Dabène

Developer at https://versus.pro

Anthropic Launches Claude Security: The AI That Detects Vulnerabilities in Your Code

Nicolas Dabene — Thu, 28 May 2026 23:30:02 +0000

Anthropic has just crossed a major milestone in AI-assisted software security. Claude Security, the code analysis tool the company had been developing since February under the name Claude Code Security, is now available in public beta. And honestly, this is one of the most promising evolutions I’ve seen in security code analysis in a long time.

TL;DR — If you only have 30 seconds: Claude Security scans your code, validates detected vulnerabilities, and suggests fixes. Public beta is available now for Enterprise customers.

How Claude Security Works

In practice, the tool goes far beyond simply scanning your codebase for known patterns. Claude Security tracks data flows across files, reads Git history to understand context, and understands the business logic behind the code. Where traditional tools stop at pattern matching, this is real semantic analysis.

Every detected vulnerability comes with:

A confidence score for the diagnosis
A severity assessment
The likely impact on the system
The steps required to reproduce the issue
A suggested fix directly openable in Claude Code on the Web

And most importantly — a critical point — every fix requires human review and approval before being applied. Teams stay in control. Personally, I think this is exactly what we should expect from a tool operating in the security space: no automatic application, no unexpected production changes.

New Features Included in the Public Beta

Feature	What It Enables
Scheduled scans	Automate security checks at regular intervals
Directory targeting	Restrict scans to a specific project path
Documented dismissal	Keep a record of triage decisions for future teams
CSV/Markdown export	Integrate results into existing audit systems
Webhooks	Send alerts to Slack, Jira, and other third-party tools

These features address real-world needs I regularly hear from development teams: automating security without losing traceability, while integrating smoothly into existing workflows.

Claude Security Availability

The tool is available immediately in public beta for Claude Enterprise customers, via the Claude.ai sidebar or directly at claude.ai/security. Administrators can enable it from the admin console.

Important point: no API integration or custom agent development is required. This is plug-and-play for Enterprise customers.

Access for Team and Max plans is expected soon — I’d recommend keeping an eye on future announcements if you’re not yet on Enterprise.

Behind Claude Security: A Broader Cybersecurity Strategy

It would be incomplete to discuss Claude Security without mentioning the larger context. This launch is part of a broader offensive cybersecurity strategy from Anthropic, initiated a few weeks ago with Claude Mythos Preview.

For context, Mythos Preview is considered too powerful to be released publicly — it is accessible only to around fifty partner organizations responsible for securing critical infrastructure. Meanwhile, Claude Security relies on Claude Opus 4.7, Anthropic’s latest public-facing model, which includes cybersecurity safeguards derived from Project Glasswing.

Beyond security itself, this move also allows Anthropic to push Opus 4.7 deeper into its partner ecosystem: CrowdStrike, Microsoft Security, Palo Alto Networks, and others. It’s a smart strategy — and it shows the company is not only playing the technical card, but also the ecosystem card.

🔑 Key Takeaways

Claude Security is now in public beta for Enterprise customers — Team and Max plans will follow.
The tool goes beyond pattern recognition by understanding business logic and tracking data flows.
Every suggested fix requires human approval — no automatic application, which is the responsible approach.
New features such as scheduled scans, webhooks, and exports directly address professional team requirements.
This launch fits into a broader strategy positioning Opus 4.7 as Anthropic’s flagship cybersecurity model.

Conclusion

To put it simply: Claude Security looks like what code security should always have been — an assistant that truly understands what it scans, not just a pattern detector. Does it replace human security audits? No. Does it make code review faster and more comprehensive? Absolutely.

Personally, I’ll be watching this very closely. If you’re on an Enterprise plan and running production code, enabling Claude Security should be an obvious move.

Nicolas Dabène — Developer of the MCP Tools Plus module for PrestaShop & expert in e-commerce security architecture.

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

Nicolas Dabene — Thu, 28 May 2026 23:15:03 +0000

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

1. The Shipwreck of Pure Autonomy: The Devin Case

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

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

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

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

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

This agentic stack rests on four critical layers:

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

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

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

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

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

The cycle is ruthless:

Phase Symptom Day 1 Development speed multiplied by ten Day 30 Duplicated logic appears, coherent error handling disappears Day 90 The wall. Code becomes « hostile ». Modifying a minor function triggers bug cascades no one can resolve Dimension Vibe Coding (Initial) Long-Term Maintenance Structured Control (Intent/Kiro) Input Vague natural language Deep understanding Structured specifications (EARS) Quality « Happy path » only Systemic fragility Edge case coverage Control Speed illusion Refactoring wall Human validation at each step > ⚠️ The warning — Vibe Coding kills maintainability. It’s the fastest route to the Technical Debt Ramp.

4. Micro-societies of agents: The MiroFish Explosion

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

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

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

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

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

Parallel Pattern (Swarms)

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

Sequential Pattern (Pipeline)

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

Supervisor Pattern

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

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

Conclusion: Toward « Software for One »

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

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

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

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

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

Nicolas Dabene — Thu, 28 May 2026 23:15:02 +0000

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

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

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

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

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

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

The fourth article is the logical consequence of all this.

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

Not disappearing.

Not dissolving.

Not becoming secondary.

Shifting.

And this shift deserves to be named.

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

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

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

Both readings are too short.

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

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

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

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

Understanding the real need.

Choosing the right level of breakdown.

Knowing what needs to be made explicit.

Determining what can be entrusted and what must be verified.

Identifying risk zones.

Maintaining overall coherence.

Arbitrating between speed and robustness.

Maintaining quality in a faster, more distributed work system.

That’s where value reconcentrates.

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

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

That’s an important nuance.

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

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

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

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

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

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

Web development is entering this logic too.

The New Point of Tension Is Arbitration

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

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

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

Because someone has to decide.

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

That’s where arbitration becomes central.

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

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

Framing Becomes a Full-Fledged Production Skill

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

With agentic AI, this hierarchy becomes much less obvious.

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

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

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

In short, framing becomes a way of producing better.

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

Orchestrating Is Not Blind Delegation

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

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

This requires very concrete decisions.

Should you start by exploring or specifying?

Should you produce a first base before review, or go through a stronger framing step?

Should you clearly separate implementation and validation?

At what point do you inject security constraints?

When should you interrupt a chain to prevent it from propagating a bad assumption?

Which results are reliable enough to move to the next stage?

What must remain under mandatory human review?

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

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

The Orchestrator Developer Remains a Developer

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

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

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

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

They understand what is produced.

They understand why it was produced that way.

They understand what needs to be verified.

They understand where the system can lie, drift, or oversimplify wrongly.

They understand when to accelerate and when to brake.

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

Final Responsibility Cannot Be Outsourced

This is perhaps the most important point of all.

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

I don’t believe in this reading.

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

Someone must remain accountable for the quality delivered.

Someone must accept the fact that a choice was made.

Someone must be able to explain why this option was chosen over another.

Someone must carry the coherence of the product, the project, the architecture, and the risks.

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

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

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

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

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

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

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

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

What Will Distinguish the Best Profiles in the Years to Come

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

The best profiles will be those who know how to:

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

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

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

Not in enthusiasm.

Not in the number of tools tested.

Not in the quantity of code generated.

But in the quality of the work system put in place.

The Profession Doesn’t Shrink, It Gains Density

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

Because it forces you to be more explicit.

Because it pushes you to better formalize.

Because it makes visible skills that sometimes remained implicit.

Because it puts the quality of human judgment under tension.

Because it transforms context, method, and organization into real production assets.

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

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

That’s why I talk about the orchestrator developer.

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

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

Conclusion

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

What loses some rarity is a part of raw production.

What gains strongly in value is the ability to frame, orchestrate, and arbitrate.

Frame, to create a clear work space.

Orchestrate, to structure a reliable production chain.

Arbitrate, to keep quality, coherence, and responsibility where they must remain.

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

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

End of the Series

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

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

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

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

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

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

Nicolas Dabene — Thu, 28 May 2026 23:00:04 +0000

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

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

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

Many still answer too quickly: the model.

The best model.

The strongest model.

The fastest model.

The most impressive model on benchmarks.

The model that “reasons” best.

The model that codes best.

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

The real difference happens elsewhere.

It happens in the context you give the system.

In the skills you stabilize around it.

And in the method you impose on its work.

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

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

The Model Alone Isn’t Enough to Create Quality

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

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

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

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

It arrives with generalization power.

Not with intimate knowledge of your living system.

That’s an essential difference.

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

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

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

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

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

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

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

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

Without context, an agent improvises.

With weak context, it extrapolates.

With fuzzy context, it rationalizes.

With poorly prioritized context, it mixes the important and the accessory.

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

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

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

Good context is sorted.

Structured.

Prioritized.

Situated.

Oriented toward the expected action.

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

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

What Teams Hold in Their Heads Must Become Transmissible

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

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

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

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

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

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

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

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

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

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

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

It can contain a method.

Rules.

Recurring patterns.

Vigilance zones.

Boundaries not to cross.

Output expectations.

Useful references.

Implicit checklists.

A recognized way of reasoning about a given problem.

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

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

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

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

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

That’s precisely why it becomes a strategic asset.

Skills Change the Question You Ask Agents

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

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

The nuance is enormous.

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

And that’s where quality truly progresses.

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

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

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

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

Without Method, Even a Good System Drifts

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

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

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

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

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

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

You specify.

You plan.

You break down.

You execute.

You verify.

You fix.

You iterate.

You validate.

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

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

Method Is a Skill That Regains Value

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

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

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

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

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

This profoundly changes how you read technical maturity.

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

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

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

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

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

The orchestrator developer operates at multiple levels.

They know what context to give.

They know what to make explicit and what to leave out of scope.

They know which skills should be mobilized.

They know when a task needs to be broken down.

They know when independent validation is necessary.

They know that a simple but rigorous method is often better than brilliant improvisation.

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

Context provides the right reference points.

Skills make expertise reusable.

Method transforms this power into a reliable work chain.

Without them, even a very good agent drifts.

With them, even an imperfect system becomes much more useful.

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

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

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

Coming Up in the Series

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

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

Nicolas Dabene — Thu, 28 May 2026 23:00:03 +0000

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

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

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

One agent to understand the request.

One agent to produce the architecture.

One agent to code.

One agent to secure.

One agent to test.

One agent to package.

One agent to document.

One agent to review.

One agent to deliver.

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

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

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

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

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

The Super-Agent Fantasy Is Understandable

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

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

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

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

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

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

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

But this impression of fluidity masks a structural fragility.

A Single Agent Ends Up Carrying Everything… So Mixing Everything

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

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

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

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

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

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

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

Real Development Is Not a Continuous Demo

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

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

But a real project is not an extended demo.

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

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

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

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

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

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

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

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

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

This separation brings something fundamental: it makes responsibilities clearer.

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

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

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

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

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

With roles.

With sequences.

With checkpoints.

With verifications.

With relay decisions.

With areas where you can parallelize.

With moments where you must, on the contrary, slow down and arbitrate.

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

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

One agent can explore.

Another can structure.

Another can produce.

Another can verify.

Another can review from a specific angle.

Another can transform a validated decision into a clean deliverable.

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

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

Handoffs Become a Real Engineering Topic

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

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

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

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

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

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

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

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

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

With agents, this rule remains true.

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

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

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

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

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

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

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

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

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

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

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

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

Mature Agentic AI Means Giving Up on Magic

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

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

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

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

An architecture where each role has a reason to exist.

An architecture where handoffs are thought through.

An architecture where validations are separated from productions.

An architecture where context isn’t just accumulated, but intelligently distributed.

An architecture where the human retains real arbitration power.

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

The Orchestrator Developer Emerges Right Here

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

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

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

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

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

Because a poorly structured agentic system can produce fast without producing right.

And because a well-thought-out agentic system can truly change a team’s quality level.

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

Conclusion

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

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

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

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

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

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

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

Coming Up in the Series

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

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

Nicolas Dabene — Thu, 28 May 2026 22:45:03 +0000

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

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

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

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

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

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

The Anatomy of a Generative Search Engine (GSE)

A GSE operates in 4 steps:

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

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

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

2. GEO vs SEO: What Fundamentally Changes

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

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

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

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

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

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

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

Step 1: Test Direct Answers

For each target query, check:

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

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

Step 2: Analyze Citation Structure

When your site is cited, note:

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

Step 3: Map the Gaps

Create a simple table:

Query Google AI ChatGPT Perplexity Bing Presence “best PrestaShop SEO module” ✅ ❌ ✅ ❌ 50% “configure MCP PrestaShop” ❌ ❌ ❌ ❌ 0% > 💡 If your presence is below 50% on your strategic queries, you’re invisible to a growing portion of traffic.

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

This is where it gets technical — and crucial.

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

The Two Families of AI Bots

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

Check your server logs or use tools like:

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

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

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

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

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

The 3 Levels of Delphic Cost

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

How to Reduce Delphic Cost

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

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

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

6. The GEO Methodology in 5 Steps

Here’s the framework I apply systematically:

1. Citability Audit

Analyze each page against these criteria:

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

2. Semantic Optimization

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

3. RAG-Focused Structuring

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

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

4. Reinforced E-E-A-T Signals

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

5. Continuous Monitoring

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

7. Tools and Resources for Implementing GEO

Testing Tools

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

Technical Tools

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

Resources to Go Further

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

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

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

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

My Recommendation

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

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

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

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

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

Nicolas Dabene — Thu, 28 May 2026 22:45:02 +0000

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

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

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

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

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

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

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

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

And that shift is much deeper than it appears.

We’re No Longer Just in the Prompt Era

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

But that logic also showed its limits very quickly.

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

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

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

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

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

The Tipping Point Happens When AI Enters the Workflow

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Breakthrough Is Organizational First

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

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

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

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

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

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

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

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

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

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

I think both positions miss the point.

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

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

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

That’s where the profession transforms.

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

That’s why I use the term orchestrator developer.

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

The Trap Would Be Believing a Good Model Is Enough

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

In practice, that’s not how it works.

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

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

And that reality changes the nature of differentiation.

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

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

Web Development Becomes a More Explicit System

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

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

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

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

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

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

Productivity Changes Its Definition

This is another major consequence.

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

With agentic AI, that reading becomes too poor.

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

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

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

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

The Best Will Learn to Organize, Not Just to Prompt

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

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

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

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

Not less method. More method.

Not less rigor. More rigor.

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

The Real Topic Is Already Ahead of Us

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

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

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

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

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

Conclusion

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

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

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

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

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

Coming up in this series

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

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

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

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

DEV Community: Nicolas Dabene

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

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

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

Breakdown of the Three Pillars

Summary: Fuzzy Prompt vs. CRT Prompt

3. Practical Case 1: Developing a Prestashop Module

CRT Application

4. Practical Case 2: Laravel Architecture and Logic

CRT Application

5. Practical Case 3: Brainstorming a New Feature

CRT Application

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

Collaborative Optimization Strategies

7. Practical Tool: Universal CRT Prompt Template

Golden Rules for Execution:

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

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

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

3. Why Is This Dangerous?

4. Survival Guide: How to Spot Slop

In Conclusion: Demand Substance, Stay Human

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

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

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

3. The Professionalization of AI: Prompt Engineering for All

4. The Architecture of Efficiency: Specialized Agents and FinOps

5. Conclusion: Defining a Framework for Reasoned AI

`/grill-me`: The Command That Stops AI Agents From Coding the Wrong Thing

TL;DR

🤖 The Real Problem With AI Agents

🔥 /grill-me Completely Changes the Dynamic

🧠 Why This Approach Is Extremely Powerful

1. It Reduces Business Hallucinations

2. It Forces Requirement Clarification

3. It Prevents Bad Starts

⚙️ A Concrete Example

🚀 Other Essential Commands in Antigravity

/goal

/schedule

/browser

🏗️ The Real Shift: From Prompting to Orchestration

✅ When To Use /grill-me

❌ When Not To Use /grill-me

🎯 Conclusion

PHP 8.6 introduces `clamp()` : a small function that greatly improves code readability

PHP 8.6 release timeline

The problem before PHP 8.6

The new syntax

How clamp() works

Case 1 — value already within range

Case 2 — value too small

Case 3 — value too large

Mental model

Real-world use cases

Progress percentage

Pagination safety

CSS opacity

Amount limits

Game stats

clamp() supports integers and floats

Integers

Floats

Float exceeding range

Important rule: $min must be ≤ $max

Official signature

Practical recommendation: prefer int and float

Before vs After

Before PHP 8.6

With PHP 8.6

Polyfill for PHP < 8.6

Why this small feature matters

Comparison with other languages

Conclusion

Anthropic Launches Claude Security: The AI That Detects Vulnerabilities in Your Code

How Claude Security Works

New Features Included in the Public Beta

Claude Security Availability

Behind Claude Security: A Broader Cybersecurity Strategy

🔑 Key Takeaways

🔥 `/grill-me` Completely Changes the Dynamic

`/goal`

`/schedule`

`/browser`

✅ When To Use `/grill-me`

❌ When Not To Use `/grill-me`

How `clamp()` works

`clamp()` supports integers and floats

Important rule: `$min` must be ≤ `$max`

Practical recommendation: prefer `int` and `float`