Vibe coding had its moment. Now it’s time to talk about what comes next.

The term “vibe coding”—coined by Andrej Karpathy in February 2025—captured something real: a new way of building software where you describe what you want and let AI figure out the implementation. No code review, no deep understanding of what’s actually happening under the hood. Just vibes.

It was fun. It was fast. And for toy projects, it worked.

But here’s the uncomfortable truth: 72% of professional developers say vibe coding isn’t part of their workflow. That’s not resistance to AI. That’s professionals recognising something the hype cycle missed.

Generating code is easy.

Generating correct, maintainable, production-ready systems is hard.

The Vocabulary Gap

Simon Willison, one of the sharpest voices in the AI development space, proposed a new term in October 2025: “vibe engineering.”

His reasoning was pointed:

“Vibe coding is pretty well established now as covering the fast, loose and irresponsible way of building software with AI—entirely prompt-driven, and with no attention paid to how the code actually works. This leaves us with a terminology gap: what should we call the other end of the spectrum, where seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce?”

The distinction matters. Vibe coding makes ideation faster. Vibe engineering makes entire organisations more capable.

Vibe coding is about generating snippets. Vibe engineering is about shipping systems.

Why the Shift Is Happening Now

Two things changed in 2025 that make vibe engineering possible where it wasn’t before:

1. Context windows exploded.

A year ago, context windows maxed out around 128,000 tokens—roughly a 250-page book. Today, Claude Sonnet 4 offers 1 million tokens. Gemini 2.5 Pro matches it. Llama 4 Scout pushes to 10 million. Some experimental models claim 100 million.

This matters because you can now feed an entire codebase into a model. Not snippets. Not summaries. The whole thing—dependency graphs, architectural patterns, variable states, the works.

2. The limitations became visible.

As Chroma’s research on “context rot” demonstrated, simply having a massive context window doesn’t guarantee reliable performance. Models excel at retrieving information from the beginning and end of the window, but struggle with content buried in the middle. Performance degrades as input length grows.

Raw context isn’t enough. You need structured orchestration of that context—systems that know what to surface, when, and how to chain decisions across the full lifecycle.

What Vibe Engineering Actually Requires

The shift from vibe coding to vibe engineering isn’t about better prompts. It’s about building systems that handle what prompts can’t.

Discovery and requirements, not just code.

Production software doesn’t start with code. It starts with understanding what needs to be built and why. Vibe engineering means AI that asks clarifying questions, surfaces edge cases, and generates specs before generating implementations.

Architecture that survives contact with reality.

Anyone can prompt an LLM to scaffold an app. The question is whether that architecture will hold when requirements change, when you need to scale, when you’re debugging at 2am. Vibe engineering requires AI that understands architectural trade-offs—not just what works, but what’s maintainable.

Testing as a first-class concern.

Vibe-coded projects notoriously skip tests. Vibe engineering means AI that generates test cases alongside implementations, validates edge cases, and catches regressions before they ship.

Deployment, monitoring, and self-healing.

Getting code to run locally is step one. Getting it to production—with observability, logging, alerting, and recovery mechanisms—is what separates prototypes from products.

Context that spans the full lifecycle.

The gap between vibe coding and vibe engineering is the gap between “this function works” and “this system is ready for users.” That gap is filled by context—requirements context, architectural context, testing context, operational context—managed across the entire SDLC.

The Context Problem Nobody’s Solving

Here’s the trap most AI coding tools fall into: they optimise for the coding phase and ignore everything else.

You get brilliant code completion. Maybe automated test generation. Perhaps deployment scripts. But each tool operates in isolation. The AI that wrote your authentication service has no idea what your deployment requirements are. The tool generating your tests doesn’t know about your monitoring stack.

As Factory.ai’s analysis of the context window problem puts it:

“A typical enterprise monorepo can span thousands of files and several million tokens. There are also millions of tokens worth of information relevant to an engineering organisation that lives outside of the codebase—Datadog, Slack, Notion. This massive gap between the context that models can hold and the context required to work with real systems is a major bottleneck.”

The solution isn’t bigger context windows. It’s structured context management—systems that know which context matters for which decisions, and can orchestrate that context across the full development lifecycle.

The Platform Shift

This is why 2026 will see a shift from AI tools to AI platforms.

Tools solve point problems: code completion, test generation, PR review. Platforms solve system problems: how do you go from initial prompt to deployed, observable, self-healing production software?

The winners won’t be the tools with the best autocomplete. They’ll be the platforms that can:

• Start from intent, asking discovery questions that surface what actually needs to be built

• Generate architecture that accounts for scale, maintenance, and operational requirements

• Produce code with the full context of what's already been decided

• Create tests that validate not just functionality but production readiness

• Handle deployment with infrastructure as code, monitoring, and alerting baked in

• Enable iteration without losing context between cycles

This is the full agentic SDLC—not AI that helps you code, but AI that helps you ship.

The Question That Matters

The question isn’t whether AI can write code. That’s settled. The question is whether AI can ship real software—from first prompt to production, with everything in between handled.

That’s vibe engineering. That’s where the value is. And that’s the problem we’re solving.

Ready to move beyond code generation to full-lifecycle software delivery?

Sign up to see how Ardor handles the complete journey from prompt to production.