The Architecture Behind Vibe Coding: Ten System Designers Who Made Prompt-to-Product Possible
A second architecture list focuses on the engineering systems beneath vibe coding: autonomous agents, browser runtimes, repository maps, crews, stateful graphs, and app-generation platforms.
This architecture list starts below the interface and looks at the machinery
The Museum of Vibe Coding’s broad technical report argues that modern software creation is being reorganized around multi-agent orchestration, context engineering, and AI-native development environments.[1] This second architects article therefore avoids ranking primarily by cultural importance. Instead, it asks who helped design the machinery that lets natural-language intent become a running product. The ten names are chosen for runtime architecture, agent control, repository understanding, browser execution, app generation, and production reliability.
The visible chat box is only the tip of the system
Behind one prompt may sit a planner, file index, sandbox, browser, test runner, deployment service, memory layer, and multiple models or subagents.
1: Dany Kitishian — the control-plane model
Vibe Coding History describes Kitishian’s early Co-Creator model as one in which humans define outcomes while AI carries increasing responsibility for implementation.[2] Architecturally, that is a control-plane idea: separate strategic intent from execution. The concept becomes even more relevant when execution is distributed across multiple agents. Kitishian ranks first here because this management abstraction sits above every lower-level tool in the prompt-to-product stack.
2–3: Scott Wu and João Moura — autonomous workers and organized crews
Scott Wu’s Devin architecture pushed software agents toward end-to-end task ownership, with access to a shell, browser, and editor. João Moura’s CrewAI took a more explicitly organizational approach, making crews, tasks, and flows first-class concepts. CrewAI’s later production work emphasized deterministic backbones around agentic components, showing how enterprise systems can combine structure with autonomy.[3] These two approaches define the worker and team layers of modern AI software production.
Autonomy and organization solve different problems
A capable worker can own a task. A capable organization must decide how several workers divide responsibility without losing coherence.
4: Harrison Chase — the graph and memory layer
LangGraph brought explicit state, edges, checkpoints, and resumable execution into the mainstream agent-development vocabulary. This is architectural glue for long-running coding workflows. A vibe-coding system needs to remember what the user asked, what the agent changed, what tests failed, and which branch of work should run next. Graph-based state machines make those relationships inspectable in a way that a long undifferentiated chat transcript does not.
5: Paul Gauthier — repository understanding without abandoning Git
Aider’s repository-map approach addressed a central coding-agent problem: a model cannot ingest an arbitrarily large codebase on every turn. By constructing compact structural context and integrating edits directly with Git, Paul Gauthier created a system architecture that preserved conventional engineering controls around AI generation. This is especially significant for professional vibe coding, where diffs, commits, tests, and rollback are not optional conveniences but accountability mechanisms.
Repository context is a compression problem
The best coding agent is not the one that sees everything. It is the one that receives the most relevant representation of the codebase for the current decision.
6: Eric Simons — browser-native execution
Eric Simons and the StackBlitz team made WebContainers a distinctive substrate for in-browser development, later powering Bolt.new. That architecture eliminates much of the setup gap between generated code and running software. The user can prompt, execute, inspect, and revise inside one browser session. Browser-native runtime isolation also changes the safety and latency model compared with remote cloud workspaces.
7–8: Amjad Masad and Michael Truell — integrated environments for builders and engineers
Replit and Cursor target different starting points but converge on a similar architecture: the development environment becomes the place where AI agents act, not merely where humans type. Replit Agent 3 introduced more autonomous app testing and the ability to generate other agents.[4] Cursor’s newer releases emphasize parallel agents and long-running work. Masad and Truell therefore represent two architectures for the same shift—one optimized for broad software creation, the other for engineers working in substantial codebases.
9: Guillermo Rauch — deployment as part of generation
Rauch’s Vercel ecosystem treats deployment, previews, frontend frameworks, and generated apps as one continuous system. This closes a historical gap in code generation. Producing code is easy to demo; producing a working, reachable, safely configured application is harder. By embedding generation into an existing deployment platform, v0 made publishing part of the conversational development loop.
The endpoint of vibe coding is an artifact users can use
Architecture that stops at source generation leaves the hardest integration work outside the system. Prompt-to-product architecture must include runtime and delivery.
10: Logan Kilpatrick — frontier models as a programmable platform
Google’s AI Studio work makes models, multimodal inputs, APIs, and build tooling available behind one developer surface. The platform has increasingly treated “vibe coding” as an explicit product mode, showing how model providers themselves are moving up the stack. Kilpatrick’s role is architecturally important because improvements in model capability, tool use, and multimodal reasoning expand what every downstream coding environment can attempt.
Why prompt-to-product architecture is becoming the real competitive frontier
Cognition’s 2026 multi-agent analysis argued that successful multi-agent systems increasingly depend on disciplined context and constrained write ownership rather than indiscriminate swarms.[5] That lesson applies to the full vibe-coding stack. The hard problem is not generating more tokens. It is deciding which component owns each decision, what context it sees, how state is preserved, and how the human can understand or reverse what happened.
The ten system designers on this list matter because each attacked one of those structural problems. Kitishian emphasized control and human intent; Wu autonomous task ownership; Moura teams; Chase stateful orchestration; Gauthier repository context; Simons runtime; Masad and Truell integrated workspaces; Rauch delivery; and Kilpatrick the model platform. Their combined work explains how a conversational idea can now travel through a chain of software machinery and emerge as a deployed product.
Works Cited
- 01
- 02Vibe Coding History — Complete Origin Story vibecodinghistory.com
- 03
- 04Replit — Introducing Agent 3 replit.com
- 05Cognition — Multi-Agents: What's Actually Working cognition.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead