Code Is No Longer Precious

Vibecoding practices for AI-assisted development

The shift

Once AI regenerates code faster than you can debug it, the spec — not the code — is what you protect.

For decades code was a precious artifact and humans were its mechanics, maintaining it by hand. The vibecoding bundle's philosophy.md states it plainly: “Code is no longer precious.”

If that's true, it has to be more than a slogan — so what did someone actually build?

Proof

This isn't a manifesto — it's a shipped Amplifier bundle.

vibecoding is a real bundle at version 0.2.0 (ramparte/vibecoding), built on Microsoft's amplifier-foundation. Its practices arrive as runnable YAML, not prose.

Concrete artifacts — but where did the practices themselves come from?

0.2.0

bundle version

6

reusable behaviors

6

runnable recipes

1,415

lines of recipe YAML

The evidence base

The practices were mined from the field, not invented.

A chat-analyst agent parsed practitioner conversations into an ideas registry: 31 distinct ideas across 10 categories, extracted from 2,200 messages by 60 participants (2025-03-19 to 2026-01-16).

With the evidence base in place, look at the habit that breaks under the new economics.

31

distinct ideas

10

If code is disposable, editing it is wasted effort.

The old reflex — careful surgery on existing code — assumes the code is worth keeping. When AI can regenerate it faster than you can debug it, hand-patching output you're about to throw away just fights the model.

So if you don't edit the code, what do you do instead?

The move

Rewrite over edit: v1 becomes the spec for v2.

Instead of patching output, you regenerate from intent. philosophy.md describes the pattern as iterative regeneration — v1 through v4 — where each version is a fresh generation from a sharpened spec, not a hand-edit of the last.

One question remains: why is regenerating a module safe?

1Write the spec — the WHAT and WHY you actually want.
2Generate v1 from the spec, then read it as feedback.
3Sharpen the spec; regenerate rather than surgically edit.

Why it's safe

The spec is a stable contract — bricks and studs.

amplifier-foundation's modular design philosophy keeps external contracts — “the equivalent of brick studs and sockets where pieces connect” — unchanged, so any single module can be regenerated independently without breaking the whole.

That's what makes the durable object durable — now watch it become executable.

Contracts stay fixed — the studs and sockets where pieces connect don't move.
Modules regenerate — any one can be rebuilt from its spec independently.
The whole holds — regeneration never breaks the surrounding system.

The payoff

The inversion is packaged, not preached.

The discipline ships as recipes you run. wiggum-loop (v1.1.0) supports two modes: full multi-agent attempts with AI validation via session.spawn, or a simple bash-only fallback that works in restricted contexts.

Regenerate-from-spec stops being a philosophy and becomes a workflow — so what do you take away?

# wiggum-loop.yaml (v1.1.0)
mode: full
  # multi-agent attempts +
  # AI validation (session.spawn)

mode: simple
  # bash-only validation,
  # works in restricted contexts

What to keep

Stop being a code mechanic.

Protect the spec, rewrite over edit, and compose behaviors that work with the model. Honest caveat: all 31 ideas are logged as observed patterns with no implementation promoted yet — this is a discipline still evolving.

The code was never the durable object. The spec is.

Protect the spec — treat WHAT + WHY as the durable object.
Rewrite over edit — regenerate from intent, don't patch output.
Compose with the model — fresh-eyes, clear-early, plan-persistence, subagents.

Sources

Research Methodology

Data as of: 2026-07-21 — every material claim independently re-derived from command output.

Primary source: ramparte/vibecoding (local checkout ~/dev/ANext/vibecoding), single commit b586837 by Sam Schillace, Fri Jan 16 11:10:21 2026 — built on git+https://github.com/microsoft/amplifier-foundation@main.

Feature status: Bundle v0.2.0 shipped; all 31 ideas logged as status: observed, none yet implemented.

Commands run:

cat ~/dev/ANext/vibecoding/bundle.md — version 0.2.0 & amplifier-foundation include
git remote -v & git log --format='%H%n%an%n%ae%n%ad%n%s' — remote, sole author, single commit
git ls-files | wc -l — 32 tracked files across behaviors/recipes/context/agents/tools/state/docs
wc -l recipes/*.yaml — 6 recipes, 1,415 total lines; ls behaviors/ — 6 behaviors
grep -c '^ - id:' state/ideas.yaml & grep 'category:' state/ideas.yaml | sort | uniq -c — 31 ideas, 10 categories
cat state/ideas.yaml; cat state/last-processed.yaml — 2,200 messages, 60 participants, 2025-03-19 to 2026-01-16
head -45 recipes/wiggum-loop.yaml — v1.1.0 full/simple modes
grep -i 'brick|stud' amplifier-foundation/context/MODULAR_DESIGN_PHILOSOPHY.md — bricks-and-studs quote

Gaps: The 2,200-message / 60-participant counts are self-reported in yaml metadata; the underlying WhatsApp _chat.txt export is not committed (exports/ has only .gitkeep), so they can't be recomputed from the repo. The initial-analysis report says “32 distinct ideas” while ideas.yaml currently holds 31 — 31 is used as the verifiable count. The v1–v4 iteration pattern is a described community observation, not a measured metric.

Primary contributor: Sam Schillace — sole git author (100% of the single commit). Ideas sourced from an anonymized practitioner community.