Why this is in the vault
First installment of a new 6-part Technically series ("Software Engineering for Vibe Coders") teaching non-engineers the frontend/backend mental model so they can maintain and debug apps they prompt into existence — useful as a plain-language artifact for explaining harness-adjacent architecture to non-technical stakeholders.
The core argument
Justin Gage frames the frontend/backend split via a restaurant analogy (dining room = frontend, kitchen = backend) walked through a running example app (Vandelay Industries, a supplier-management tool for a potato-chip importer). Frontend is limited to HTML/CSS/JavaScript (plus frameworks like React) and is everything the user directly sees and clicks. Backend is the database, API endpoints, and — increasingly — AI model calls, running server-side in languages Claude Code or similar tools choose more freely (the piece name-checks Rust). APIs exist as a translation layer between frontend and database for three reasons: access control, data formatting, and query-logic reuse, and JSON is the near-universal wire format.
The most useful debugging heuristic offered: when something in a vibe-coded app breaks, first ask "is this a frontend or backend problem?" — e.g., a dead button could be broken backend logic OR a frontend CSS property blocking the click; diagnosing which half is at fault is the single skill that separates a competent vibe coder from one who's just prompting blind. The piece closes by naming where the frontend/backend line is genuinely blurring — Next.js co-locating both in one codebase, and the client-side-vs-server-side-rendering split — rather than pretending the boundary is always clean.
Mapping against Ray Data Co
Directly usable as an explainer artifact: when Ray (or Ben) needs to onboard a non-engineer stakeholder — a client, a family member, a collaborator on a vibe-coded RDCO surface — into why a build broke or what a hosting/database choice actually does, this restaurant analogy and the "frontend or backend?" triage question are a faster teaching tool than writing one from scratch. It's also a soft data point for the harness-engineering thread already in the vault (see 2026-07-21 Technically harness-engineering note): the piece treats "AI models and harnesses" as squarely a backend-engineering discipline now, reinforcing that agent/tool-call plumbing is architecture work, not frontend polish — consistent with how RDCO treats its own agent build stack.
⚠️ Sponsorship
Railway (cloud hosting/deploy platform) sponsors the entire 6-part series, disclosed at the top of the email ("Thanks to our friends at Railway... for sponsoring this series") with an inline CTA link (railway.com/new). Inside the article itself, Railway is also used as the concrete example of where the fictional Art Vandelay hosts his app — "the all-in-one intelligent cloud provider" giving him "one place to run his database, API server, frontend, scheduled jobs." This is a soft in-narrative product placement layered on top of the disclosed sponsor block: the walkthrough example was constructed to make Railway's pitch (one platform for everything) land as the natural conclusion, not just a banner ad. Treat the backend/hosting framing as favorable-to-Railway by construction, not neutral.
Related
- [[2026-07-21-technically-harness-engineering]] — same sender, adjacent thesis on AI/agent backend architecture
- [[2026-08-09-technically-dispatch-kimi-liquid-stacked-prs]] — same sender, most recent prior Technically note
- [[2026-06-18-technically-code-sandboxes]] — same sender, backend infra concept for vibe-coded apps