Vibecoding for the garden: when an LLM writes your app

Stepping away from your computer for five minutes after launching a lengthy prompt and returning to find a working app in the preview window—that's exactly what a Verge editor describes in their piece published on June 13. The reason was straightforward: their backyard garden was dying and they wanted a tool to track plants, watering schedules, and pending tasks. Instead of searching for an app in the store, they decided to build one with Gemini.

The result arrived quickly. It also arrived with an error: `~ Channel is unrecoverably broken and will be disposed!`. It sounded serious. But just below appeared a button to fix it automatically. Strange, yes. Functional, also.

What is vibecoding and why this case matters

The term "vibecoding" has been used for months to describe the practice of building software by describing what you want in natural language, without manually writing code. It's not new as a concept, but it is new in its real accessibility: anyone with a browser can now try to generate a functional app from a prompt.

What makes the Verge experiment interesting isn't the garden itself, but the author's profile: they're not a developer. They're someone who needed to solve a concrete problem and evaluated whether current LLMs can serve as a personal software workshop for non-technical users. The answer that emerges from the article is nuanced: yes, with friction.

What works and what still needs smoothing

The initial generation workflow is surprisingly smooth. A detailed prompt produces a navigable interface in minutes. Current LLMs have improved significantly at inferring reasonable data structures from prose descriptions: what fields a plant record needs, how to organize tasks by frequency, where to place reminders.

Problems emerge during iteration. When the author wants to modify something specific—change a button's behavior, adjust notification logic—the model sometimes rewrites parts that were already working. The broken channel error mentioned at the beginning is representative: the experience swings between "this is magic" and "I have no idea why this broke."

The auto-correction button is a revealing detail. It normalizes the presence of errors as part of the workflow, not as an exception. For someone without technical training, that can be liberating or unsettling depending on the day.

Who this approach makes sense for today

Vibecoding works well for a quite specific profile: someone who needs a limited-scope personal tool, with no demanding scalability or security requirements, and who can tolerate some opacity in how the generated code works internally.

For that profile, building a garden app, habit tracker, or personalized list manager makes real sense. The cost of entry is nearly zero. The time to having something usable is minutes, not weeks.

Where the model still falls short is in maintainability. If the app grows, if something breaks in a non-obvious way, or if the user wants to integrate with external services, the lack of understanding of the underlying code becomes a concrete ceiling. It's not a hypothetical future problem: it's the ceiling that any non-technical vibecoder will hit sooner or later.

Context in the broader tool ecosystem

These types of experiments are redefining what "building an app" means. Tools like Claude Code with subagents and plugins, Gemini environments with live previews, and similar platforms are converging toward workflows where the prompt-preview-correction cycle becomes the primary development paradigm for non-specialized users.

It's not that professional developers will disappear. It's that the threshold to having something functional has dropped so much that people who never tried before now generate tools that cover their real needs. That has value, regardless of whether the resulting code is elegant.

---

Editor's note: the garden experiment is a good indicator of vibecoding's actual state: useful for contained cases, still rough whenever complexity appears. It's worth closely following how automatic correction mechanisms evolve; that's where much of the difference lies between a curiosity and a tool for sustained use.