From Vibe Coding to Engineering

aisoftware-engineeringbuilding-in-public

I’ve been watching the agent logs fly by on a Google Antigravity session and a realization popped into my head.

In March, we were using Copilot for code completions. A typing accelerator, useful but limited. By September, we were vibe coding entire applications, pointing an AI agent at a blank project and getting working software. Now, in December, we’re using an agentic IDE built on Google’s Gemini model, and the agents can hold context across files, reason about architecture, and produce code that’s genuinely close to what I’d write myself.

The trajectory is clear. AI-assisted development isn’t a fad. It’s the future of how software gets built. The capability curve is steep and accelerating.

But here’s what I keep coming back to: vibe coding isn’t software engineering.

What vibe coding gets you

Working software. Fast. Describe what you want, watch the agent build it, iterate on the result. For Tuido, a terminal todo app, this was great. Functional program, two days, daily driver.

But look at the things we’ve built this year that actually matter to our business: Flux with its content-addressable blob store and namespace confusion protection. Codex with its RBAC hierarchy and push policy system. Sirius2 with its semantic token architecture.

None of these could have been vibe-coded. Not because the code is too complex. The agents can write complex code. But because the decisions that make these systems work aren’t code decisions. They’re architecture decisions, design decisions, business decisions. Where to put the abstraction boundary. Which trade-offs to accept. What to build and what to deliberately not build.

What’s missing

Architecture. An agent can write a blob store. It can’t decide whether you need one. The four-layer storage model in Flux, BlobStore → Blob → Asset → ArtifactAsset, came from understanding the Docker content-addressing model and reasoning about how it would compose with RubyGems’ path-based storage. That’s a design conversation, not a code generation task.

Taste. What should the UI feel like? How much information density is right? When should a modal be a slideover instead? The Sirius2 design philosophy, monochromatic base, color as signal, depth for interactivity, is a set of aesthetic and functional judgments. Agents don’t have taste. They have training data.

Context that survives. This is the practical problem. Agent sessions end. Context windows fill up. The design decisions you explained in session one are gone by session three. The agent doesn’t remember why you chose YAML-driven RBAC over a database-backed policy engine. It doesn’t remember the Nexus failures that motivated Flux’s storage design. It starts fresh every time, and you spend the first twenty minutes of every session re-establishing context.

Todo lists that survive. Related but distinct. What’s been done, what’s left, what’s blocked. This information lives in the human’s head and dies when the session ends. The agent can’t pick up where it left off because it doesn’t know where it left off.

Where this is going

I’ve been thinking about this a lot. The answer isn’t “AI can’t do engineering.” The answer is “AI doesn’t have the scaffolding yet.” The architecture reasoning, the taste, the persistent context, the surviving todo list. These are solvable problems. It’s really not about making the model smarter. But telling it exactly what you want. The problem is if you write the spec down to that level of detail, you may as well just write the code yourself. We are missing an entire meta-layer of tools and processes around software engineering with AI.

What if there was a system that:

Not vibe coding. Not manual coding. Something in between. Engineering with AI as a genuine collaborator. Human sets the direction, makes the design calls, defines quality. AI handles implementation within those boundaries. Both working from the same persistent context.