Pieter Levels described the experience directly: “Every time I do a Gauntlet Loop I end up with a total mess and chaos of unperformant code and too many things happening and nothing works properly. And I burn $500. I have to clean everything up manually and get back to what I had.” This is not a complaint about the tools. It is a description of what happens when speed of generation outpaces architectural discipline. The tools produced what was asked of them. The architecture of what was being asked was not sound.
The karpathy framing — vibe coding raised the floor, agentic engineering raises the ceiling — is accurate in both directions. More people can ship more software than at any point in the history of the industry. Larger and more complex systems are achievable by smaller teams than ever before. Both of those statements are true and neither of them reduces the importance of the architectural decisions that determine whether what gets built is sound.
flowchart TD A[Team adopts agentic coding tools] --> U1[Ship fast without architecture review] U1 --> U2[Structural decisions compound across agents] U2 --> U3[Retrofit costs exceed initial savings] A --> I1[Set architecture boundaries first] I1 --> I2[Agents operate within defined constraints] I2 --> I3[Speed with structural integrity] class U3 bad class I3 good classDef good fill:#163a26,stroke:#44cc77,color:#d7ffe6; classDef bad fill:#3a1620,stroke:#ff5555,color:#ffd9d9; classDef warn fill:#3a2e16,stroke:#ffaa33,color:#ffe9c7; classDef accent fill:#15233b,stroke:#4488ff,color:#dce9ff;
What the Floor Actually Looks Like
The floor that vibe coding raised is real. A non-engineer or a junior developer who could not have built a functional application three years ago can now ship a working product. The entry barrier to software creation is lower than it has ever been. This is useful and meaningful.
But “working” and “sound” are not the same thing. A vibe-coded application that handles a hundred users may handle ten thousand users poorly, or not at all. The decisions that determine whether it scales — about database structure, caching strategy, asynchronous processing, API design — are not decisions that the AI agent makes by default in favor of scalability. The agent makes decisions that work for the immediate prompt. Architectural soundness at scale requires someone who has seen what happens when those decisions compound under load.
The floor going up means more software gets built. It does not mean better software gets built. Those are different claims.
What the Ceiling Requires
Agentic engineering — multi-agent systems that can plan, write, test, and deploy code across a multi-step task with minimal human intervention — has moved the ceiling substantially. Small engineering teams can now build systems that would have required significantly larger teams five years ago. That is a real capability expansion.
The capability expansion comes with an architectural surface area expansion. An agent that writes code across multiple files, modifies data models, creates API endpoints, and generates tests is making architectural decisions at each step. If those decisions are not constrained by an architectural frame — approved patterns, defined boundaries, established conventions — they will be made in whatever direction satisfies the immediate prompt. Individually, each decision may look reasonable. Cumulatively, without a consistent frame, they produce the kind of structural chaos that becomes expensive to unwind.
The ceiling going up increases what is achievable. It does not automatically improve the quality of what gets built toward that ceiling.
The Judgment in the Middle
The most expensive decision I encountered in five-plus years at LERETA — the second-largest property-tax payment processor in the U.S. — was not a technology choice in the conventional sense. It was a question of whether to retrofit an acquired codebase or start fresh.
LERETA had acquired a company from Texas offering similar technology and attempted to retrofit it into a flagship product rebuild in progress. The data structures were different in ways that seemed minor initially. The processing logic was fundamentally different in ways that only became clear once the teams were deep in the work. The differences caused rework, delay, and eventually required teams to stop and restart from a different baseline. In retrospect, building from scratch with a full requirements process would have been faster and less expensive. The decision to retrofit rather than rebuild cost the organization time and money that was only visible in hindsight.
That judgment — retrofit or rebuild — is exactly the kind of decision that agentic coding tools make tempting to skip. An agent can generate something that functions quickly. The question of whether that something is the right foundation for the next two years of work is a different question, and it requires someone who has been at the point where the wrong choice became expensive to change.
What Managing the Gap Requires
The gap between the floor and the ceiling is not a technology problem. The tools are capable. The problem is architectural governance — ensuring that what the tools build is sound, that the decisions accumulating across hundreds of agentic outputs are coherent, and that the team can rebuild rather than retrofit when the foundation is wrong.
For teams actively using agentic coding tools, the fractional CTO’s primary contribution is defining the constraints the agents operate within before the architectural pattern is already set: which patterns are standard, which dependencies are approved, what the production review gate looks like, and when the cost of starting over is lower than the cost of continuing. Those are not code-review decisions. They are architectural decisions, and they require someone who has made them before under conditions where the stakes were real.
The floor and the ceiling both moved. The architecture decisions in the middle did not go away — they became more consequential.
