The number has been circulating for weeks: at Alan, more than 280 pull requests were merged in a single quarter by employees who had never written a line of code. A year earlier the same counter read zero.
The context matters, because it does not transfer as-is: a 150-strong engineering team, a million insured members, a monorepo, ISO 27001 certification, and above all a culture where every decision is taken in writing, in GitHub issues — technical and business alike. Alexandre Gerlic puts it well: it is the closest thing to open source he knows of inside a company.
That last characteristic is not a cultural footnote. It is what made the rest possible.
The founding bet: definitely not a separate tool
When the project starts, in the summer of 2025, the market is awash with tools promising to let non-developers code. Alan discards all of them, and the reasoning is worth quoting:
If we start using different tools, we recreate silos — and that is exactly the trajectory I don't want us on.
The decision: non-engineers use exactly the same tools as engineers. Same development environment, same linters, same CI, same pull requests, same review. Two benefits, and the second is the bigger one: you don't manufacture an artificial silo the way earlier no-code waves did, and you lean on a delivery pipeline you already know holds.
If there were one thing to keep, it would be this. Opening the code to everyone did not mean lowering the bar for newcomers. It meant bringing them inside the existing machinery, with no back door.
What blocked people was not what anyone expected
First lesson, and it is counter-intuitive: generating code was not the problem. As soon as the prompt was roughly right, the models of the day produced code that did the job.
What stalled was everything around it. What is a Git branch? How do you know you haven't created a conflict you won't be able to resolve? And above all: how do you know whether what you are asking for is hard? A change that looks trivial from a user-experience standpoint can imply a data-model change and a database migration. Nobody ever told a designer that.
The answer was to draw a boundary. Front-end yes, on the web app and the mobile app; back-end no; database absolutely not. And an explicit criterion for choosing that scope: the feedback loop has to be visible. On the front end, you change something, the page reloads, and you see whether the flow you had in mind works. That loop is what lets a non-developer learn without constant supervision.
A striking side result: the gap between the start of the experiment and the first production deployment by a non-developer was 24 hours. An engineer joining Alan ships their first pull request within the week. Read the contrast carefully — the ops person was changing an internal tool she uses every day, in a domain she knows by heart, while the engineer must first learn the house. But the question it raises is a good one: between the domain expert who doesn't know the code and the code expert who doesn't know the domain, who ships first?
Ownership, the one real point of contention
There was no engineering revolt, but one point was debated more than the others: if someone from ops pushes a change, who is responsible when it breaks in production? That person cannot debug it.
The answer adopted is simple and transferable: pairing with an engineer, whose code review carries the commitment. Ownership stays with the team, not with the author of the commit. The argument holds: design, PM and engineering already discussed the best outcome for members before anyone wrote code; what changes is where the conversation happens, not who answers for it.
The arrangement held "about 80% of the time", and the exception is interesting: now and then someone opens a pull request with no pairing, saying simply "I had this idea". Challenging from an ownership standpoint, positive from a mindset standpoint — and the mindset was the actual goal. Instead of "I saw that bug, I'll file a ticket", "I'll open the editor and see whether it's complicated".
Every pull request, typo fixes included, kept going through engineering review. Nothing was relaxed. That is what made it possible to open up without breaking anything.
The side effect nobody planned for
Two anecdotes from the account are worth more than an argument.
The first: a designer rebuilds the entire member-feedback flow, pulling what he needed straight out of Figma. The VP of Engineering, who thought it out of reach, walks over to his desk and finds that it isn't. He puts it down to an absent mental ceiling: the designer did not know it was supposed to be hard.
The second is more instructive still. Someone runs a prompt for a small change to an internal tool that had never been migrated to the in-house design system — one of those 80%-complete migrations nobody ever finishes. The agent, reading the repository's rule files, finds the instruction to use the current design system and to propose upgrading any deprecated components it meets along the way. The pull request lands with the small requested change and three migrated files.
In other words: a non-developer's contribution improved the quality of the codebase and advanced a migration that had been deprioritised for months. The boy-scout rule — leave the code cleaner than you found it — that everyone knows and nobody has time for, applied by someone who never had the chance to pick up the bad habit.
And the effect closes the loop: the rules, linters and tooling written to make non-developer contributions safe improved the engineers' own working environment. The two internal teams — the programme's and the developer environment's — ended up converging.
The next bottleneck is already here: review
This is the most honest part of the account, and the most useful to anyone considering the same move. The programme works, so it produces hundreds of extra pull requests. In parallel, the engineers adopt agentic tools that also multiply pull requests. Both movements converge on the same place: code review does not scale.
A regulatory constraint compounds it — ISO 27001 requires knowing how a change reaches production — which rules out answering by relaxing the vigilance.
The question Gerlic asks is more uncomfortable than the observation:
By the time you do the code review, you have to wonder: isn't it already too late? Why isn't the generated code already good? What's missing?
The goal he states is ambitious and openly uncertain: make the system learn from the feedback given, so that the same mistake is corrected only once. Not to remove review, but to stop treating it as inevitable that review absorbs the speed gained upstream.
We described the same wall from other angles with LinearB's merge rate for AI pull requests and with "vibecoding fatigue": when production accelerates and validation stays calibrated for human throughput, validation becomes the product.
"Everything has code": the unplanned extension
The project produced a shift nobody had in the original plan. Alan now maintains a repository of skills — a mix of Markdown files and scripts — that is not only about coding: meeting preparation, coaching, weekly reporting. And the anecdote that sums it up: a pull request on one of those skills was reviewed and merged by someone from the people team.
This is the move from "everyone can build" to "everything has code". The company's ways of working enter a repository, go through review, get versioned. An organisation that already takes every decision in writing had, without knowing it, a considerable head start: its context was already written down.
Discipline remains the limiting factor
This account has to be read alongside what is happening elsewhere, or the wrong lesson gets drawn. The movement is general: Ramp reports more than 1,500 internal apps shipped in six weeks by 800-plus non-engineer builders; a survey of 200 enterprise CISOs estimates that business software builders now outnumber professional developers by four to ten times in large organisations.
The downside is documented too. Thoughtworks cites 25% of AI-generated code carrying confirmed vulnerabilities and one enterprise breach in five now linked to AI-generated code; Gartner writes of "shadow attack surfaces" created by tools and agents adopted without central oversight.
Hence the distinction Aha! draws between vibe coding and PM coding, which is not just wordplay: "AI grants you the capability of a technical team, but it does not grant you the judgment of a product leader." The first starts from a solution because solutions became cheap to write; the second starts from a need, defines what success means, and only then builds.
A team that ran a workshop of this kind came away with five questions no coding tutorial teaches — and they are exactly the ones Alan had settled before opening the gates:
- Should this be built at all, or does it already exist?
- Who is it for, and how do we know their problem is the one we think it is?
- How will we test it as the models change?
- Who owns it after launch, security patches and eventual deprecation included?
- What does it cost to maintain, compared with what it solves?
The fourth is the one that gets skipped. It is the one Alan settled first.
What Survol does with this
This account describes, without naming it, the layer we work at. Three direct correspondences:
- Rules rather than tools. At Alan it was the repository's rule files that made it possible to open the door without lowering quality — to the point of enforcing a forgotten migration. That is exactly what our organisation technical constraints do: injected at the start of every session, ranked, and traced whenever an agent pushes back on one.
- A named owner, not a commit author. Every request goes through an approved specification with an attributed product decision. "Who answers for this change?" has an answer before production, not after the incident.
- The context is already written. Alan's advantage is its written decisions. Most companies do not have them — which is why Survol rebuilds the feature map from existing repositories, with a confidence level, and turns every blind spot into an open product decision rather than an assumption.
On the review bottleneck we have no magic answer, and nor does anyone else. But the direction Gerlic points to is the right one: progress will not come from reviewing faster, it will come from making sure the same remark never has to be made twice.
Sources
- If This Then Dev, “Et si n'importe qui dans l'entreprise pouvait proposer une pull request ?”, interview with Alexandre Gerlic, VP of Engineering at Alan.
- Brian de Haaff, “Vibe coding vs. PM coding”, Aha!.
- Geoff Smalling, “When everyone can build software, judgment matters more”, Fast Company, 4 August 2026.
