“When not to vibe code” — Justin Gage (Technically)

Why this is in the vault

This is a working operator’s framework for the exact question RDCO is publishing into: when should a non-engineer ship something themselves with a coding agent vs. hand it to engineering? Gage is doing growth at Railway and writes from inside an active vibe-coding practice — not as a thesis-builder. His two-axis framework (consequences + ownership, expressed as “blast radius” and “who gets paged at 2am”) is more concrete than most of what’s in the vault on this question, and it converges with our agent-deployer positioning while implicitly contradicting the lazier “AI lets anyone build anything” framing.

It is also a useful counterweight to the Tossell-style maximalist non-technical-founder posture in 2026-04-04-coding-with-agents-non-technical: same enabling premise, much sharper boundary discipline.

The core argument

Gage’s decision rule for non-engineers shipping code with agents is built on two factors:

1. Consequences (blast radius). Is a bug a nuisance to me and my team, or does it page someone serving real users? A formatting glitch on an internal dashboard is annoying; a 404 on a high-traffic landing page is an incident.
2. Ownership. Whoever gets paged at 2am needs to have all the context to fix the underlying issue. If the marketer who shipped the code can’t fix it, they shouldn’t have shipped it alone.

The mapping that follows from those two factors:

• Ship internal tools yourself. Tools that don’t touch production infrastructure, used weekly by a few people, where breakage costs only your own time. Gage’s examples from Railway: a template-verification app, a sponsorship-attribution dashboard pulling YouTube + npm data, a content-quality checker for the affiliate program. Each took under four hours.
• Ship within existing engineering systems. A new landing page using existing components, design system, form integrations, and CDN/caching is fine for a non-engineer to build. The system handles scale, security, monitoring; the operator just adds copy and structure.
• Hand to engineering when you’d be introducing new systems. New subdomain with new structure, anything touching payments or user data, anything where traffic could spike to 1M/day, anything requiring defensive programming or monitoring. The “underlying engineering system” — load handling, caching, CDN, graceful degradation, security, monitoring — is not what an agent should be asked to invent on the fly.

His punchline framing: the right question is not “can I build this page” but “does the system this page would live on already exist.”

Notable claims

• Coding agents have shifted where the handoff happens between non-engineers and engineering, not whether one happens. This is a more honest framing than most current discourse.
• Defensive thinking is what coding agents currently lack — Gage cites a real bug where a casing change broke hardcoded button paths because the agent had no instinct to ask “what else uses this string.”
• The right test for whether a non-engineer should own production-facing work is not skill but paging surface: who fixes it at 2am.
• He explicitly carves out internal tools as the high-leverage zone — the place where non-engineers get the most compounding value with the least risk. This matches the RDCO internal-tooling pattern almost exactly.

Direct paraphrases above; the one short quote worth keeping: “you build it, you own it” (5 words).

Mapping against Ray Data Co — load-bearing

This article is strong mapping. It converges with our position on three points and contradicts/extends it on one.

Convergence:

1. Two-axis decision rule = our agent-deployer discipline made concrete. 2026-04-14-levie-agent-deployer-role-jd defines the role; Gage gives the operator’s day-one playbook. The blast-radius + ownership pair is exactly the test we should be teaching agent-deployers to apply before they ship anything from a Claude Code session into a live system. Worth pulling into a decide-shipping-surface skill or the build-project SKILL preflight.
2. Internal-tools-first matches our entire RDCO model. Gage’s three Railway tools (template verifier, sponsorship dashboard, content quality checker) are structurally identical to RDCO’s /process-newsletter, /check-board, /morning-prep, etc. — internal, weekly-cadence, blast-radius=self, built by the operator with an agent. This validates the architectural choice we made by accident and dignifies it as a category.
3. “Build within existing systems” maps to our harness thesis. commentary-tan-fat-skills-thin-harness-2026-04-14 argues that operators should add fat skills to a thin harness, not build new harnesses. Gage’s “ship within existing engineering systems vs. add new systems myself” is the same discipline applied to web infrastructure. The pattern is general: operators extend, engineers (or harness authors) own the substrate.

Productive contradiction:

4. Gage stops short of the agent-deployer vision. He frames the role as “non-engineer who can ship growth experiments without paging engineering” — useful but small. The agent-deployer thesis (2026-04-14-levie-agent-deployer-role-jd, 2026-04-15-commoncog-operational-rigour-pursuit-of-knowledge) is bigger: the operator runs autonomous loops against the substrate, instruments them, and tunes inputs over time — not just one-off page builds. Gage’s framework is the gate for what enters that loop; it doesn’t describe the loop itself. Useful complement, not a competing thesis.

Counterweight to vault’s existing scaling-failure literature:

5. The “vibe-coded app goes viral and goes down” pattern from 2026-03-20-every-vibe-coded-app-viral is what Gage’s framework prevents. His “what happens at 1M users” question is the diagnostic that flags the would-be-viral app before it ships into a system without load handling. Use both together when teaching the discipline.

Operational follow-ups worth queuing:

• Consider a Sanity Check issue on “the 2am test” — the single sharpest decision rule for when a non-engineer should ship vs. defer. Gage’s framing earns its own treatment, credited.
• Add the blast-radius/ownership question pair to the build-project skill’s PRD step. It is currently missing.
• Worth pulling Gage’s three internal-tool examples into the agent-deployer pitch deck as concrete proof points from a real growth team at a real company. Railway is a credible logo.

Related

• 2026-04-14-levie-agent-deployer-role-jd — defines the role; Gage operationalizes the gate
• 2026-04-04-coding-with-agents-non-technical — Tossell’s maximalist version; Gage adds discipline
• 2026-04-09-technically-claude-code-meta-ads-autonomous-loop — prior Technically piece on autonomous-loop pattern; this issue is the human-in-the-loop counterpart
• 2026-03-20-every-vibe-coded-app-viral — what Gage’s framework prevents; the failure mode
• commentary-tan-fat-skills-thin-harness-2026-04-14 — same discipline (extend, don’t reinvent) applied at the harness layer
• 2026-04-15-commoncog-operational-rigour-pursuit-of-knowledge — agent-deployer as modern SPC operator; Gage gives the entry-criteria rule
• 2026-04-13-joe-reis-ai-hard-parts — “faster code is not faster production”; Gage’s framework names which faster-code paths reach production safely