Vibe Coding Crashes and Burns After Seven Months: 234 Commits Archived, Rewriting Everything from Scratch

A developer named Swinburne Portel recently published an article that resonated widely across the tech community — "I'm going back to writing code by hand." He spent seven months Vibe Coding with AI, accumulating 234 commits across roughly 30 weekends and 1,690 lines of core code, only to archive the entire project and rewrite it from scratch.

Vibe Coding is a concept coined by AI luminary Andrej Karpathy in early 2025. It refers to a development approach where the programmer describes requirements entirely in natural language, lets AI generate all the code, and only verifies whether the results "look right." This paradigm gained rapid popularity as tools like Claude, GPT-4, and Cursor matured, dramatically lowering the barriers and speed bottlenecks of programming — but it also sparked widespread debate about code quality, maintainability, and developer skill atrophy.

Portel's conclusion is unequivocal: AI builds features, not architecture. The longer you let AI drive unconstrained, the uglier the wreckage.

A Magical Start: A K9S Clone in 3 Weekends

Portel kicked off a project called K10S in late September 2025, aiming to build a GPU-aware Kubernetes dashboard — like K9S, but designed specifically for people managing NVIDIA GPU clusters.

K9S is a widely popular open-source terminal UI tool for managing and observing Kubernetes clusters, known for its Vim-style keyboard navigation that lets operators browse Pods, Services, Deployments, and other resources without leaving the terminal. Kubernetes itself is Google's open-source container orchestration system and has become the de facto standard for cloud-native infrastructure. With the explosion of AI/ML workloads, more teams need to manage GPU resources on Kubernetes, but neither the native tools nor K9S offer native support for GPU topology, VRAM allocation, or DCGM metrics — exactly the gap K10S aimed to fill.

The initial experience felt like magic. "Add a Pods view with live updates" — 3 seconds later, the code was running. Resource lists, namespace filtering, log streaming, Describe panels, keyboard navigation, Vim-style keybindings… a complete K9S clone built in about 3 weekends, entirely through natural language prompts.

Portel estimates his development speed at the time was 10x his normal hand-coding pace. After each prompt, he'd glance at the terminal, confirm it compiled and the happy path worked, then move on to the next feature. In seven months, he never once sat down to read through the AI-generated code in full.

This workflow seemed perfectly fine early on — features were growing, the project was advancing, and everything appeared to be under control.

The Breaking Point: Cascading Failures After the GPU Fleet View

The turning point came after the GPU fleet view went live. This was K10S's core selling point — a dedicated interface showing each node's GPU allocation, DCGM utilization, temperature, and power draw, with color-coded status indicators. DCGM (Data Center GPU Manager) is NVIDIA's suite of GPU management and monitoring tools, widely used in data center environments to collect GPU utilization, memory usage, temperature, power consumption, ECC errors, and other critical metrics, exposing data through monitoring systems like Prometheus. In large-scale AI training scenarios, a cluster might contain hundreds or even thousands of GPUs, and operators need real-time visibility into each GPU's health and load distribution — exactly what K10S's fleet view was designed for.

The AI generated the FleetView Struct, label filtering, custom rendering, and allocation progress bars in one shot. It looked perfect.

Then Portel hit the shortcut to switch back to the Pod view — nothing rendered. The table was empty, live updates had stopped. Switching to the Notice view showed stale cached data from the fleet view. Switching back to the fleet view, the label filtering was broken.

For the first time, he sat down and actually read model.go — 1,690 lines of code, with a single Struct called Model handling everything: UI state, K8S client, state for every view, navigation history, caching, mouse handling, cancel functions, raw object lists — all crammed into one struct.

This is one of the most notorious anti-patterns in object-oriented programming — the God Object. It refers to a class or struct that takes on far more responsibility than it should, directly violating the Single Responsibility Principle (SRP) from SOLID. The danger of a God Object is that any modification can produce unexpected cascading effects, unit tests become nearly impossible to write, and merge conflicts become frequent in team settings. In Portel's case, the AI kept stacking functionality onto the same Model struct because in each prompt's context, the struct already existed and "worked" — the AI naturally took the path of least resistance: adding code to it rather than refactoring into new modules.

Even more terrifying was the Update() method: 500 lines of code, 110 switch case branches dispatching messages to various view logic. Each new feature was shoved directly into this "God Object" by the AI, because its context window only contained "make this feature work right now," with zero awareness of how the other 49 features shared state.

Five Hard-Won Lessons: Where Are the Boundaries of AI-Assisted Programming?

Portel distilled several profound lessons from this failure, each one worth careful reflection for any developer currently using AI to write code.

Lesson 1: AI Builds Features, Not Architecture

Every prompt yields a perfectly working feature, but each feature is implemented in the context of "make this work right now," with zero awareness of shared state. When 50 features share the same mutable state, the system inevitably collapses.

This is the most fundamental limitation of AI programming. While current LLM context windows have expanded from the initial 4K tokens to 128K or longer, they're still woefully insufficient for a real software project. A medium-sized project might contain hundreds of thousands of lines of code, hundreds of files, complex dependency graphs, and implicit architectural conventions. Even if the model can "see" all the code, it lacks deep understanding of the project's evolutionary history, design decision context, and team conventions. This is why AI excels in a project's early stages (small codebase, simple structure) but its output quality degrades sharply as the project grows — it's fundamentally making locally optimal decisions, not globally optimal ones. AI won't proactively tell you "you should abstract an interface here" or "this state should be managed with an event bus."

Lesson 2: Speed Is an Illusion, Until It Isn't

The dopamine hit of Vibe Coding comes from instant delivery, but this gratification masks exponentially accumulating technical debt. When the codebase is small, AI can handle the big picture; once the project outgrows its context window, AI starts reinventing wheels and patching over existing features.

Technical Debt is a metaphor coined by Ward Cunningham in 1992, comparing code shortcuts to financial debt — they accelerate delivery in the short term but require "interest" payments (maintenance costs) long-term. In traditional development, technical debt usually accumulates linearly because human developers instinctively sense when code "smells" bad and proactively refactor. But in Vibe Coding mode, this natural feedback loop is severed: the developer doesn't read the code, the AI doesn't proactively refactor, and each new feature stacks new debt on top of existing debt. This causes debt to grow exponentially rather than linearly, until a tipping point — just as Portel experienced — where the system suddenly becomes unmaintainable.

10x development speed may come at the cost of 10x technical debt.

Lesson 3: Shallow Review Isn't Enough — You Must Read the Code

Portel admitted that for seven months he only performed the bare minimum review of "compiles + happy path tests." If he had sat down and read model.go at the 100th commit, he might have caught the problem at 500 lines rather than 1,690.

This reveals a counterintuitive truth: The more AI makes you feel like you don't need to read code, the more you need to read code. Traditional code review is effective not just for finding bugs, but more importantly for helping developers maintain a mental model of the codebase. When you write code by hand, this mental model forms naturally; but when AI does the writing, you must deliberately read and review to compensate for this gap — otherwise your understanding of your own project grows increasingly fuzzy as the codebase expands.

Lesson 4: Prompt Engineering Cannot Replace Software Design

When things broke, Portel's first instinct was to keep prompting AI to fix it. But the God Object problem can't be solved through incremental prompts, because it requires top-down architectural refactoring — not yet another switch case branch.

This is a common affliction among Vibe Coders — encountering problems and adding more prompts instead of stepping back to think about design. No matter how sophisticated your prompt engineering, it can't compensate for architectural deficiencies. The essence of software architecture is making decisions about "how to decompose complexity": which modules should be independent, how state flows, how interfaces are defined, how change is isolated. These decisions require deep understanding of the business domain, anticipation of future requirements, and experience weighing tradeoffs between various design patterns — precisely the areas where current AI is weakest.

Lesson 5: AI Is an Accelerator, Not a Driver

Portel ultimately chose to archive the entire codebase and rewrite by hand — not because AI can't write code, but because he realized: without human architectural constraints, AI will continuously stack features along the path of least resistance until the system collapses under its own weight.

This aligns closely with the concept of "entropy" in software engineering — any software system, without deliberate refactoring and governance, will naturally trend toward chaos. Human developers combat this entropy through experience and intuition, while AI at its current stage lacks this capability. It's an extremely efficient code generation engine, but not an architect that understands the evolutionary direction of a system.

The Right Human-AI Collaboration Model: Humans Own Architecture, AI Fills in Details

Portel's experience exposes a core issue: Vibe Coding lets you build products without understanding the code. This might hold true during prototyping, but when a project enters production and requires long-term maintenance and team collaboration, not understanding the code means you can't assess debt, predict failures, or fix root causes.

That said, his reflection isn't a wholesale rejection of AI programming. He explicitly stated that the rewritten K10S will still incorporate AI assistance, but with a completely different collaboration model:

• Humans design the architecture, define module boundaries, and specify state flows
• Then let AI fill in implementation details within those constraints

This model has deep theoretical foundations in software engineering. It essentially separates "architectural decisions" from "implementation details" — the former requires global vision, domain knowledge, and long-term thinking, while the latter is relatively mechanical coding work. This aligns perfectly with the classic principle of Separation of Concerns. In practice, this means developers first complete system design the human way — defining modules, interfaces, data flows, and state management strategies — then within each clearly bounded module, let AI accelerate the concrete coding implementation.

This is likely the correct approach to AI-assisted programming — not handing the steering wheel to AI, but drawing the roadmap first and then letting AI step on the gas. Architectural decisions, state management, and module boundaries — work requiring global vision — remain irreplaceable core competencies of human developers.

234 commits and 7 months of time cost made this an expensive lesson, but for the broader developer community, it's an invaluable field report. As AI programming tools grow ever more powerful, understanding the boundaries between humans and AI matters far more than learning to write better prompts.