Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
I come from code.
I was a DevOps engineer, even if that wasn't necessarily what we called it back then. I was a developer. I was a software architect. Then, gradually, I stepped away from those roles and moved into managing dev teams, project work, agile, product management.
I didn't stop coding overnight. At first, I still wrote Python scripts myself — automating a task, sorting files, transforming a format, building a small tool. Then I started delegating some of that work to ChatGPT, in chat mode. Then I shifted progressively to Claude Code. But in all cases, it was still small pieces of code to build tools, not product development in the full sense.
Until then, it was tightly scoped. A Python script, a function. A specific task. A clean kind of delegation: instead of asking the LLM to sort files itself in its context, you had it write a script. It ran an operation, you verified, you moved on.
But that's not what's been happening for the past few days.
For four days, I've been developing again. Or rather: I've been having Claude Code develop. And this time, I'm not talking about a utility script. I'm talking about a real product, built from zero, with screens, internal APIs, advanced behaviors, data modifications, architectural choices, tests, documentation generated from the code.
This piece isn't a conclusion about vibe coding. I don't have enough distance for that. Four days is too short to build a doctrine. That might even be the most important point: I'm still in the middle of it. I'm documenting a crossing.
The Honeymoon
The first thing that strikes you is the speed.
In four days, I produced something that, back when I was developing, would probably have taken me a month. Maybe two. And I'm not saying that to sound impressive. I started from scratch. I made over 180 commits. I built, broke, fixed, reorganized, tested, added behaviors, demoed the product, received feedback, kept going.
It's intoxicating.
There's a moment where you think: this is incredible. I can have an idea, articulate it, ask Claude to implement it, test, adjust, go again. I'm no longer writing a spec imagining what the product will look like later. I'm already inside it.
And that changes a lot of things.
With a mockup, you can already iterate. You see a screen, a flow, an intent. You think: the button is in the wrong place, this use case isn't clear, something's missing. But with a working product — even an imperfect one — the iteration becomes even more direct. You actually use it. You actually see it. You feel the friction.
In my case, the shift happened fairly naturally. At first it looked like a mockup. Then the mockup started working. Then I demoed it. Then people asked for improvements. Then they asked when they could use it.
That's usually where the danger starts: when the throwaway becomes useful.
The Cold Shower
The second thing that strikes you is that Claude Code, left alone, can do absolutely anything.
Not anything in the sense that nothing works. It's almost the opposite. Often, it works. The screen renders. The data loads. The button does something. The demo goes fine. And that's exactly what makes it dangerous.
Claude has a natural tendency to charge ahead. It codes. It adds. It grows. It starts with a reasonable file, then that file swells and swells until it becomes a blob that does a little bit of everything. When you need to modify it, it takes longer. When you need to understand the intent, it's harder. When a bug appears, you no longer know exactly where to look.
An experienced developer fairly quickly thinks about separation of concerns. They ask where to put the business logic, how to isolate the transport layer, where to put the rendering, how to name concepts, how to avoid coupling everything to everything. Claude can do it, but it doesn't do it consistently on its own. You have to guide it.
Same thing with data volume.
In my project, some APIs can return a few hundred items. Others can return tens of thousands. That's not even close to the same world. Loading 200 items to display on a page is nothing like loading 20,000 or 30,000 items and hoping the browser, the user, and the backend will stay cheerful.
But if you don't tell it anything, Claude can easily load everything, pass it all to the web page, filter it client-side, and consider the problem solved. In testing, with little data, it can look like it works. In real use, it blows up. Or worse: it doesn't break cleanly — it just becomes slow, frozen, incomprehensible.
A bug isn't always a red error in the console. Sometimes it's just a product that stops responding because 5,000 items were loaded silently, with no logging, no pagination, no clear strategy. And there, a non-technical PM may not understand what's happening.
Managing a Very Fast Junior Developer
My relationship with Claude Code reminded me a lot of managing an extremely fast junior developer.
It can produce an enormous amount. It can also take absurd liberties. You give it a screenshot of a component, it doesn't do exactly what was asked. It interprets. It simplifies. It goes in a direction. Sometimes you have to re-explain basic things: why this file shouldn't contain everything, why this layer shouldn't know about that other layer, why you don't load all the data, why you need to write tests, why you need to re-run tests.
And sometimes it doesn't get it right away.
That's not a big deal in itself. Human developers make mistakes too. Things built by developers sometimes go to production and don't hold up under load. Technical debt didn't start with PMs doing vibe coding.
But AI adds a speed that changes the problem. It allows you to produce a lot of mediocre code very quickly. If the guardrails aren't in place, the debt accumulates fast. Very fast.
On my end, my technical background helps. I understand the broad lines of the architecture. I see when a file starts getting too big. I see when the layers are bleeding into each other. I can feel when something is going to cause a volume or maintainability problem.
But I don't control everything. There are parts of the code I couldn't explain immediately. If I take the time, I can understand them. But I can't pretend to have the same mastery as if I'd written every line myself.
On this product, I accept that. On other products, I wouldn't.
And that distinction matters.
The Real Issue: Competence Multiplied by Risk
You could frame the question like this: can all PMs now build software with AI?
My instinctive answer would be: no.
Or rather: it depends.
But "it depends" isn't a dodge. It's not just about individual skill. It's about the relationship between the level of competence and the level of risk of the product.
It's exactly like a junior developer. Do you immediately give a junior access to the most complex, most critical, most business-impactful repository? Probably not. Do you give them access to every repo, all the data, all the permissions? No.
For a PM who vibe-codes, it's the same.
It's not about saying: PMs can or can't do this. It's about defining what they can do, in what scope, with what limits, based on their level and the risk.
I like the driving license analogy. You don't drive any vehicle without a license, because you can become dangerous. And even with a license, you don't drive everything. Maybe a rusty PM can handle a 125cc. That doesn't mean they should get on a heavy bike and hit the highway in the rain.
"PM code," in my usage, isn't an insult. It doesn't mean PM code is necessarily bad. It means it's code produced by someone who doesn't have a strong — or no longer has a strong — command of code. So you have to accept limitations. And above all, you have to accept defining them.
Green, Orange, Red
I don't believe in a universal framework.
Every company will need to define its own policy. But the principle seems clear enough: the more the product touches sensitive data, write operations, critical workflows, security, billing, permissions — the higher the bar has to be.
A small internal tool, personal, short-lived, with limited impact, can probably survive with little formalism. If it breaks, it's not a disaster. You throw it out, fix it, move on.
A shared internal tool, with advanced behaviors, limited write operations, business dependencies, is already something different. There, you need to ask more questions.
And once you're touching critical production systems, sensitive customer data, permissions, irreversible writes, or workflows with strong customer or business impact — you're in a completely different category.
Security, for example, seems non-negotiable to me. You can debate the test coverage needed for a throwaway tool. You can debate the review. You can debate the documentation level. But security shouldn't depend on the mood of the moment.
Fortunately, developers already have plenty of tooling for this: CI/CD, scanners, rules, practices, skills, sometimes even internal prompts or custom skills. The point isn't to reinvent everything for PMs. It's to connect augmented PMs to the tooling that already exists.
I Don't Believe in Systematic Review
You could answer: just have developers review everything.
I'm skeptical of that response.
Systematic review has become a reflex, but it deserves scrutiny. It comes largely from the open source world, for multiple reasons: quality, security, knowledge transfer, governance, trust between contributors. But in a company, for all types of code, in all contexts, I'm not convinced you need to review everything systematically.
If a PM builds a personal, throwaway, low-risk tool, do you really need to pull a developer in to review it? Maybe not. Otherwise you recreate exactly the dependency you were trying to reduce.
That said, review can play a role early on — helping PMs build good habits. It may also be necessary depending on what's at stake. Again, it's not yes or no. It's a matter of risk.
At some point, you also have to accept responsibility. If I decide to build my own tool, I have to eat my own cooking. If it breaks, it's on me to figure it out. And that's where it can hurt — because many PMs won't necessarily know how to debug what they just built with AI.
Tests as a Control Lever
In this experience, tests became central.
Not just because "tests are good." But because they're one of the few ways to stay in control of code you didn't entirely write yourself.
Claude doesn't spontaneously write the right tests if you don't ask for them. It can forget. It can write tests after the fact. It can write tests that validate its implementation rather than the business intent. It can give the impression the product is safe because there are tests, when in fact there's no real test strategy.
A PM may not know TDD. They may not know the difference between a unit test, an integration test, and an end-to-end test. They may not know the test pyramid. They don't always know when to write a test before coding a behavior, or how to express a business rule as a test.
And yet, in a vibe coding project, this might be one of the most important points.
In my project, there are over 500 tests. That's a lot for a project of this size. Most of the time, things don't break — precisely because Claude re-runs the tests very often. When something does break, the tests provide a foothold. They help you understand where the expected behavior stopped being respected.
I'm not saying everything needs the same level of rigor. A very simple, low-risk internal tool doesn't necessarily need a complete test strategy. Again, it's a matter of scale.
But once the product gets more serious, tests aren't a bonus. They become part of the steering wheel.
Rails Accelerate as Much as They Protect
When I talk about rails, I don't only mean guardrails that prevent PMs from doing something stupid.
Rails also help you go faster.
If you leave a PM and Claude Code alone facing a codebase, the AI can easily miss the right internal APIs. It can use the wrong entry point. It can rebuild something that already exists. It can produce a tool that works poorly, or not at all, or wastes enormous time working around the existing architecture.
But if developers provide rails, the PM and the AI know where to go.
These rails can take many forms: a catalog of available internal APIs, functional documentation generated from the code, a mapping between business concepts and technical entry points, example requests, reusable UI components, conventions, scoped access, security CI, Claude files, prompts, skills.
You can imagine, for example, an environment where a PM can build internal screens, query interfaces, lists, charts, or business scenarios — backed by documented and validated APIs. All the plumbing is built by the developers. The PM doesn't start from a blank page. They compose within a framework.
That's already what some tools have been doing for years with query languages, dashboards, and internal platforms. AI just makes that logic more powerful.
The key point: rails don't only slow things down. They speed things up, because they keep the AI from going down the wrong path.
From Small Internal Tool to Product Builder
There's maybe an additional level.
So far, you might think I'm only talking about small internal tools: a lookup screen, an export, a dashboard, a query interface, a temporary interface to help the product team. That case exists and is already interesting. It can relieve pressure on developers, speed up day-to-day work, let a product team answer some of its own needs.
But that may not be the only horizon.
If a company's codebase is well-structured, internal APIs are documented, business concepts are readable, components and conventions are stable — then the PM might be able to go beyond the simple internal tool. They can become a kind of product builder.
Not an autonomous developer on any topic. Not someone handed unrestricted access to the product's critical areas. But someone capable of creating a module, a screen, a flow, or a functional variation by building on the existing codebase.
The difference matters.
With a small internal tool, the PM usually builds alongside the product. They consume APIs, aggregate information, produce an interface useful to themselves or their team.
With a product builder, they build more in the extension of the product. They use the existing building blocks, the business language in the code, the company's components, the rails the developers have laid. They're not starting from a blank page. They're composing with material that's already structured.
And that's precisely where the quality of the codebase becomes decisive. A poorly structured codebase traps the PM and the AI in patchwork. A readable, documented, business-oriented, well-tooled codebase can instead open up a broader space for contribution.
Vibe coding doesn't automatically turn a PM into a product builder. Handing them Claude Code and a Git repo isn't enough. You need a workable terrain.
If that terrain exists, then the question becomes far more interesting than "can PMs build their own little tools?" The real question becomes: how far can an organization let product profiles directly build parts of the product without losing technical control, coherence, and security?
What About Specs?
This experience also made me revisit a question that borders on provocative: do we still need to write specs?
I'm not saying specs are going away everywhere. For many products, regulatory contexts, and structural decisions, you'll always need to write, frame, discuss, document the why.
But for some internal tools, I wonder if the spec is changing status.
In my case, I didn't write a spec. I just started. I built. I showed it. People said: this is missing, we'd need this, for this and that reason. I added it. I iterated.
Why build a mockup if I can build a first working version directly? Why write a descriptive spec if I can let the behavior emerge in the product, then generate functional documentation from the code afterward?
I recently wrote that the product question should start from the source code. This experience points in the same direction, but from the other side. If the code becomes the truth of the behavior, then part of the documentation can be regenerated from it. The spec doesn't necessarily disappear — but it can no longer claim to be the lasting truth of the product.
For some areas, you could almost say: we no longer write the spec first. We build, validate, then generate the business logic from what's running.
I'm pushing the point a bit. But not that much.
The Organizational Risk
There's also a less technical, more organizational risk.
If everyone starts building their own tools in their corner, things can quickly spiral. Unmaintained internal tools can become important. Throwaway scripts can end up used every week. A screen hacked together for a team can become mandatory. A tool without governance can become critical without anyone ever deciding that.
But this risk isn't unique to vibe coding. Companies already deal with this through Excel files, macros, scripts, no-code tools, dashboards built on the side. Vibe coding doesn't create the problem. It accelerates it, because it makes producing tools easier.
Again, the answer isn't to ban it. It's to define the zones, the permissions, the responsibilities, the limits, the rails.
What This Changes for Developers
I don't think PMs are going to replace developers.
But I do think some small internal tools that used to be requested from developers could now be built directly by product, support, ops, or business teams — as long as the context is well-scoped. And that can relieve pressure on developers.
How many times have you asked a dev team to step away from the core product to build a small internal tool, an export, a lookup screen, a dashboard, a temporary interface? If some of those requests can be absorbed elsewhere, that's not necessarily bad news.
But that doesn't make the developer role disappear. On the contrary, it can shift it. They also become the people who build the rails, the platforms, the clean APIs, the conventions, the safe environments where others can produce without breaking everything.
That's not less technical. It might even be more architectural.
The Fatigue
I don't want to sell this experience as purely euphoric.
It's tiring.
Making over 180 commits in four days, even with AI, isn't neutral. You're not typing all the code, but you're steering, reviewing, testing, correcting, deciding, reworking, monitoring, re-explaining. You move very fast, but you have to keep up with the speed.
Vibe coding gives a sense of power, but it's not free power. The PM becomes a kind of pilot, proximity architect, tester, reviewer, intent-setter, guardrail. And if they don't have enough technical literacy, they can end up driving something they don't really understand.
That's where the illusion of competence is dangerous.
We've seen this before with no-code. People thought they no longer needed developers, then discovered three days later that a site with no security, no protection against brute force attacks, no circuit breaker, could very quickly become a problem. It wasn't that the tool was bad. It's that it gave access to power without automatically transferring the security and architecture culture that comes with it.
Vibe coding raises the same kind of question.
I'm Documenting a Crossing
I don't have a definitive conclusion.
And that might be the only serious conclusion possible after four days.
I'm still vibe-coding. I keep learning. I keep seeing what works, what breaks, what escapes me, what the tests catch, what the rails speed up, what my old technical background still lets me sense.
I don't want to build my opinion from the grandstand. I want to build it through practice.
What I see right now is a new capability — very powerful — that doesn't eliminate the old questions of software. It makes them more visible sometimes. It accelerates them. It moves them around.
Vibe coding lets you go very fast. But going fast isn't the same as knowing where you're going, or knowing what you risk breaking.
So I keep going.
I'm documenting a crossing.
For More
The product question should start from the source code In 8 days, I understood that the Product Manager job was about to change completely AI shouldn't just help us produce ten times more. It should also force us to understand ten times better what we produce Code Centric