Industrial-grade copy/paste
A few months ago, I was using AI the way most developers do: I'd ask a question, grab a snippet of code, and spend twenty minutes checking whether it had hallucinated half the answer.
My daily workflow with ChatGPT was a loop: ask a technical question, copy the response, realize it doesn't compile, send back the stack trace, copy the fix, validate, commit. Forty times a day. Industrial-grade copy/paste — mechanical, thoughtless — with the vague conviction that it was still better than writing everything by hand.
Meanwhile, everyone around me had become an evangelist. AI was going to revolutionize everything, you could do anything with it, it was the future. Every problem got the same answer: "Ask ChatGPT." What annoyed me wasn't the tool itself — it was this collective bliss that excused everyone from asking the real question: how to use it intelligently.
False starts
My first encounter with Claude Code lasted a few days. An AI on the command line, capable of writing code, executing it, and reasoning about errors. The first few hours are impressive. Then reality catches up fast: files generated everywhere, an incoherent architecture, a project impossible to maintain by hand. Without structure, AI produces fast — and badly. I give up. I go back to ChatGPT.
Some time later, I switch to GitHub Copilot in VSCode. The autocompletion is good, the suggestions relevant, the integration smooth. It's promising. But fundamentally, nothing has changed: I talk, the AI answers. It's a good assistant. But a passive one.
The problem becomes concrete when I start giving it complex tasks. Copilot can't keep up. You ask it to run a command, it fails, retries the same thing, loops. Meanwhile, tokens pile up — and AI has a cost. A real cost. You lose time, you lose money, and you end up doing it yourself.
Both experiences teach me the same lesson: the power of the tool isn't enough. What makes the difference is how you use it.
Back to Claude
With that lesson in mind, I come back to Claude a few months later. And something changes. The problems I had with Copilot are gone. Claude executes, reasons, chains steps together — without wasting time on tasks as simple as capturing the output of a program. Confidence returns. AI takes up more and more space in my daily work.
A friend tells me about multi-agent mode, review gates, specialized agents. I read the documentation. I start structuring the way I work: I write skills, I specialize agents, I assign them precise roles.
And above all, I give them access to real systems — Kubernetes clusters, Grafana, GitLab, Sentry, Elasticsearch, Google Search Console, Google Analytics, databases.
Opening the AI's eyes
What Claude can understand about a system when it has access to real data is what surprised me most. It doesn't just run queries — it correlates, contextualizes, identifies patterns. In a few minutes of analyzing Grafana metrics, it surfaced anomalies I hadn't even noticed: latencies hidden in logs, silent error patterns, gradual degradations. The kind of weak signals you don't look for because you don't yet know they exist.
Connecting AI to production data isn't a gimmick. It's what transforms an assistant into something that genuinely understands the system it's working on. The difference between a developer who reads the docs and a developer who reads the metrics.
Building the team
Then comes the next step: I ask Claude to write its own agents. Its own skills. To review itself. Things accelerate. A friend tells me about team mode — still experimental, but already powerful. That's when the paradigm shift happens.
For an agent to be truly effective, you have to give it real autonomy. Not "tell me what to do" — "go do it." Its own access to a Kubernetes cluster, to GitLab, to a full Grafana stack to observe what it deploys. I owe a lot to this friend for pushing me in this direction — two mentions in the same article, well deserved.
I set up a test infrastructure and let Claude operate autonomously. It develops the features we spec together, tests them, deploys them, monitors, fixes.
The resulting production velocity surprises even me. But it doesn't work without structure — and that's where the lesson from the first false start comes back. AI is a tool. Like any tool, it's only effective when used well. You need to structure flows, introduce feature management, organize tasks, optimize communication between agents. It's real architecture work — except what you're architecting is a team.
How it works, concretely
Each feature is a versioned document with a strict lifecycle: planned, in_progress, review, done. I describe what I want, Claude plans the tasks and distributes them across specialized agents — a backend agent that codes the service, a devops agent that handles Kubernetes manifests and CI, a quality reviewer that audits everything, a systematic security auditor. Each agent has its own scope, tools, and constraints. The reviewer can't modify code — it reads, judges, and renders a verdict. The dev doesn't touch production infrastructure. Everything is compartmentalized.
Agents commit on their branches, push to GitLab, trigger CI. Review is mandatory before any merge. A smoke test verifies that the pod is running and the ingress responds. If something breaks, nobody marks "done" — we investigate. Everything is tracked in a central registry that shows the status of every feature at any time.
This isn't magic. It's engineering applied to agent coordination. And it requires as much rigor as building a human team — maybe more, because an agent doesn't raise its hand when it doesn't understand. And its ability to produce fast can become a major problem when it does it poorly. A human error generates a bug. An agent error, multiplied by velocity, can generate fifty before you even notice.
Today, Claude works autonomously on dev and staging environments, with the necessary guardrails. Production remains under strict human control. The infrastructure is secured: each agent operates in an isolated environment, with access limited to its scope. No access to the host cluster, no plaintext secrets, no direct push to master.
What it changed
My job hasn't evolved. It has mutated. In a few weeks, in a way I wouldn't have thought possible.
I barely write code directly anymore. I have a macro view of services, flows, dependencies. What it frees up is time — to design architectures, to think about structural choices, to anticipate. Time constraints, implementation difficulty, the factors that used to dictate the scope of every sprint — they've almost disappeared. Our imagination and our ability to produce are unleashed like never before.
The question now is: what are we going to do with it?
That said, it doesn't run without supervision. The best gate is still a human. At least when the human knows what they're doing — but that's another topic.
In French, developers have a colorful expression: "pisser du code" — literally "pissing code" — producing fast, in volume, usually with the assumption that quality suffers. Except here, quality is maintained by the agents themselves. Thinking about this, I told a colleague this morning:
"Je pisse des features comme si j'étais à la fête de la bière à Munich." — "I'm pissing features like I'm at Oktoberfest in Munich."
Prost. 🍺