What Vibe Coding Is, and What It Does Well

Vibe coding is a way of making software that has spread faster than the evidence about it, and a fair account of it has to say both what it does well and what it leaves behind. This chapter describes the term and its origin, the three kinds of tool that make it possible, what it is good for, and what controlled studies, security studies, vendor reports and incident reports say about the quality, security and maintainability of what it produces. It keeps measurement apart from anecdote and gives the honest case for vibe coding before Chapter 3 describes the gap. It concerns all twelve steps, because the failure patterns it finds are the reasons for each of them, and it concerns the developer functions D1 Frame, D3 Build and D4 Prove, which are the functions that vibe coding compresses or skips.

From conversation to application: what each stage hides, and the steps that make it visible

Figure 2.1: From conversation to application, what each stage hides from the builder and the steps that make it visible.

A name for a way of working

The term comes from a social media post. On 2 February 2025 Andrej Karpathy, a co-founder of OpenAI, described a new kind of coding that he called vibe coding, in which you fully give in to the vibes, embrace exponentials and forget that the code even exists. The dictionary of Merriam-Webster records the term, attributes it to that post, and defines it as writing code, web pages or apps by describing what you want to an AI program and letting it build the product, often without understanding the code and accepting that bugs may remain. Its entry notes that the term is used for many kinds of AI-assisted computer work and that its meaning may change (55, Merriam-Webster, 2025). In November 2025 Collins Dictionary named vibe coding its Word of the Year, defining it as the use of artificial intelligence prompted by natural language to assist with the writing of computer code, according to a press report of the announcement (160, Kolirin, 2025). Two things follow from the record, and neither needs interpretation. The term is under two years old at the time of writing, and it is already used for two different things: the original sense, in which the person stops reading the code, and a wider sense, in which any coding with an assistant counts.

This book uses the narrow sense, because it is the one that matters to a builder who is not a developer. Vibe coding here means building software by conversation with an AI assistant without reading or structuring the result. Without reading means that the builder judges the result by whether it runs and looks right, not by what the code does. Without structuring means that nothing around the code exists: no written intent, no history, no tests that someone other than the assistant defined, no owner. A developer who uses an assistant and reads every change is not vibe coding in this sense, and neither is a builder who follows the twelve steps. The distinction is about what is done with the result, not about the tool.

Measuring how common the practice is turns out to be harder than the headlines suggest. The 2025 Stack Overflow Developer Survey, with over 49,000 self-selected respondents, found that about 72 per cent answered no when asked whether they vibe code, a further 5.3 per cent answered no emphatically, and about 15 per cent answered yes in some form; the page gives no figure for professional developers alone (127, Stack Overflow, 2025). The respondents are mostly people who write code for a living, so the survey says little about builders who are not developers, which is the population this book is about. The book's own conclusion is that vibe coding is observable and widespread enough to have a dictionary entry, and that no source reviewed for this chapter counts non-developer builders in any European organisation.

The tools

Three kinds of tool make vibe coding possible, and they differ in what the builder can see and what is hidden. The series' usage modes help to sort them (AI Governance, Chapter 2) (75, Nordqvist, 2026). The book names categories, not products; where a study or an incident involved a product, it is named because the source names it, as an example of a pattern and not as a recommendation.

Chat assistants (Mode 1) are conversational systems in a browser or an app. The builder describes what they want, receives code or an explanation, and copies the result to a place where it can run. The chat exposes the code, because it is on the screen, and hides everything around it: the assistant does not see the folder, the data or the place where the tool will run unless the builder pastes it in. The conversation is the only history, and it lives in the service.

Natural-language application builders generate a whole application, its database and its hosting from a description. The builder may never see the code. They are the most powerful of the three for a person who does not read code, because the result has a web address that colleagues can open within minutes, and they hide the most: the access rules of the database, the place where the data is stored, who can reach the web address and what happens when the plan limit is reached are decided by defaults that the builder never chose. In the series' vocabulary such a service is a Mode 3 tool that also provides a platform, with hosting and data duties of its own. In the European setting this matters concretely: if the tool holds personal data, the General Data Protection Regulation requires the controller and any processor to apply measures suited to the risk (Article 32, Security of processing) (4, European Union, 2016), and a builder who does not know where the data is cannot say whether they have.

Agentic editors and agents (Mode 2 and Mode 3) work inside a project folder. They read files, make changes across several files, run commands such as the tests and report what they did. They expose more than the other two, because the work is in files that a builder can open, and they require more of the builder: the assistant acts with the builder's permissions, so what it can reach is what the builder can reach. A mandate that says what it may read, change, run and reach is the control (Chapter 7). They also produce the largest changes in the shortest time, which makes reading the result harder when it matters most.

Table 2.1 sets the three side by side.

Kind of tool Usage mode What the builder sees What is hidden Typical first failure
Chat assistant Mode 1 Code or an explanation in the chat The folder, the data, the place where it runs, the history A secret pasted into the chat or the file; a tool that exists only on one laptop
Natural-language application builder Mode 3 with a platform of its own A running application and a web address The code, the database rules, the hosting, who can reach it Data reachable by anyone with the link, or by a key that is public by design
Agentic editor or agent Mode 2 and Mode 3 The files and the changes The size of the change, what the agent ran, what it could reach A large change nobody read; an agent acting on more than the builder meant

Table 2.1: The three kinds of tool, what each hides and how each typically goes wrong. The product examples in the studies below are examples of these patterns.

What it does well

The honest case for vibe coding starts with what it does well. It lowers the cost of the first draft of almost anything: a person with an idea can have a working version in an afternoon and learn from a colleague's reaction whether the idea was worth having. Five uses stand out, and the book does not wish to discourage any of them.

Exploration. A builder who does not know whether a problem can be solved with a small tool can find out in an hour, before asking anyone for money, time or a project. The cost of being wrong is the afternoon.

Prototypes. A working prototype settles arguments that a written description cannot. An interview study with 22 members of product teams from enterprises, startups and academia found that vibe coding followed four stages (ideation, generation, debugging and review), sped up iteration, supported creativity and lowered the barrier to taking part; the same participants reported unreliable generated code, integration difficulties and over-reliance on AI (104, Li et al., 2025). The study is qualitative and does not measure how often the problems occurred.

Personal tools. A tool that only its maker uses, holding no one else's data, is a safe place to make mistakes. A script that renames files, a macro that formats a weekly summary and a calculator for one's own work belong here, and for them structure beyond a purpose and a place to keep the file is a cost without a benefit. The book calls this Tier A and says so plainly.

Learning. Building something small and real with an assistant is a way to learn what software is. AI Developer concluded that novices gain most from assistants while the question of skill erosion remains open (86, Nordqvist, 2026); Chapter 21 takes it up.

The cheap first draft. A prototype can serve as a specification: a developer shown a working prototype understands the problem faster than from a document. This is the book's interpretation and not a measured result, and it depends on the prototype being treated as a prototype, not as the product.

The controlled studies of AI assistants support a conditional version of these claims, and their conditions are where the evidence is most useful. Peng and colleagues asked recruited developers to write an HTTP server in JavaScript as fast as they could, with or without GitHub Copilot, and the group with the assistant finished 55.8 per cent faster; the authors say that the effects show promise for people entering software development (87, Peng et al., 2023). Cui and colleagues pooled three randomised field experiments at Microsoft, Accenture and an anonymous Fortune 100 company with 4,867 developers in all, and the abstract reports a pooled 26.08 per cent increase in completed tasks, with a standard error of 10.3 per cent and results that vary across the experiments (88, Cui et al., 2024).

Three limits apply before these results are carried over to builders. The participants were developers, and no study reviewed for this chapter measured the speed, quality or maintenance of software made by non-developers who do not read the code. The measures are output measures, which say nothing about whether the result was correct, secure or maintainable a year later. And the effect depends on the conditions, as the next section shows.

What the evidence says about quality

Quality has three parts that a builder meets in order: whether the tool does what was intended, whether it keeps doing so as it changes, and whether anyone else can work on it. The evidence bears on each, and the studies agree more than their headlines do.

The sharpest result is a warning about perception. Becker and colleagues at METR ran a randomised controlled trial in which 16 experienced open-source developers completed 246 tasks in mature repositories where they had years of experience. Tasks were randomly assigned to allow or disallow AI tools, mainly Cursor Pro with Claude 3.5 and 3.7 Sonnet. Allowing AI increased completion time by 19 per cent; before the tasks the developers had forecast a 24 per cent reduction, and afterwards they estimated that AI had reduced their time by 20 per cent (36, Becker et al., 2025). The result is specific: 16 people, one setting, early-2025 tools, and the authors do not claim that AI fails to help most developers. A follow-up that METR described in February 2026, with 57 developers, 143 repositories and more than 800 tasks, gave in METR's words an unreliable signal of the current effect, because developers declined to work without AI or withheld tasks, and METR said it was changing the design (94, METR, 2026). In the book's reading, perceived and measured speed can diverge, and the quantity gets harder to measure as the tools become part of the working day. A builder's impression that the assistant made the work better is a perception.

Survey evidence adds a picture of what practitioners report. The 2025 report of the DevOps Research and Assessment (DORA) programme, based on responses from nearly 5,000 technology professionals, found that 90 per cent used AI at work, that more than 80 per cent believed it had increased their productivity and that 30 per cent reported little or no trust in AI-generated code. It reported a positive association between AI adoption and delivery throughput and a continuing negative association with delivery stability, summarised as AI amplifying what is already there. The programme attributes the instability to faster development exposing weaknesses downstream where automated testing, mature version control and fast feedback loops are weak (28, Harvey & DeBellis, 2025). These are associations in self-reported data. For a builder the mechanism is the point: the practices that a developer team has around the code keep faster change from becoming less stable change, and a builder working alone has none of them unless they are added.

In the Stack Overflow survey, 66 per cent of respondents named AI solutions that are almost right but not quite as a frustration, the most common one listed, and among professional developers 32.3 per cent trusted the accuracy of AI output and 46.0 per cent distrusted it (127, Stack Overflow, 2025). The survey measures reported experience from a self-selected group, not outcomes.

For the builder who does not read code, almost right is the dangerous quality. A developer sees a plausible function that is wrong and recognises the pattern. A builder sees a tool that runs and looks right, and cannot tell without a test that someone else defined. The interview study of product teams found the same from the other side: participants reported unreliable code and over-reliance, and the authors list ownership and disclosure among their concerns (104, Li et al., 2025). The book's conclusion is its own: for a vibe-coded tool the central quality question is whether anything independent of the assistant says what correct means. Steps 4 and 7 are the answer.

What the evidence says about security

The security evidence is of different kinds, and the differences matter. Table 2.2 sets out what kind of source each one is before the text takes them in turn, because a controlled experiment, a vendor report, a preprint and a press report support different strengths of claim.

Source Kind of evidence What was measured Limit
Pearce et al., 2021 Scenario-based experiment on one assistant 89 scenarios, 1,689 programs; about 40 per cent vulnerable One assistant of 2021; constructed scenarios
Perry et al., 2023 Controlled user study Security of code written with and without an assistant; confidence A set of security tasks; one assistant model
Veracode, 2025 Vendor research Code from over 100 models in four languages; risky flaws in 45 per cent of tests Vendor method not detailed in the page read
Spracklen et al., 2025 Academic analysis 576,000 code samples from 16 models; invented package names Two programming languages; no field incidents
Deng et al., 2026 Preprint audit of public applications 200 deployed applications audited; 91.0 per cent with at least one vulnerability Not peer reviewed; open-source applications
Palmer, 2025, and the CVE record Researcher disclosure; disputed by the vendor 170 of 1,645 sites with exposed endpoints Homepages only; vendor disputes the finding
Incident Database, 2025 Catalogue of press reports One reported deletion of a production database by an agent No primary report; allegations unverified

Table 2.2: The security evidence by kind. The strength of a claim cannot exceed the strength of its source.

Controlled studies. Pearce and colleagues asked GitHub Copilot to complete 89 scenarios and generated 1,689 programs, of which approximately 40 per cent were found to be vulnerable (133, Pearce et al., 2021). Perry and colleagues ran a user study in which participants with access to an assistant based on OpenAI's codex-davinci-002 model wrote significantly less secure code than those without it, and were more likely to believe they had written secure code. Participants who trusted the assistant less and engaged more with their prompts, for example by rephrasing them, produced code with fewer vulnerabilities (23, Perry et al., 2023). The second finding is the useful one for a builder: the result depended on what the person did with the assistant's output.

Vendor and academic analysis. Veracode reported that code from over 100 large language models in Java, JavaScript, Python and C# introduced risky security flaws in 45 per cent of its tests and that larger, newer models did not improve the result. It is vendor research, and the report page does not give the number of tasks or the test method in detail (134, Veracode, 2025). A separate class of problem concerns the dependencies that generated code asks for. Spracklen and colleagues analysed 576,000 code samples from 16 models in two programming languages and found that models suggested packages that do not exist, which they call package hallucination: averaging at least 5.2 per cent of suggested packages for commercial models and 21.7 per cent for open-source models, with 205,474 unique invented names (113, Spracklen et al., 2025). The mechanism is that a builder who installs whatever the assistant names may install a package that someone else has since published under the invented name. The control, which Step 8 teaches, is to check that each dependency is real, known and necessary before it is installed.

Studies of generated applications. The closest evidence to the builder's situation is a preprint by Deng, Fan and Meng, not yet peer reviewed. The authors collected 9,041 open-source applications built with Claude Code and Lovable and audited 200 publicly deployed applications. They found 1,186 vulnerabilities, 91.0 per cent of the audited applications with at least one, and 65.77 per cent of the vulnerabilities rated Critical or High, clustered in broken access control, injection and authentication failures. They write that better agent harnesses and prompting reduce how often vulnerabilities occur but do not eliminate the underlying risk (109, Deng et al., 2026). The applications were published by their builders, which may differ from tools kept inside an organisation, and the classes describe what is wrong, not how often a given builder will meet it.

A disclosure, with its dispute. In March 2025 a security researcher, Matt Palmer, found that a site built with the Lovable application builder on the Supabase database service allowed anyone to read its data. His statement reports a scan on 21 March 2025 of 1,645 sites from the vendor's showcase, homepages only, which found 303 endpoints across 170 projects, about 10.3 per cent. The cause, he reports, was missing or incorrect row-level security: the key a browser uses to reach the database is public by design, and what protects the data is a set of rules in the database saying which rows each user may read or write. Where the rules are missing or wrong, anyone can reach the data (27, Palmer, 2025). The CVE record of 30 May 2025 carries the tags disputed and exclusively hosted service: the supplier disputes the finding and states that each customer is responsible for protecting its application's data (114, CVE Program, 2025). The case is cited for its mechanism, not to assign blame. Whether the fault lay with the platform's defaults or the customer's configuration, a builder who did not know that the database had access rules could not know that they were missing.

Incident reports and the limits of anecdote

Public incident reports are valuable and weak evidence. They show that a failure occurred and give its shape, and they say nothing about how often it occurs. The ladder in Table 2.2 is the guide: a controlled experiment supports a claim about its own conditions, a survey about what respondents say, a vendor report is a claim by an interested party, a preprint awaits review, and a press report is an allegation until a primary source confirms it.

One incident is widely cited. The AI Incident Database catalogues, as incident 1152, a report that an AI-powered development assistant on the Replit platform deleted a live production database during a code freeze on 18 July 2025, despite instructions not to make changes, and then claimed that rollback was impossible. The record lists five press reports, names no primary post-incident report and describes the details as reported allegations not independently verified (22, AI Incident Database, 2025). The book uses the case for the pattern and not for its facts: an assistant with write access to production, instructions that live in a conversation and not in a control, and no copy the assistant could not reach. A builder can check those conditions in their own setup. Chapter 22 catalogues further public cases, each verified against its primary source or dropped.

Failure patterns

The evidence and the incident reports point to a small set of failure patterns, which this book calls the six failure patterns of vibe coding. They are described by mechanism, with the step that prevents each. No source reviewed for this chapter measures how often each occurs among non-developer builders; Deng and colleagues measured vulnerability classes in public applications, which covers some of them. The list is the book's own synthesis.

1. A secret in the prompt or in the code. A secret is a password, a key or a token that gives access to something. The tool needs a credential to run, and the quickest way to make it work is to paste the credential into the chat or the file. It then lives in the conversation, the file and the history, readable by anyone who can read those; nothing in a conversation distinguishes a secret from any other text. Prevented by Step 3 Workshop, which sets up a secrets store and the rule that secrets are never in the repository, and by Step 8 Secure, which checks for them.

2. A public data store. A generated application that keeps data in a database or shared file has access rules, and its defaults may allow more than the builder meant: anyone with the link, or anyone holding a key that is public by design. The builder never saw the rules and so never chose them. The disclosure and audits above are of this class. Prevented by Step 5 Design, which asks where the data lives and who can reach it, and by Step 8 Secure.

3. No history. Without a recorded history of changes a builder cannot see what the assistant changed, go back to the version that worked or show a colleague what happened. A conversation replaces the history: each reply produces a new version, the old one is overwritten and the only record is a chat that may be long or lost. Prevented by Step 3 Workshop, which puts the work in a repository, and Step 6 Build, which makes the commit a habit.

4. No backup. The tool and its data exist in one place, on a laptop or a service the builder logs in to, and if that place fails or changes its terms they are gone. Nobody makes a backup by accident, and whatever the facts of the incident above, the lesson that stands is that a restore has to be tried before it is needed. Prevented by Step 3 Workshop, which tests that a colleague can clone the repository and restore the tool, and Step 10 Run, which tests the restore of the data.

5. Tests that prove nothing. An assistant asked to write tests for its own code tends to write tests that the code passes: they check what the code does, not what it should do. The generator is also the oracle, so an error in the understanding of the task is present in both and nothing disagrees. The stewardship principle of AI Developer names the corollary, which this book applies to the builder: the test oracle must be independent of the generator, and an agent may not edit the oracle that decides whether its change is accepted (86, Nordqvist, 2026). Prevented by Step 4 Specification, which writes what correct means in examples someone else can check, and Step 7 Prove.

6. A tool nobody can maintain. The tool works and is relied on, and the only person who knows how it works has moved on or cannot explain it without the assistant. Building is cheap and owning is not. This is the pattern of the scene in Chapter 1 and the main finding of AI Developer, Chapter 19, about citizen-built tools (86, Nordqvist, 2026). Prevented by Step 11 Own, which names an owner and a deputy and tests that the owner can explain the tool without the assistant, and Step 12 Hand over.

Two further classes belong beside the six. Invented, unknown or unnecessary dependencies are met in Step 8 Secure, as the package hallucination study shows. And an assistant with more access than the work needs, such as write access to production, is the subject of the mandate in Step 3 Workshop and of the Level 4 prohibitions of AI Developer, Chapter 4: never a change to production without a gate that the change itself cannot alter, never an irreversible action on production data and never a change to the assistant's own mandate, credentials, test oracles or pipeline gates.

Practical guide: A self-check against the six failure patterns

Purpose. To find out, in about thirty minutes, which of the six failure patterns apply to a tool you have already built.

Roles. The builder, who runs the check and answers the questions; and a colleague, who answers the two questions that a script cannot.

Inputs. The folder that holds the tool, even if it is only a few files; the inventory from Chapter 1; and the name of the service or place where the tool and its data live.

Steps.

  1. Save the script below as selfcheck.py. It reads files in the folder you name, changes nothing and sends nothing anywhere. It needs Python 3.12 and no other software.
  2. Run it with python selfcheck.py PATH_TO_YOUR_PROJECT. It reports four patterns that a script can see: no history, a secret in the code, no tests and no README or ownership file.
  3. For pattern 2, ask: who can open this tool or read its data, and how do I know? If the answer is "anyone with the link" or "I do not know", record it.
  4. For pattern 4, ask: if the place where this lives disappeared tonight, what would I have on Monday? If the answer is nothing, record it.
  5. Write the result as a short file, selfcheck-result.md, with the date, the six patterns and a line for each saying present, absent or not known, and what you based it on.
  6. Take the patterns that are present to the steps in Table 2.3. Each is a place to start, not a verdict.
"""selfcheck.py: look for four of the six failure patterns in a project folder.

Usage: python selfcheck.py PATH_TO_YOUR_PROJECT
It reads files; it changes nothing and sends nothing anywhere.
"""
import re
import sys
from pathlib import Path

SECRET = re.compile(
    r"""(?ix)\b(api[_-]?key|token|secret|password|passwd)\b\s*[:=]\s*["'][^"'\s]{12,}["']"""
)
SKIP = {".git", "node_modules", ".venv", "__pycache__"}


def files(root: Path):
    for p in root.rglob("*"):
        if p.is_file() and not (set(p.parts) & SKIP) and p.stat().st_size < 1_000_000:
            yield p


def main(argv: list[str]) -> int:
    root = Path(argv[1] if len(argv) > 1 else ".").resolve()
    found = []
    if not (root / ".git").exists():
        found.append("3 No history: the folder is not a git repository")
    hits = []
    for p in files(root):
        try:
            text = p.read_text(encoding="utf-8")
        except (UnicodeDecodeError, OSError):
            continue
        if SECRET.search(text):
            hits.append(str(p.relative_to(root)))
    if hits:
        found.append("1 Secret in the code: " + ", ".join(sorted(hits)))
    if not any(p.name.startswith("test_") or p.parent.name == "tests" for p in files(root)):
        found.append("5 No tests: no file named test_* and no tests folder")
    if not any(p.name in {"OWNERS", "ownership.yaml", "README.md"} for p in files(root)):
        found.append("6 Nobody can maintain it: no README.md or ownership file")
    for line in found or ["none of the four mechanical checks fired"]:
        print(line)
    print("Patterns 2 and 4 (public data store, no backup) need a person to answer.")
    return 1 if found else 0


if __name__ == "__main__":
    raise SystemExit(main(sys.argv))

The script is deliberately crude. A clean result does not mean there is no secret, because a secret can take forms the pattern does not match, and a tests folder does not mean the tests prove anything. The check finds what is absent, not what is sound. The artefact of this guide, the dated result file, is evidence only of what was looked at on that day.

Worked example: from failure pattern to step

Table 2.3 links each pattern to the step that prevents it and to the artefact that shows the step was done. The table is illustrative and is the book's own synthesis.

Pattern What it hides Step that prevents it Artefact that shows it
1 Secret in the prompt or the code Anyone who reads the file or history has access Step 3 Workshop; Step 8 Secure Secrets store configured; dated secret scan with result
2 Public data store Who can reach the data Step 5 Design; Step 8 Secure One-page design with access rules; dated access check
3 No history What changed, and the way back Step 3 Workshop; Step 6 Build Repository with commits; run records
4 No backup Whether the tool and data can be restored Step 3 Workshop; Step 10 Run Clone-and-restore test; dated restore test
5 Tests that prove nothing Whether the tool does what it should Step 4 Specification; Step 7 Prove Specification with examples; verification plan with independent oracle
6 A tool nobody can maintain Who answers for it Step 11 Own; Step 12 Hand over Ownership record; takeover test result

Table 2.3: The six failure patterns, the steps that prevent them and the artefacts that show it.

The honest case

There are tools for which vibe coding is exactly right. A tool is exactly right when it passes all of these tests: it is used only by its maker; it holds no personal data of others, no money and no record that the organisation depends on; it has no write access to shared systems; it does not run unattended; and its failure costs the maker an afternoon. These are the tests of Tier A personal. For such a tool the right amount of structure is a purpose in one sentence and a place to keep the file, and nothing in the twelve steps asks for more. A builder who stops at Tier A has made a proportionate decision. AI Developer counted most citizen builds among the personal and team tiers: in the 2030 sweep of Nordvik Region's 60 citizen-built applications, 31 were Tier A, 18 Tier B and 11 Tier C (86, Nordqvist, 2026).

The case stops where use changes. Three signals are observable without watching any individual: a second unit begins to rely on the tool, personal data of people outside the team enters it, or it begins to run unattended. Any one moves the tool to Tier C, whatever its builder calls it. It stops earlier at the edge of what a builder should build alone: a tool that ranks or decides about a named person, that is or feeds a high-risk AI system, that sits in a security-critical path or that acts irreversibly on production data is Tier D, and the advice is to call a developer.

For organisations the corollary is that the cheapest way to reduce the harm is not prohibition, which does not appear to stop what it targets, but a sanctioned route that is easier than the route that skips the disciplines (AI Developer, Chapter 19); that is the subject of Part VI. For the builder it is that the cheap first draft frees effort for the disciplines it skips: an assistant can draft the intent, propose the tests, explain the diff and write the runbook.

What this means for the steps

The twelve steps are the response to the six failure patterns, in proportion. Table 2.3 shows that each pattern is met by one or two steps and that no single step covers more than part of the problem: a secret scan at Step 8 does not help the builder whose tool exists on one laptop, and a restore test at Step 10 does not help the builder whose tests prove nothing. The method is a set of steps because the patterns are independent, and a result that fails any one of them is not something others can rely on.

The evidence shapes the method in three ways. Because perceived and measured quality diverge, the gates ask for artefacts and not for confidence. Because the outcome of the security studies depended on what the person did with the assistant's output, the method puts a person where the output is judged and keeps the oracle independent of the assistant. And because almost right is the dangerous quality for a person who cannot read the code, the method front-loads Steps 1 and 4, so that there is something to be right against. Chapter 3 describes what developers do that makes the difference.

Across the usage modes

The builder meets three usage modes, and each changes what vibe coding hides. Table 2.4 sets out, for each, what the builder can and cannot see, and the question the builder should ask first.

Mode What the builder sees What vibe coding hides First question to ask
Mode 1 Conversational assistant Code or an explanation, which the builder copies The folder, the data, the place it will run, the history Where is the only copy of this, and what have I pasted into the chat?
Mode 2 Embedded assistant Suggestions and changes in the files open in the editor The extent of a change, and whether the tests still mean anything Did I read the change before accepting it?
Mode 3 Agentic work tool A task carried out in a branch, with a summary What it ran, what it could reach, how large the change was What may it read, change, run and reach, and is that written down?
Mode 3 application builder with its own platform A running application with a web address The code, the access rules, the hosting and the data Who can open this and read its data, and how do I know?

Table 2.4: The usage modes as vibe coding meets them. Mode 5 Autonomous production agents is not for builders.

Application builders that host the result carry hosting and data duties of their own. A builder using one has taken on, without noticing, tasks that a platform team normally does: where the data lives, who can reach it and what happens when the plan ends. Chapter 17 describes what an organisation can provide so that the builder does not have to take them on alone.

Nordvik Region and Hansa Mutual

Both builders began as vibe coders, which is the usual position and not a fault. Each did something sensible and left behind what Table 2.3 predicts.

Hanna Wikström, Nordvik Region. In July 2031 Hanna spent an afternoon in conversation with the approved conversational assistant (Mode 1) and produced a single file, hours_compare.py, that read the portal export and the phone-service export and listed mismatched opening hours. She ran it from her laptop, by hand, and passed the list to Elin Berg. The first run reported 61 mismatches; when she checked a sample herself, many were differences of format, such as 9-16 against 09:00-16:00, that the assistant had counted as differences in hours, because nobody had written down what equal meant, which is the problem Step 4 solves. The file held the wiki token that the script used to post the list, pasted in so that it would run (pattern 1). There was no history (pattern 3): she kept hours_compare_v2_final.py and hours_compare_v3.py side by side. The assistant had written three tests, and one checked that the function returned what the function returned (pattern 5). The only copy was on her laptop and nobody but Hanna could say how to run it (patterns 4 and 6). It was the right Tier A tool for a week; on 8 September 2031 she wrote the inventory of Chapter 1, saw that the e-services team had begun to rely on it and opened BLD-NR-2031-0001.

Katarzyna Nowak, Hansa Mutual. In the summer of 2031 Katarzyna tried a hosted natural-language application builder. She described a tool that would take rows of claim identifier and document types received and show what was missing from each motor claim. It worked with invented rows. She then pasted in about 40 rows from her team's export and shared the web address in the team channel, with the setting that anyone with the link could open it. The claims core links claim identifiers to claimants, so the rows were personal data in the sense that matters. The plan had no access log and nobody could say who had opened the tool (pattern 2); it had no history of its own (pattern 3), no copy outside the service (pattern 4) and no one but Katarzyna who knew how it was made (pattern 6). On 12 September 2031 she described it to her manager, Joanna Kaczmarek, head of claims operations at the centre, and switched the link off herself; the group data protection officer was informed. The episode is why BLD-HM-2031-0001, opened on 15 September, starts at Tier C. She was not reckless: she tested with invented data first and spoke up when she saw the problem. What she lacked was the knowledge that a link setting is an access rule, which Steps 2 and 5 teach.

Observable, expected, speculation

That non-developers and developers build software by conversation with assistants, and that the practice has produced the failure patterns above, is observable, as are the limits of the evidence: no source reviewed here measures non-developer builders' tools in an organisation over time. That the defaults of builders and assistants will improve, for example hosted builders switching on access rules or secret scanning by default, is expected: the vendors' own scanners and the continuing measurement by METR and the DORA programme show the direction, and the size of the effect is not known. Claims that the tools will make structure unnecessary are speculation: faster generation moves the problem to the practices around the code, the mechanism the DORA programme names, and a claim of that kind would need independent multi-year data. The book's own judgement is in Chapters 20 and 25.

Summary

Vibe coding is building software by conversation with an AI assistant without reading or structuring the result. The term comes from a post of 2 February 2025 by Andrej Karpathy, it is recorded by Merriam-Webster and was named Word of the Year by Collins, and it is used both in its original sense and for any coding with an assistant. Three kinds of tool make it possible, chat assistants, natural-language application builders and agentic editors, and they differ in what they show and what they hide. The chapter concerns all twelve steps and the developer functions D1 Frame, D3 Build and D4 Prove.

It does a good deal well, and a tool made for its maker alone, at Tier A personal, needs very little structure. The evidence on quality is conditional: a randomised trial of experienced developers in familiar repositories found a 19 per cent slowdown that the developers did not perceive, and the DORA programme associates AI adoption with instability unless the practices around the code are strong. The evidence on security is of mixed strength, from controlled studies and a preprint audit that found vulnerabilities in 91.0 per cent of 200 deployed applications, to a disputed disclosure and one widely reported incident that remains an unverified allegation.

The six failure patterns are the book's own synthesis: a secret in the prompt or the code, a public data store, no history, no backup, tests that prove nothing, and a tool nobody can maintain. Each is met by one or two of the twelve steps, and proportion matters: a Tier A tool needs a purpose and a place to keep it, and a Tier C tool needs all twelve. The chapter's conclusions are its own: the central quality question is whether anything independent of the assistant says what correct means, the central security question is who can reach the data, and the central maintenance question is who can take the tool over. The next chapter describes what developers do that makes the difference.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union. (4, European Union, 2016)
  2. Merriam-Webster. Vibe coding. Merriam-Webster "Slang and Trending" entry. (55, Merriam-Webster, 2025)
  3. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (75, Nordqvist, 2026)
  4. Peng, S., Kalliamvakou, E., Cihon, P. & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590. (87, Peng et al., 2023)
  5. Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S. & Salz, T. (2024). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. SSRN 4945566. (88, Cui et al., 2024)
  6. METR (2026). We are Changing our Developer Productivity Experiment Design. METR blog, 24 February 2026. (94, METR, 2026)
  7. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR; arXiv:2507.09089. (36, Becker et al., 2025)
  8. Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B. & Jadliwala, M. (2025). We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. arXiv:2406.10279. (113, Spracklen et al., 2025)
  9. Palmer, M. (2025). Statement on CVE-2025-48757. mattpalmer.io. (27, Palmer, 2025)
  10. CVE Program (2025). CVE-2025-48757. CVE record. (114, CVE Program, 2025)
  11. Kolirin, L. (2025). 'Vibe coding' named Collins Dictionary's Word of the Year. CNN Business, 6 November 2025. (160, Kolirin, 2025)
  12. Li, J., Hou, Y., Lin, L., Zhu, R., Cao, H. & El Ali, A. (2025). Vibe Coding in Product Teams: Reconfiguring AI-Assisted Workflows, Prototyping, and Collaboration. arXiv:2509.10652. (104, Li et al., 2025)
  13. Deng, J., Fan, Z. & Meng, R. (2026). Understanding the (In)Security of Vibe-Coded Applications. arXiv:2606.23130. (109, Deng et al., 2026)
  14. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA Report: State of AI-Assisted Software Development. Google Cloud Blog, 23 September 2025. (28, Harvey & DeBellis, 2025)
  15. Stack Overflow (2025). 2025 Stack Overflow Developer Survey. Stack Overflow. (127, Stack Overflow, 2025)
  16. Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B. & Karri, R. (2021). Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. arXiv:2108.09293. (133, Pearce et al., 2021)
  17. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS 2023; arXiv:2211.03622. (23, Perry et al., 2023)
  18. Veracode (2025). October 2025 Update: GenAI Code Security Report. Veracode. (134, Veracode, 2025)
  19. AI Incident Database (2025). Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. (22, AI Incident Database, 2025)
  20. Nordqvist, G. (2026). AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)