Skip to content

CONCEPT Cited by 2 sources

Vibe coding

Definition

Vibe coding is the LLM-driven interactive code-generation workflow where a developer (or another agent) converses with the LLM to produce code, the LLM emits code in bursts, the code runs against an execution environment, errors and outputs feed back, and the loop iterates until the intent is met. The resulting session produces source — often a whole new app — through conversational iteration rather than through the developer personally writing each line.

Canonical wiki statement

Fly.io, 2025-04-08:

Today's robots are different. No longer masses of wire, plates, and transistors, modern robots are comprised of thousands of stacked matrices knit together with some simple equations. All these robots want are vectors. Vectors, and a place to burp out more vectors. When those vectors can be interpreted as source code, we call this process "vibe coding".

(Source: sources/2025-04-08-flyio-our-best-customers-are-now-robots)

Fly disclaims the coinage ("We didn't make up this term. Don't blame us.") — Karpathy is the popular attribution.

Workload shape

Fly.io's own framing is the clearest characterisation on the wiki:

A vibe coding session generates code conversationally, which is to say that the robots stir up frenzy of activity for a minute or so, but then chill out for minutes, hours, or days.

(Source: sources/2025-04-08-flyio-our-best-customers-are-now-robots)

The shape is neither transaction nor batch:

  • Not transaction-shape: not a per-request fan-out where each vibe-coding step finishes in tens of milliseconds. A single step can chew on GPU / tool-calls / filesystem / test execution for seconds to minutes.
  • Not batch-shape: not a long pre-committed run. The session is interactive. The LLM stops. The developer reads the output, replies, restarts. Or goes to lunch.

Fly's compute-primitive answer is start/stop on Fly Machines: the burst runs on a started Machine, the idle window the Machine sits stopped, the next burst starts it back up.

Storage implication

Vibe-coding sessions build up the target Machine incrementally — install this package, patch that file, add a systemd unit — contrary to the immutable-OCI-container default. Canonical wiki phrasing:

A typical vibe coding session boots up a Fly Machine out of some minimal base image, and then, once running, adds packages, edits source code, and adds systemd units. This is antithetical to normal container workflows, where all this kind of stuff is baked into an immutable static OCI container. But that's not how LLMs work: the whole process of building with an LLM is stateful trial-and-error iteration.

(Source: sources/2025-04-08-flyio-our-best-customers-are-now-robots)

This shape is on the wiki as concepts/stateful-incremental-vm-build.

Relationship to the agentic development loop

Vibe coding and the agentic development loop are close relatives but not the same thing:

  • Agentic loop emphasises the closed-loop feedback between LLM and execution environment as an anti-hallucination mechanism (the LLM's generated code is ground-truthed by running it).
  • Vibe coding emphasises the conversational, stateful iteration shape — the LLM and the developer (or another agent) go back and forth; the target Machine accumulates state across turns.

Most real vibe-coding sessions are also agentic loops. Agentic loops don't have to be vibe-coding sessions — a batch-mode "fix all these tests" run is agentic but not conversational.

What makes vibe coding an RX concern

Fly.io's 2025-04-08 post identifies vibe-coding workloads as the reason RX (Robot Experience) is now a first-order design axis for a cloud platform:

Each of these is a wiki data point on how vibe-coding workloads are shaped differently from traditional DX workloads.

What's not yet known

  • No metrics for vibe-coding workload shape at scale — Fly's post is qualitative ("frenzy for a minute, idle for hours"); no distributions, no ratios.
  • No observed failure modes — the post is bullish on vibe coding. No runaway-loop cost stories, no context-window-blow- up incidents, no crashes from LLM-emitted systemd units in production.
  • No pricing signal — Fly's start/stop model turns out to fit vibe coding's bursty-then-idle shape, but the post doesn't share the per-session $ or Machine-hour numbers that would let another platform calibrate.

Seen in

  • sources/2025-04-08-flyio-our-best-customers-are-now-robots — Fly.io's 2025-04-08 post; canonical wiki phrasing of vibe coding as bursty-then-idle conversational code generation.
  • sources/2025-06-20-flyio-phoenixnew-remote-ai-runtime-for-phoenix — LiveView-complexity vibe-coding instance. Phoenix.new is framed as a productised vibe-coding target where the generated code is not single-file toy apps but full-stack Phoenix apps with Channels, Presence, Ecto schemas, LiveView templates, and real databases. The Fly.io post offers the ElixirConfEU Tetris demo ("nailed it, first try, first prompt") as an existence proof that frontier-model world knowledge + the right substrate can cover surface-pattern gaps — "it's not like there's gobs of Phoenix LiveView Tetris examples floating around the Internet! But lots of people have published Tetris code, and lots of people have written LiveView stuff, and 2025 LLMs can connect those dots."
Last updated · 200 distilled / 1,178 read