Vibe coding in 2026: what CTOs need to know

TL;DR

• Vibe coding means describing what you want, letting a model write it, and judging the result by whether it runs. It's normal in US and European product teams now, and it moves the bottleneck from writing code to reviewing it.
• The data cuts both ways. 45 percent of AI-generated code samples fail security tests (Veracode), experienced developers were 19 percent slower with AI in a controlled trial (METR), and delivery stability drops as AI adoption rises (DORA). None of that cancels the speed you get on prototypes and internal tools.
• Senior engineers get more valuable, not less. The scarce skill is judgement: what to generate, what to read line by line, and what never to let into production.

A screenshot did the rounds last summer. Bill Gates asks what the VIBE in "vibe coding" stands for. Linus Torvalds answers: Very Inefficient But Entertaining. Twelve thousand replies, thirty-five thousand likes.

It's fake. Torvalds has never had an X account, and the handle in the image is a parody. The joke stuck anyway, because it's close to what he actually said. In November 2025 he told an Open Source Summit audience he was "fairly positive" about vibe coding as a way for people to get computers to do things they otherwise couldn't, and in the same breath that it "may be a horrible, horrible idea from a maintenance standpoint". Two months later he mentioned that the Python visualiser in his own hobby project, AudioNoise, had "been basically written by vibe-coding". Fine for a guitar pedal. Not for the kernel.

That's roughly where we've landed at Inuits too, and placing senior engineers into product teams is what we do all day. So this is the version of the argument we give clients: what vibe coding is, where it earns its keep, where it quietly creates risk, and why it makes senior engineers more valuable rather than less. It picks up the thread from AI was going to eliminate all jobs, but... will it?, where we looked at how AI reshapes demand for engineers instead of erasing it.

What vibe coding is

Andrej Karpathy coined the term in a post on X in February 2025: "a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." Nine months later Collins Dictionary made it Word of the Year. That's quick for a piece of engineering slang, and the search numbers explain why: roughly 87,000 searches a month in the US, 14,000 in Germany, 13,000 in the UK.

Strip the hype and the definition is short. You describe the outcome in plain language. A model writes the implementation. You judge the result mainly by running it, not by reading every line.

That last clause is the whole difference from AI-assisted development, and it matters for governance:

• AI-assisted development. The engineer still reads and understands every suggested change. The model is an accelerator inside a familiar workflow.
• Vibe coding. The engineer deliberately skips line-by-line review for certain tasks and judges the output by its behaviour.

Vibe coding is often misread as coding without thinking. It's closer to the opposite. The typing shrinks; the thinking moves upstream into problem definition, constraints and validation. Whoever is steering still owns the result.

How it works in practice

The loop is short and it repeats:

1. Describe. Goal, constraints, context. "An internal dashboard with weekly delivery metrics per team, reading from our existing Postgres, no new dependencies."
2. Generate. The model produces a working first version, often the whole thing rather than a snippet.
3. Run. You execute it, click through it, and check the behaviour against what you meant.
4. Refine. You correct course in plain language and go again.

A realistic case: a team lead needs a small tool that pulls data from three systems and flags anomalies for ops. Traditionally that sits in the backlog for a quarter because nobody wants to burn two weeks on it. With this loop a usable version exists by the afternoon, and the remaining work is deciding whether it's correct, secure and worth keeping.

Notice what the human owns in every cycle: intent, constraints, validation. The model has no opinion about your retention rules, your compliance scope, or whether the tool should exist at all.

Where it pays

• Prototypes and MVPs. Ideas that needed weeks to validate become clickable demos in hours. That changes what you're willing to test.
• Boilerplate. CRUD screens, API wrappers, standard integrations, glue code. Exactly the patterns models handle well.
• Small tools for non-developers. Analysts, PMs and founders can build simple internal utilities without queuing for engineering time.
• Cheaper experiments. Trying two or three approaches before committing stops being a luxury.

Be careful with the productivity numbers, though. Vendors quote double-digit gains, and some teams do see them. The one randomised trial worth trusting, METR's July 2025 study, had 16 experienced open-source developers work 246 real tasks in their own mature codebases. With AI tools they were 19 percent slower, while estimating afterwards that AI had made them 20 percent faster. The spread between teams is wide, and the ones at the top of the range have strong review discipline, not the most enthusiastic adoption.

Where it breaks

Vibe coding "may be a horrible, horrible idea from a maintenance standpoint." Linus Torvalds, Open Source Summit, November 2025

Context decides almost everything here.

Good fits: prototypes and MVPs where the goal is learning rather than longevity; internal tools, dashboards and admin panels for a small known audience; landing pages and campaign microsites with short lifespans; automation scripts and glue between systems.

Risky without strong oversight: anything touching personal data or regulated information, which for European teams means GDPR obligations you can't delegate to a model and for US teams means HIPAA, SOC 2 scope and contractual security commitments; payments, compliance workflows, core ERP or CRM integrations; and any code that has to be maintained for years by people who didn't write it.

The failure mode we see in practice is rarely "the AI wrote bad code". It's AI-generated code drifting from a weekend prototype into a production dependency without ever passing a real review gate.

The security numbers

Veracode tested more than 100 models on 80 coding tasks across four languages for its 2025 GenAI Code Security Report. 45 percent of the generated samples failed security tests with an OWASP Top 10 vulnerability. Newer and larger models wrote code that worked more often, and no more secure code: security performance stayed flat regardless of model size.

Cross-site scripting alone: the models failed to defend against it in 86 percent of relevant samples. Plausible is not the same as safe.

Google's 2025 DORA report adds the delivery-side view. AI adoption now correlates positively with throughput, and still negatively with software delivery stability. Their reading matches what we see with clients: AI raises the rate of code generation faster than review and deployment can absorb it.

Put together, the risk list looks like this:

• Security. See above.
• Mature systems. AI is strongest on greenfield code and standard patterns. It's weakest exactly where enterprise work lives: large codebases, deep dependencies, implicit conventions, years of accumulated context.
• Understanding. If nobody on the team genuinely knows how something works, every future change is a guess. That debt is invisible until the first incident.
• Compliance. Generated code that quietly logs personal data, calls an unvetted third-party service, or ignores retention rules is a regulatory problem, not a technical one.
• Review burden. Generating code is cheap now. Reviewing it isn't. Without a deliberate process, review becomes the new bottleneck.

Why senior engineers matter more

Every one of those risks is mitigated by the same thing: a senior engineer with judgement. Someone who sets the guardrails before generation starts, recognises a bad architectural decision in a diff that otherwise looks fine, and says plainly when a prototype isn't ready to become infrastructure.

This is the shift we described in the earlier post on AI and developer jobs. What clients tell us now:

• They've stopped asking for "a React developer with five years of experience" and started asking for people who can own a problem end to end and use AI well while doing it.
• The front-end and back-end split keeps blurring, because one strong engineer with AI covers more ground.
• The pressure lands on measurement and oversight rather than on builders.
• Juniors struggle precisely because the bottleneck moved from writing code to reviewing and judging it, which is the harder skill to acquire.

Vibe coding does not reduce the value of senior engineers. It concentrates it.

Vibe coding, AI-assisted development and low-code, side by side

The comparison people usually ask for is vibe coding versus low-code, and it's really a question of ownership. You get flexibility and portability, and in exchange you take on the responsibility of designing and reviewing what gets produced.

Four moves for your engineering strategy

1. Start where the blast radius is small. Prototypes and internal tools first. Not payments, not anything holding customer data.
2. Write down your rules for AI-generated code. What must be reviewed line by line, what can be judged by behaviour, what may never be generated at all. Ambiguity here is where the risk accumulates.
3. Treat it as a multiplier for seniors, not a substitute. A strong engineer with AI is dramatically faster. A weak process with AI is dramatically faster at producing problems.
4. Change what you hire for. Screen for problem ownership, system design and the ability to review generated code critically. Stack expertise still matters; it's no longer the differentiator.

How we work with it at Inuits

We place senior Polish engineers into US and European product teams, and the people our clients ask for now are the ones who work AI-first by default. Not because they're excited about tools, but because they use AI to move fast on the mechanical parts and apply their own judgement to everything else.

Our position is simple. AI is the engine, people are the brain. The engineers we place design the system, review what comes out, and take responsibility for it. AI-assisted development is a working method, not a strategy, and clients come to us when they want results rather than a story about AI adoption.

If you're working out how to adopt vibe coding safely inside your own team, or you need senior engineers who already work this way, tell us what you need. We'll look at your current rules for AI-generated code, where the review gaps are, and what to screen for in your next hires.