Vibe coding and AI-assisted programming

Someone shows you an application they built over a weekend. It works. There is a login, a database, a search function and a tidy layout. The natural question is: when will it be ready?

The question sounds simple, but it bundles together several different questions. This article takes them apart, because producing code has become cheap quickly and the work that comes after it has not become cheap at the same rate.

Where the word comes from

The term vibe coding was coined by Andrej Karpathy in February 2025. He used it to describe a way of working in which changes are accepted without being looked at and the implementation is steered by how the result behaves in use. Collins named it word of the year for 2025 and defines it as the use of artificial intelligence, prompted by natural language, to assist with the writing of computer code.

Programmer Simon Willison drew the boundary in March 2025, in a single sentence:

When I talk about vibe coding I mean building software with an LLM without reviewing the code it writes.

The title of that same piece is "Not all AI-assisted programming is vibe coding (but vibe coding rocks)", and that is the core of the distinction.

Use of the term has since widened, and in everyday speech it now often means any coding done with a model's help. So this article makes its own boundary explicit: vibe coding here means specifically the narrow method in which the source code is not meaningfully reviewed. That is Karpathy's original description, and it is also the method whose risks differ from those of reviewed work.

The boundary is necessary, because otherwise one word is doing duty for two different things.

Two working methods under one name

The distinction is often blurred in company presentations. The difference is not who writes the code but on what grounds it is accepted and who answers for the result.

Either can be workable, but the unreviewed method only where the possible damage is bounded, the environment is isolated and changes can be rolled back. The problem arises when something made the first way is presented as the second.

One documented case

In the spring of 2026 I built a pilot application for bands to use in rehearsal: songs, arrangements, chord charts, demo recordings, set lists and real-time chat in one workspace. I used a language model throughout. According to my notes, the first production version involved:

• six and a half weeks, in practice weekends
• about 13,000 lines of code, 88 files
• 24 interface components, 16 pages, 5 server functions
• 142 automated tests and 64 separate tests for the database access rules

These are figures I recorded myself, from one project. There is no control group, so they do not say how much faster this was than the same work without a model. My own view is that the difference was large, but that is a view and not a measurement.

One conclusion is nevertheless clear. Measured against Willison's boundary, this was not vibe coding. I reviewed the changes. I decided the data model, the access rules, what would be tested and what would not be built at all.

I mention it because figures exactly like these circulate online under the headline "I built an app with AI". The figures may well be true. The headline is still misleading.

What the research says about productivity

There is no single multiplier, and that is the most important finding here. Results depend on the task, the tool, familiarity with the codebase and what is being measured in the first place.

Coding activity rises far more than releases. An NBER working paper from May 2026 combined the activity of more than 100,000 GitHub developers with telemetry on their use of AI tools. In a matched event study, the adoption of autocomplete, interactive agents and autonomous agents was associated with cumulative estimates of roughly 40, 140 and 180 per cent in commits. For autonomous agents the corresponding estimate was 50 per cent for the number of projects and 30 per cent for actual releases. Across four app marketplaces the number of new apps rose moderately, but total usage did not rise at all.

The researchers call this the weak-link hypothesis: human bottlenecks in the production chain attenuate a strong productivity gain. This is an observational design and not a randomised experiment. The result is consistent with the phenomenon this article describes, but it measures GitHub activity and releases rather than costs or user value directly.

In randomised experiments more tasks were completed. Three randomised field experiments at Microsoft, Accenture and a large company involved 4,867 developers in total. Pooled, use of a coding assistant increased completed tasks by 26.08 per cent, and the benefit was on average larger for less experienced developers. The individual experiments were noisy, however, and the tools were code-completion assistants rather than the agents of 2026.

Coordination slows down. In a study of open-source projects, use of Copilot increased project-level code contributions by 5.9 per cent and the number of participating developers by 3.4 per cent. At the same time the time spent on coordination grew by 8 per cent. The overall effect was positive, but note what was measured: contributions, not delivered value.

The experienced do not automatically gain most. In METR's experiment, 16 experienced open-source developers worked in their own projects, ones they had known for years. With early-2025 tools they were 19 per cent slower than without. The researchers treat the result as a snapshot of one setting rather than a general law, and the tools have improved since.

METR continued the experiment with newer tools and published fresh figures in February 2026. They were still on the slowdown side, 18 per cent for those of the original developers who carried on and 4 per cent for newly recruited ones, though both confidence intervals extend into speedup. The researchers consider their own estimate unreliable. Recruitment and retention have become harder, and in a survey 30 to 50 per cent of developers said they had chosen not to submit some tasks because they did not want to do them without AI. The study is therefore systematically missing the developers with the most optimistic expectations. The researchers' own view is that the true benefit is larger than measured, but these data are too weak to show its size.

The overall picture is exactly what this article is about. Coding activity and the number of completed tasks grow measurably in some settings. What gets delivered all the way to finished does not necessarily grow in the same proportion.

The staircase you cannot see from outside

The model below is my own illustrative framing, not an industry standard. In reality the stages overlap and run backwards and forwards. It is here because it makes one thing visible: a program does not move from "does not exist" to "exists" in a single step.

1. Idea. What problem is being solved and for whom.

2. Specification. What the program does, for whom and under what conditions. More on this below.

3. Proof of concept. The question is narrow: is this possible at all?

4. Demo. A different thing from the previous one. A proof of concept answers a technical question; a demo is made to be shown to a person and is allowed to be a facade.

5. Minimum viable product. Its purpose is to test an assumption about a customer or a market against real feedback. By definition it does not require a login or any other single feature. It needs precisely the security and reliability properties its real use demands, and no more.

6. Release. Does this survive a user doing something nobody anticipated? Two people press the same button at once. The network drops mid-save.

7. Productisation. This involves both commercial and technical work: pricing and contract terms, but also multi-tenancy, billing logic, instrumentation and onboarding.

8. Maintenance. Who fixes this in three years' time? Libraries age, interfaces change, security holes are found.

9. Customer support. Who answers when it does not work, and how do they know what went wrong?

10. Operations. Someone watches that the service is up, takes the backups and keeps a record of outages.

Cross-cutting responsibilities

These are not steps on the staircase; they run through all of them from the start. Leave them to the end and they do not get done.

• Security and access rights. Designed together with the data model, not after it.
• Data protection and regulation. How personal data is handled is settled before any is collected. Whether the AI Act applies is determined by, among other things, the system's intended purpose and risk category and by your role in the value chain, for example as a provider or a deployer. All of these have to be known before building.
• Accessibility. Fixing it afterwards can require substantial structural changes to the interface.
• Maintainability. A structure that resists change was decided on day one. Refactoring can still improve it, but always at a higher price than deciding well at the start.

Where AI saves the most time

The following is my own estimate, not a measurement.

The core of the estimate is this: the effect is largest in the part that was already the fastest. A proof of concept and a demo have typically been cheap compared with what comes after. As they get cheaper still, the gap between the visible and the invisible work grows.

Why expertise still matters

The research does not show that experienced developers always get the larger speed benefit. In METR's setting it was precisely the experienced who slowed down in their familiar projects, and in the randomised field experiments the benefit was on average larger for the less experienced. The result varies with the task, the tool, familiarity with the codebase and the metric, so no single direction can be assumed for either group.

Skill therefore affects something other than writing speed. It affects whether the person can judge architecture, security, missing requirements and the maintainability of what was produced. A model's output does not itself guarantee any of these.

From this follows vibe coding's hard constraint. When the code is not reviewed, the point at which technical judgement would normally be exercised disappears. Accountability does not transfer to the model. It stays with the people and the organisation that approve the software and put it into use, whether or not anyone has been named.

Where the risk actually sits

In the code

Access rights. Who sees whose data. This is easy to make look correct, because when you test with your own account everything appears right.

The data model. How the data is organised can be one of the most expensive things to change, particularly once production data has accumulated and integrations have been built.

Silent failures. The save fails, but the interface reports success.

The accumulating repair debt is called technical debt. AI does not remove it; it speeds up its creation too.

In the agent

This is the most important addition of 2026, and it is often left out of the conversation entirely. A coding agent equipped with tools does not merely suggest text. Within the permissions it has been given it can read and change files, run commands, install packages and use the network, as well as read task descriptions and web content. The risk is therefore not only bad code but also what the agent does while running.

• Secrets and source code may end up being processed by the model service, or leak through tool calls, if the agent has access to environment variables and key files.
• Indirect prompt injection from task descriptions, documentation and web pages. The agent reads its instructions and the material it is working on through the same stream of text.
• Excessive permissions to files, the network and the production environment.
• Malicious dependencies and unexpected side changes nobody asked for.
• Changes to tests or safety controls while the agent is "fixing" the implementation. This one is particularly nasty, because it makes the gauge read green.

These are not one writer's private worries. OWASP treats agent application risks as a list of their own, headed by agent goal hijack and identity and privilege abuse.

The remedy is the same as in any other safety engineering: run the agent in an isolated environment, give it only the permissions the task requires, review every file it changed, and give it no direct access to production or to secrets.

Seven practices that preserve the speed advantage

Notice one thing about the structure of this article. Everything below moves work away from narrow vibe coding and towards reviewed work. That is the point. The question is not whether a model may be used, but how to get its speed without leaving responsibility unnamed.

Six of the seven are practices that existed before AI.

1. The specification is written before the model is started.

A model or an agent may set off building from a one-sentence instruction without asking for adequate detail. It makes the decisions you left unstated on your behalf, quietly and generally in the direction of finishing fastest. The specification is where those decisions get made deliberately.

A functional specification says what the program does and for whom: who uses it, what each role may see and do, and what happens when something goes wrong. Edge cases matter more here than the main functions: in my experience the main functions land correctly more often without separate instruction.

A technical specification says the data model, the access rules, what runs where, and which parts have to be replaceable later. These are the most expensive decisions to change afterwards.

An interface handoff package is worth making at the same time: views, states, colours, typography, spacing, empty states and error messages. Without one, the model reinvents the visual language in every view. This site was built on the basis of such a package too.

A model can be used to write the specification, and it is at its most useful there as an interviewer: ask it to ask you what you have left unsaid. The answers are still yours.

2. Documentation is kept current throughout, not at the end.

This has been turned on its head. Documentation used to be written for the next human being, and that is why it could be deferred. Now the model reads it and uses it as its instruction, so out-of-date documentation is not merely a gap but an active source of error.

When code appears faster than anyone can read it, documentation is often the only place where intent is preserved. The code shows what was done. What was considered and rejected shows up only where it was written down: in notes, architecture decisions, tickets or the reasoning attached to changes.

3. Version control, in small pieces.

Version control records every change and allows an earlier state to be restored. With a model it becomes essential for two reasons.

First, a model can change dozens of files at once, and without version control going back is not an operation but a wish.

Second, version control shows changes as a difference, that is, only the lines that changed. That is what makes review practically possible. Small changes about one thing are readable. One evening's thousand-line lump is not.

4. The agent is isolated and given only the permissions it needs.

This is the practical counterpart of the agent risks described above, and in practice it weighs more than the choice of model. Run the agent in a separate environment, limit its file and network access, keep secrets out of its reach, give it no direct access to production, and review every file it changed.

As an optional addition, a second model can assess the result under a different brief. It is an extra signal rather than a verification. The same model produces different results on different runs, and a model from a different vendor does not guarantee an independent judgement. The primary controls are human review, tests, type checking, static analysis and dependency scanning.

5. The test plan is made before the code.

This is not about writing tests. A model writes tests quickly. It is about deciding in advance what must never break, and that decision is a human one.

In my own project I wrote down three before the first line: chord parsing, key transposition and the access rules.

Tests speed up feedback but do not replace review. They show only that the implementation passes the checks somebody thought to include in the test set.

In March 2026 METR had four maintainers assess 296 agent-written pull requests, all of which passed the SWE-bench tests. About half of them would not have been merged into main as they were. The agents were not given the chance to revise their work in response to feedback, so this is not a ceiling on capability. It does say precisely what a passing test does not prove. The greater the risk of a change, the more independent the checks on specification, tests and implementation need to be.

6. The interface is reviewed along the way, not at the end.

A model can be used as a design reviewer: give it a view and precise criteria, and it may suggest possible shortcomings, such as inconsistent spacing or weak contrast.

A suggestion is not a finding. An image does not reliably reveal touch targets, semantic markup or screen reader behaviour, and no automated tool alone is enough to establish that a service is accessible. W3C's own evaluation guidance says as much. The criteria and the conclusion are human.

Timing decides. If the review is left to the end, the fixes land in places that have already been built on top of.

7. Modularity and portability are decided at the start.

Left unconstrained, a model optimises for finishing the immediate task, so one provider's proprietary calls spread easily through the whole codebase.

The remedy is to keep vendor-specific parts behind a thin interface. It reduces the blast radius of a change, but it does not turn switching into a one-place edit: databases, authentication and payment services differ in meaning and behaviour as well, and an interface does not remove those differences.

This is not about independence as an absolute principle; it is about controlling switching costs. Dependencies are not eliminated, they are chosen, and the same thinking applies to models as it does to sovereign AI more broadly.

When a lightweight approach is enough

Vibe coding suits work where the extent of the damage is bounded and changes can be rolled back. The number of users and whether something is disposable are not criteria: an internal tool for five people can handle payroll, and a one-off script can destroy a thousand files.

Ask these:

• How sensitive is the data involved? Public material is one thing, personal data another.
• What does it have access to? Read access to one directory is not the same as production credentials.
• Can the changes be rolled back? Version control and backups change the answer.
• How far does the damage reach if this goes wrong? To you, your team or your customers.
• Is it isolated? A separate environment bounds most of the consequences.

Depending on the answers, the same task can be light or heavy regardless of how small it looks.

One use is worth ruling out. This method is not, as it stands, suited to practising the understanding of code. In Anthropic's randomised experiment with 52 developers, the AI-assisted group averaged 50 per cent on an immediate comprehension quiz against 67 per cent for the group that coded by hand, and the small difference in time between the groups was not statistically significant. The experiment was small and short and says nothing about learning over the long run, but it is enough to caution against presenting unreviewed AI-assisted coding as a reliable way to learn to read code.

Killing an idea cheaply is all the more valuable a use. Build it in a day, notice it does not work, throw it away. At best a wrong idea can be abandoned in days rather than months.

When code must be reviewed

When the price of a mistake falls on somebody else:

• customer or patient data
• money, billing and payments
• safety and physical equipment
• anything that has to still work in five years
• anything that has to be defensible to a regulator afterwards

This does not mean AI may not be used. It means the working method is the right-hand column of the table.

Four questions before a demo is presented as a product

1. Has anyone reviewed the code? If not, this is an experiment regardless of how finished it looks.
2. What happens when a user does something that was not anticipated? Ask to be shown, not told.
3. What did the agent have access to while it was being built? Production credentials, customer data, the network?
4. Who fixes this in three years and with whose money? Maintenance is a budget line, not an attitude.

What to take away

In one sentence

AI has in some settings substantially increased the production of code and completed software tasks, but the size of the benefit varies, and in NBER's 2026 data the growth faded on the way from commits to projects, to releases and to total app-marketplace usage, so a demo produced quickly does not on its own establish a product's readiness or its value to users.

Disclosure

The pilot application described above is my own project and is not for sale. The figures are ones I recorded myself and have not been externally verified.