What does it feel like using AI to write code nowadays — also known as vibe coding?

Ask two experienced engineers what it is like to write code with AI in 2026 and you can get answers that do not appear to describe the same planet. One shipped in a weekend what used to take a quarter. The other spent Thursday unpicking four hundred lines of confident nonsense that a machine produced in nine seconds.

Both are telling the truth. That is the interesting part, and it is what this post is about.

Where the word came from — and why it causes arguments

Andrej Karpathy coined vibe coding in February 2025, and his original description was deliberately casual: you talk to the model, accept what it gives you, do not really read the code, and "forget that the code even exists." He was describing throwaway weekend projects — the kind where being wrong costs nothing.

The phrase escaped immediately. By November 2025 Collins Dictionary had made it their word of the year, defined far more broadly as using AI prompted by natural language to write software. Somewhere in that journey the term stopped meaning "I am not reading the output" and started meaning "I used AI to write code" — a completely different activity.

That drift is the source of most of the argument. When someone says vibe coding produces unmaintainable slop, they usually mean Karpathy's original version, nobody reading anything, and they are right. When someone says it is now how serious software gets built, they usually mean a reviewed, tested, agent-assisted workflow, and they are also right. The two camps are having a heated disagreement about two different things.

For the rest of this post, vibe coding means the broad sense — writing software with AI — and the distinction gets called out where it matters.

What it actually feels like

Set the discourse aside; here is the texture of the day.

The blank page is gone. Starting is no longer the hard part — there is something on screen within a minute. For many people that alone is what makes the tools feel transformative.

The work moved from writing to deciding and reading. You spend the day specifying, steering and reviewing rather than typing. Whether you enjoy that depends entirely on whether you enjoyed those activities before.

The first 80% arrives startlingly fast; the last 20% behaves normally. The demo works in twenty minutes. The edge cases, the error handling and the one integration that actually matters take the rest of the week.

"Almost right" is the dominant failure mode, and it is peculiarly tiring. In Stack Overflow's 2025 developer survey the top frustration — around two-thirds of respondents — was not that AI answers are wrong, but that they are almost right but not quite. Obvious errors are cheap. Plausible ones cost you the full price of reading closely, on every line, because you cannot know in advance which lines are the ones.

Reviewing code you did not write, all day, is a different job. As a slice of the week, review is fine. As the main activity it uses a different kind of attention and depletes faster — which is why an AI-heavy day can leave you feeling both unproductive and wrung out.

Trust becomes something you manage. You build a private map of where the tool is reliable and where it is not: this framework yes, our auth layer absolutely not. Skilled use of these tools is mostly the accuracy of that map.

You lose contact with the code. Delegate a module entirely and you do not know it the way you know code you wrote. Six weeks later, when it breaks at 2am, that is not academic.

The tools, by category

Naming products dates a post like this within weeks. The categories are stabler than the names, so here they are, roughly in order of how much rope they hand you:

Two structural points matter more than any product comparison.

The centre of gravity moved from completion to delegation. In 2023 the question was "what will it suggest on this line?" In 2026 it is "can I hand it this ticket and review a pull request?" Agents now routinely run for long stretches, touch dozens of files and execute commands to check their own work. That shift is what changed the experience from assistance to supervision.

The model matters more than the wrapper, and context matters more than either. Most tools in a category reach for the same handful of frontier models, so the differences that survive real work are about context: what the tool can see, what it may run, and what you have written down. Convention files (AGENTS.md, CLAUDE.md and friends), tool access through protocols like MCP, and a test suite that tells the agent when it is wrong all do more for output quality than switching vendors.

What the evidence says — and how it has changed

This part is usually missing from both the enthusiastic and the dismissive account, and it is uncomfortable for both.

The most-cited sceptical result is real, and its own authors have retired it. In July 2025 METR ran a randomised controlled trial: 16 experienced open-source developers, 246 tasks in repositories they knew well. Allowing AI made them 19% slower. They had forecast a 24% speedup and believed afterwards they had been 20% faster. Measured and perceived reality pointed in opposite directions — which should give every confident claim in this space, optimistic ones included, a moment of pause.

That study travelled a long way as proof that AI coding does not work. METR has since labelled the result historical and is redesigning the experiment: their follow-up data leans towards a speedup, with wide confidence intervals, and they are candid that selection effects wrecked the measurement — developers began refusing to participate rather than work without AI, and 30–50% of them avoided submitting the tasks they expected AI to be fast at. If you are still quoting 19% as the current state of things, the authors disagree with you.

The industry-scale picture reversed too, then got more interesting. Google's DORA research in 2024 associated AI adoption with reduced throughput and stability. In the 2025 edition that flipped: AI is now associated with improved throughput, alongside roughly 90% adoption among technology professionals — but also with increased delivery instability. More change, moving faster, breaking more often. DORA's own framing is the most useful sentence published on the subject: AI does not fix a team, it amplifies what the team already is. Strong testing, tight version control and fast feedback turn extra volume into delivery; their absence turns extra volume into incidents.

Code-level signals point fairly consistently one way. GitClear's analysis of hundreds of millions of lines of change reports a sharp rise in duplicated code blocks through the adoption period — eightfold in a single year — and duplication has a long-established link to defect rates. Veracode's testing across more than a hundred models found security flaws in roughly 45% of the code produced. And an academic study of 576,000 generated samples across 16 models found close to 20% of recommended packages did not exist, with hallucinated names recurring predictably enough that attackers can register them and wait — the attack now called slopsquatting.

The honest summary is narrower than either camp would like:

• Speed of production is up, and barely disputed any more.
• Speed of confidence is not up, and may be down.
• Perceived gains reliably exceed measured gains, including among experts.
• The variance between teams exceeds the average effect. Your practices decide which side of it you land on.

Where it genuinely helps

Roughly in order of how uncontroversial the benefit is:

• Throwaway tooling. Scripts, one-off migrations, log parsers, test data generators. Short-lived, easy to verify, nobody maintains it — almost pure upside, and the one case where not reading the code is defensible.
• Prototypes that end an argument. A working thing beats a document. Two competing ideas, both clickable by the afternoon — provided everyone agrees it gets deleted afterwards.
• Unfamiliar territory. A new language, someone else's SDK. The tools flatten the cost of not having done this before, which is a genuine reduction in project risk.
• Mechanical work at scale. Rename this across 300 files, port these tests to the new runner. Tedious, well-specified, cheap to verify by running the suite.
• Reading code, not just writing it. "Explain this module", "what breaks if I change this". On a large legacy codebase this is often worth more than the generation, and it is where onboarding time really does collapse.
• Tests for the boring parts — with one caveat: a model asked to make tests pass will sometimes write tests that assert the current behaviour, bug included.
• The floor came up. People who could not previously build software can now build something that works. That is a real change in who gets to make things.

Where it genuinely hurts

• Confident wrongness. No uncertainty signal: a hallucinated method and a correct one arrive in the same tone, formatted identically.
• Volume. These tools produce more code than the problem requires, and code is a liability you service forever. Three hundred lines where forty would do is not a win, it is a mortgage.
• The review bottleneck. Generation became nearly free; reading did not. Going fast on generation without expanding review capacity just relocates the queue, and a large unread pull request is worse than no pull request.
• Convergence on the average. Models are drawn to the most common pattern in their training data, which is often the pattern from three versions ago. The result is conventional, occasionally outdated, and rarely tuned to your constraints.
• Security and supply chain. The failure modes are ordinary — a missing authorisation check, unvalidated input, a secret in the wrong place, a package that should not exist — which is exactly why they slip past when nobody is reading closely.
• Nobody decided anything. Generated code carries no design rationale. Six months later "why is it like this?" has no answer, because there was never a reason, only a probability distribution.
• The skills question is open. The tasks juniors traditionally learned on are precisely the tasks agents now do, and plenty of senior engineers report atrophy in themselves. Whether that matters, or is simply what happened when we stopped writing assembly, is not yet known — and anyone certain it is fine, or certain it is catastrophic, is ahead of the evidence.

Deliverability, part one: does the code survive production?

Shipping a demo and shipping something you will still be running in three years are different problems, and AI helps far more with the first. What survives production is not a function of which tool you used.

Verification is the actual constraint. The most useful heuristic anyone has produced for this technology: use AI in proportion to how cheaply you can check the answer. Typed code with good coverage, pure functions, mechanical transformations, anything with a fast red-green signal — lean in hard. Concurrency, money, authentication and authorisation, schema migrations, cryptography — anywhere being subtly wrong is expensive and invisible — slow down and read every line as if it were a stranger's pull request, because it is.

The gates do not change. Code review, CI, tests, static analysis, dependency and secret scanning, staged rollout. All of them were designed assuming humans make mistakes at human volume; they now have to hold at machine volume, which usually means faster and more automated, not more lenient. DORA's instability finding is largely a story about teams whose gates did not keep up with their throughput.

Whoever merges it, owns it. "The AI wrote it" is not a defence in an incident review and should not be an acceptable answer in a review comment either. If you cannot explain it, you cannot merge it.

Shape the work to be reviewable. An agent will happily hand you a 2,000-line diff. Nobody reviews a 2,000-line diff; they skim it and approve it, which is not the same activity. Small, single-purpose changes matter more now than when the constraint was typing speed.

Expect to need more observability, not less. More code, written faster, understood less deeply, raises the value of knowing what your system is actually doing in production.

AI-written code does survive production — a great deal of what is running right now was written this way. It survives when it passes through the discipline you would apply to a competent contractor's work, and it fails in the predictable ways above when it does not.

Deliverability, part two: does it move your dates?

This is where expectations and reality diverge most sharply, especially between the people buying software and the people building it.

Coding was rarely the bottleneck. On most real projects, writing code is a quarter to a third of elapsed time. The rest is working out what is wanted, waiting for decisions, integrating with systems whose owners are busy, testing, security review, data migration, change approval and deployment windows. Halving the coding portion moves the total by much less than people expect — and that arithmetic is precisely why a team can feel twice as fast and still deliver on roughly the old schedule.

What genuinely compresses: discovery and spikes, prototypes, boilerplate-heavy early phases, and the risk premium you used to carry for unfamiliar technology. If your estimate held a large buffer because nobody had used the framework before, that buffer can legitimately shrink.

What does not compress: stakeholder decisions, regulatory and compliance work, integration with third parties, data correctness, user acceptance, security sign-off, and the coordination cost of more than a couple of teams. These are the parts that make enterprise delivery slow, and they are indifferent to how quickly code appears.

Estimation gets harder, not easier. The mean may improve; the variance widens. The same task can take a fifth of the time or three times as long depending on how well the model happens to know the territory, and you usually cannot tell which in advance. So: keep estimates honest rather than discounting them because "AI will handle it", treat review and verification as real line items rather than rounding them to zero, and be wary of fixed-price commitments justified by expected AI speedups.

Scope inflation is the quiet effect. When building is cheaper, people ask for more. Teams frequently report the same delivery pressure at a larger scope — arguably a win in value delivered, but not the win anyone was promised, and it does not feel like one.

Measure delivery, not activity. Lines of code, suggestion acceptance rates and tokens consumed will all rise whether or not anything improves. The questions worth tracking are the ones DORA has asked for a decade: how long from commit to production, how often changes fail, how fast you recover, how much rework you are doing three months later. If those are not moving, the productivity gain is happening somewhere other than your delivery.

Plan for a differently shaped team: more review capacity, more investment in test infrastructure and environments, and more senior judgement per unit of code — because judgement is the part that did not get automated.

Both camps are right about something

The enthusiasts are right that the floor has risen permanently, that drafts and prototypes are nearly free, that the cost of working in unfamiliar technology has genuinely dropped, that ~90% adoption is not a fad, and that "it produces bad code" has aged badly as an argument — the output in 2026 is not the output of 2023.

The sceptics are right that correctness did not get cheaper, that review is now the real constraint, that perceived speedups measurably exceed real ones even among experts, that volume and duplication carry a maintenance bill somebody pays later, and that understanding your own system is not optional and does not come bundled.

Mostly they disagree about which half of the work they were measuring.

The synthesis, as far as the evidence supports one: these tools multiply your existing engineering discipline, in both directions. Good tests, small changes, real review and clear ownership, plus AI, is a fast team. No tests, no review and a culture of merging what looks plausible, plus AI, is the same team as before generating technical debt at a substantially higher rate. That is not a compromise position adopted for the sake of neutrality — it is the most consistent finding in the data.

If you want to find out for yourself

• Pick one task type, not everything. Start where verification is cheap: internal tooling, a well-covered module, a mechanical refactor.
• Write your conventions down. A repository file describing your stack, patterns and constraints improves output more than most tool choices — agents cannot infer house style.
• Keep every gate, and tighten them if anything. Faster generation with unchanged review capacity is exactly how the instability finding happens to you.
• Cap the diff, at a size a human will actually read.
• Measure the delivery outcome: lead time, change failure rate, escaped defects, rework. Give it a quarter before concluding anything.
• Re-test your beliefs on a schedule. Whatever you concluded in 2024 is out of date, in whichever direction you concluded it.

So what does it feel like? Mostly it feels like the job moved one level up — from producing code to specifying, supervising and verifying it — and the interesting difficulty moved with it. Faster to a first draft than anyone expected, no faster to certainty, and considerably less forgiving of teams that were already skipping the unglamorous parts.

If you are working out what this means for a specific system, team or delivery date, that conversation tends to be more useful than the general one — we are happy to have it.