The developer behind k10s, a terminal dashboard for monitoring Kubernetes clusters with GPUs, has archived the project's Go implementation and begun rewriting it from scratch after seven months of heavily AI-assisted development. The retrospective argues that code-generation tools delivered individual features quickly but did not create a durable architecture without explicit human direction.
K10s was conceived as a GPU-aware counterpart to k9s, with views for allocation, utilization, temperature, power use and memory across NVIDIA-equipped nodes. The developer says the early project progressed rapidly through sessions with Claude. Resource tables, namespace filters, log streaming, keyboard navigation and a command palette were assembled over several weekends, followed by a dedicated GPU fleet view.
The failure became visible when switching away from that fleet screen. Other resource views rendered empty or stale data, live updates stopped, and filters leaked between screens. Reading the full implementation exposed the deeper issue: a single model structure owned user-interface widgets, the Kubernetes client, navigation, caching, input handling and view-specific state. Its central update method had grown to roughly 500 lines with about 110 branches, while the containing file reached 1,690 lines.
The author attributes that outcome to a sequence of prompts focused on immediate features. Each generated change took the shortest route through existing state, adding special cases to generic resource-loading and key-handling paths. Cleanup depended on manual field resets, making omissions likely as the number of views expanded. Identical keys also acquired different meanings through a flat set of conditions rather than isolated per-view controls.
The post does not conclude that AI coding is useless. The archived repository contains 234 commits produced across roughly 30 weekends, and the author says the experience taught valuable lessons. The revised approach is to define interfaces, message types, ownership rules and view boundaries before asking a model to implement features. Those constraints should then be placed in persistent project guidance so every coding session begins with the same architectural expectations.
Another lesson concerns apparent speed. When early additions were cheap, the project's scope widened. That velocity made it easy to judge changes by whether they compiled and passed a happy-path test rather than by how they altered the whole design. Problems accumulated gradually until multiple features interacted.
This is one developer's postmortem, not a controlled comparison between hand-written and AI-generated software. Its practical contribution is a concrete account of where supervision was missing. The creator's conclusion is that a person still needs to remain responsible for system boundaries, review and long-term coherence, even when a model can implement substantial features in isolation.
