I come from code.

I was a DevOps engineer, even if back then nobody necessarily called it that. I was a developer. I was a software architect. Then, bit by bit, I moved away from those jobs and into managing dev teams, projects, agile, product management.

I didn't stop coding overnight. At first I still wrote the odd Python script myself, to automate a task, sort some files, convert a format, make a small tool. Then I started handing part of that work over to ChatGPT, in chat mode. Then I gradually moved to Claude Code. But either way, it was still only small pieces of code for small tools, not product development in the full sense.

Up to now it was all very contained. One Python script, one function. One precise task. A clean kind of delegation: instead of asking the LLM to sort the files itself inside its context, you had it write a script. It ran one operation, you checked, you moved on.

But for the past few days, that isn't what's happening.

For four days I have been developing again. Or rather: I have 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 nothing, with screens, internal APIs, advanced behaviours, data changes, 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 far too short to build a doctrine. That may even be the most important point: I'm still inside it. I'm documenting a crossing.

The honeymoon

The first thing that hits you is the speed.

In four days I have produced something that, back when I was a developer, would probably have taken me a month. Maybe two. And I'm not saying that to sound good. I started from nothing. I made more than 180 commits. I built, broke, fixed, reorganised, tested, added behaviours, showed the product to people, got change requests, carried on.

It goes to your head.

There's a moment where you think: this is incredible. I can have an idea, put it into words, ask Claude to implement it, test it, adjust, start again. I'm no longer writing a spec while imagining what the product will look like later on. I'm already in it.

And that changes a lot.

With a mock-up you can already iterate. You see a screen, a journey, an intention. You think: actually, the button is in the wrong place, this use case isn't clear, something is missing. But with a product that works, even an imperfect one, the iteration becomes more direct still. You genuinely use it. You genuinely see. You feel the friction.

In my case the shift happened fairly naturally. At first it looked like a mock-up. Then the mock-up started to work. Then I showed it. Then people asked for changes. Then people asked when they could start using it.

That's often where the danger starts: when the throwaway thing becomes useful.

The cold shower

The second thing that hits you is that Claude Code, left to itself, can do absolutely anything.

Not anything in the sense that nothing works. Almost the opposite. It often works. The screen renders. The data comes through. The button does something. The demo goes fine. And that is exactly why it's dangerous.

Claude has a natural tendency to charge ahead. It codes. It adds. It bloats. It starts with a reasonable file, then that file swells, and swells, and swells, until it becomes a block that does a bit of everything. When you need to change it, you lose time. When you need to understand the intent, it's harder. When a bug shows up, you no longer know quite where to look.

An experienced developer thinks about separation of concerns fairly quickly. They ask where the business logic goes, where to isolate the transport, where to put the rendering, how to name the concepts, how to stop everything being coupled to everything else. Claude can do it, but it doesn't do it spontaneously and consistently. You have to steer it.

Same story on data volumes.

In my project, some APIs may return a few hundred items. Others may return tens of thousands. Those are not the same world at all. Loading 200 items to display them on a page is not the same as loading 20,000 or 30,000 and then hoping the browser, the user and the backend will all stay in a good mood.

But if you say nothing about it, Claude is quite happy to load everything, push it all to the web page, filter it all on the front end, 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 clearly break, it just gets slow, frozen, unintelligible.

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 at that point a non-technical PM may have no idea what is going on.

Managing a very fast junior developer

The 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 and it doesn't do exactly what was asked. It interprets. It simplifies. It heads off in some direction. Sometimes you have to explain basic things again: why this file mustn't hold everything, why this layer mustn't know about that other layer, why we don't load all the data, why the tests have to be written, why the tests have to be run again.

And sometimes it doesn't get it straight away.

That's not a problem in itself. Human developers make mistakes too. Things written by developers sometimes go into production and fall over under load. Technical debt wasn't invented by PMs doing vibe coding.

But the AI adds a speed that changes the problem. It makes it possible to produce a lot of mediocre code very fast. If the framing isn't right, the debt piles up quickly. Very quickly.

For my part, my technical past helps. I understand the broad lines of the architecture. I can see when a file is starting to get too big. I can see when the layers are bleeding into each other. I can sense when something is going to cause a volume or maintainability problem.

But I don't master all of it. There are parts of the code I couldn't explain on the spot. Given time I can work them out. But I can't claim to have the same grip on it as if I had written every line myself.

On this particular product, I accept that. On other products, I wouldn't.

And that distinction matters.

The real subject: skill multiplied by risk

You could put the question like this: can every PM now build software with AI?

My instinctive answer would be: no.

Or rather: it depends.

But "it depends" isn't a dodge. It isn't only a question of individual skill. It's a ratio between the level of skill and the level of risk the product carries.

It's exactly like a junior developer. Do we hand a junior the most complex, most critical, highest-impact repository on day one? Not necessarily. Do we give them access to every repository, every set of data, every permission? No, we don't.

For a PM who vibe-codes, it's the same.

This isn't about saying PMs are allowed or not allowed. It's about defining what they can do, within what remit, with what limits, depending on their level and on the risk.

I rather like the driving licence analogy. You don't drive just any vehicle without a licence, because you can become dangerous. And even with a licence, you don't drive everything. Maybe a rusty PM can ride a 125cc. That doesn't mean he should get on a big bike and head out onto the motorway in the rain.

"PM code", when I say it, isn't an insult. It isn't saying a PM's code is necessarily bad. It's saying it's code produced by someone who doesn't have a very good grip on code, or no longer has one. So you have to accept limits. And above all, you have to accept the job of defining them.

Green, amber, red

I don't believe in a universal grid.

Every company will have to define its own policy. But the principle seems clear enough: the more the product touches sensitive data, writes, critical workflows, security, billing, permissions, the higher the requirements have to go.

A small internal tool, personal, short-lived, with limited impact, can probably live with very little formality. If it breaks, never mind. You throw it away, you fix it, you move on.

A shared internal tool, with advanced behaviours, some writes, business dependencies, is already something else. There you have to ask more questions.

And as soon as you touch critical production, sensitive customer data, permissions, irreversible writes, workflows with a strong customer or business impact, you move up another category again.

Security, for instance, strikes me as non-negotiable. You can argue about the level of testing a small throwaway tool needs. You can argue about review. You can argue about how much documentation. But security shouldn't depend on the mood of the moment.

Happily, developers already have plenty of tooling for this: continuous integration, scanners, rules, practices, expertise, sometimes even internal prompts or skills. So the point isn't to reinvent everything for PMs. It's to plug augmented PMs into the tooling that already exists.

No, I don't believe in systematic review

One answer would be: just have developers review everything.

I'm fairly wary of that answer.

Systematic review has become a reflex, but it deserves to be questioned. It comes largely from the open source world, for a number of reasons: quality, security, passing on knowledge, governance, trust between contributors. But inside a company, for every type of code, in every context, I'm not convinced everything has to be reviewed as a matter of course.

If a PM builds themselves a personal, throwaway, low-risk tool, do we really need to pull a developer in to read it? Probably not. Otherwise we recreate exactly the dependency we were trying to reduce.

Review can have a role early on, though, to help PMs pick up good practice. It can also be necessary depending on what's at stake. Again, it isn't yes or no. It's a question of risk.

At some point you also have to accept responsibility. If I decide to build myself a tool, I have to be willing to eat my own dog food. If it has a bug, sorting it out is on me too. And that's where it can hurt, because plenty of PMs can't necessarily fix the bugs they've just created with the AI.

Tests as a lever of control

In this experiment, tests became central.

Not just because "tests are a good thing". Because they are one of the few ways of keeping control over code you haven't entirely written yourself.

Claude doesn't spontaneously write the right tests unless you ask. It can forget. It can write the 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 what's missing is a real testing strategy.

A PM doesn't necessarily know TDD. They don't necessarily know the difference between a unit test, an integration test and an end-to-end test. They don't necessarily know the test pyramid. They don't always know when a behaviour should be tested before it's coded, or how to express a business rule as a test.

And yet, in a vibe coding project, that may be one of the most important points of all.

My project has more than 500 tests. That's a lot for a project this size. Most of the time nothing breaks, precisely because Claude runs the tests again very often. When something does break, the tests give you something to push against. They let you see where the expected behaviour is no longer being respected.

I'm not saying everything has to be tested to the same standard. A very simple, low-risk internal tool doesn't necessarily need a full testing strategy. Here too, it's a question of scale.

But as soon as the product gets more serious, tests aren't a bonus. They become part of the steering wheel.

Rails speed you up as much as they protect you

When I talk about rails, I don't only mean guard rails to stop PMs doing something stupid.

Rails are also there to make you go faster.

If you leave a PM and Claude Code alone in front of the source code, the AI may well not pick the right internal APIs. It may use the wrong entry point. It may rebuild something that already exists. It may produce a tool that works badly, or doesn't work at all, or wastes an enormous amount of time working around the existing architecture.

If the developers provide rails, on the other hand, the PM and the AI know where to go.

Those rails can take several forms: a catalogue of the internal APIs you're allowed to use, functional documentation generated from the code, a mapping between business concepts and technical entry points, example queries, reusable interface 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 tools, lists, charts or business scenarios on top of documented, validated APIs. All the plumbing is built by the devs. The PM doesn't start from a blank page. They compose within a framework.

Some tools have been doing this for a long time with query languages, dashboards or internal platforms. The AI simply makes the logic more powerful.

That's the important point: rails don't only slow you down. They speed you up, because they stop the AI taking the wrong path.

From the small internal tool to the product builder

There may be a further step up.

So far you might think I'm only talking about small internal tools: a read-only screen, an export, a dashboard, a query tool, a temporary interface to help the product team. That case is real, and it's already interesting. It can take load off the developers, make the day-to-day faster, let a product team answer some of its own needs.

But it isn't necessarily the only horizon.

If the company's codebase is well framed, if the internal APIs are documented, if the business concepts are readable, if the components and conventions are stable, then the PM can perhaps go beyond the simple internal tool. They can become a kind of product builder.

Not a developer working unsupervised on anything at all. Not someone handed the critical areas of the product without limits. But someone able to create a module, a screen, a journey or a functional variation on top of the existing codebase.

The difference matters.

With the small internal tool, the PM is usually building alongside the product. They consume APIs, aggregate information, produce an interface that's useful to them or their team.

With the product builder, they are building more as an extension of the product. They use the existing building blocks, the business language of the code, the company's components, the rails laid down by the developers. They don't start from a blank page. They compose with something that is already structured.

And that is exactly where the quality of the codebase becomes decisive. A badly framed codebase traps the PM and the AI into botching everything together. A readable, documented, business-oriented, well-tooled codebase can open up a far wider space to contribute in.

So vibe coding doesn't automatically turn a PM into a product builder. Handing them Claude Code and a Git repository isn't enough. You need ground you can actually walk on.

If that ground exists, the subject becomes far more interesting than "can PMs build their own little tools?". The real question becomes: how far can an organisation let product people build parts of the product directly, without losing technical control, coherence and security?

And what about specs?

This experiment also made me ask an almost provocative question again: do we still need to write specs?

I'm not saying specs are going to vanish everywhere. For plenty of products, contexts, regulatory subjects and structural decisions, we will always have to write, frame, discuss, document the why.

But for certain internal tools, I wonder whether the spec isn't changing status.

In my case, I didn't write a spec. I got started. I built. I showed it. People told me: this is missing, this would be good, for such and such a reason. I added it. I iterated.

Why build a mock-up if I can build a first usable version directly? Why write a descriptive spec if I can let the behaviour emerge in the product, then generate the functional documentation from the code afterwards?

I wrote recently that the product question should start from the source code. This experiment points the same way, but from the other side. If the code becomes the truth of the behaviour, 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 certain areas you could almost say: we no longer write the spec first. We build, we validate, then we generate the business view from what's running.

I'm overstating it a little, obviously. But not that much.

The organisational risk

There's also a less technical risk, a more organisational one.

If everyone starts building their own little tools in their own corner, it can quickly sprawl. Unmaintained internal tools can become important. Throwaway scripts can end up being used every week. A screen cobbled together for one team can become a compulsory step. A tool with no governance can become critical without anyone ever deciding it.

But that risk isn't specific to vibe coding. Companies already know it from Excel files, macros, scripts, no-code tools, dashboards built off in a corner. Vibe coding doesn't create the problem. It accelerates it, because it makes producing tools easier.

Here too, the answer isn't to ban it. It's to define the zones, the permissions, the responsibilities, the limits, the rails.

What it changes for developers

I don't believe PMs are going to replace developers.

I do think, though, that some of the small internal tools we used to ask developers for could be produced directly by the product, support, ops or business teams, as long as it's properly framed. And that can take load off the developers.

How many times do we pull a dev team away from the heart of the product to make a small internal tool, an export, a read-only screen, a dashboard, a temporary interface? If part of that demand can be absorbed elsewhere, that isn't necessarily bad news.

But it doesn't make the developers' 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 in which others can produce without breaking everything.

That isn't less technical. It may even be more architectural.

The tiredness

I don't want to sell this experiment as a purely euphoric moment.

It's tiring.

Making more than 180 commits in four days, even with an AI, isn't nothing. You don't type all the code, but you steer, you read, you test, you fix, you decide, you pick it back up, you keep watch, you explain again. You move very fast, but you have to keep up with the speed.

Vibe coding gives you a feeling of power, but the power isn't free. The PM becomes a kind of pilot, hands-on architect, tester, reviewer, source of intent, guard rail. And if they don't have enough technical grounding, they can end up steering something they don't really understand.

That's where the illusion of competence is dangerous.

We've seen it 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 become a problem very quickly. It wasn't that the tool was bad. It was that it gave access to power without automatically passing on the security and architecture culture that goes with it.

Vibe coding raises the same kind of question.

I'm documenting a crossing

I have no final conclusion.

And that may be the only serious conclusion available after four days.

I'm still vibe-coding. I'm still learning. I'm still seeing what works, what breaks, what gets away from me, what the tests catch, what the rails speed up, what my old technical background still lets me sense.

I don't want to manufacture an opinion from the stands. I want to build it through practice.

For now, what I see is a new capability, a very powerful one, that doesn't remove software's old questions. Sometimes it makes them more visible. It speeds them up. 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 carry on.

I'm documenting a crossing.