4 Opportunities and Potential
What vibe coding opens up is not “coding faster” but the range of who can build and what can be built. This chapter examines that opportunity in order: people (who gets access), things (what becomes newly possible), economics (how the cost structure changes), and the research frontier.
4.1 Which Doors Opened for Whom
Not yet drafted. Check TOPICS.md at the repository root for owner and status.
Brief. The first thing vibe coding changed is the boundary of who can make software. This section’s theme is how widely this door has opened for non-programmers, domain experts, solo founders, and researchers respectively, and what new barriers have been hidden behind that threshold. The narrative that “now anyone can build” comes largely from success stories, while failure cases and cases of giving up partway are relatively underdocumented. This section gathers both currents in balance to concretely depict who actually gained access to what. It serves as the introduction to Chapter 4 (Opportunities and Potential), with the following §4.2-4.4 covering the specifics.
Seed Questions
- What cases are there of non-programmers completing software from start to finish with vibe coding, and where did they get stuck?
- What patterns appear in cases where domain experts (medicine, law, education, etc.) directly coded solutions to problems in their own field?
- Did vibe coding actually let solo founders shrink their team size, or did it just shift the problem to other bottlenecks (marketing, operations)?
- What evidence do skeptical rebuttals to the claim that “now anyone can build” cite?
- Record your own experience of building something as a case for this section. What background knowledge were you missing when you first tried vibe coding, and what actually filled that gap, and what did not?
Research Pointers
- Collect build reports from non-developers (blogs, communities, Product Hunt-type sites), covering both successes and failures
- Case interviews from solo founder and indie hacker communities (Indie Hackers, etc.)
- Interview students themselves and their peers about their first building experience and compile them as cases
4.2 Software for One, Disposable Software
Pre-draft. Check the repository root’s TOPICS.md for owner and status.
Brief. When the marginal cost of building software falls, a new category emerges: software built and discarded for just one person, or for a single task. This section addresses whether this kind of personal, disposable tool is actually increasing, and if so, in what form it appears. The existing software industry has been designed around the premise of reuse and economies of scale; when that premise is shaken, the key question is what remains and what newly emerges. This is also an answer to what the people who came in through the door opened by §4.1 are actually building.
Seed questions
- Where can we find the terminology and discussion around personal, disposable software?
- In which domains do actual examples of disposable software (scripts and tools used once and discarded) appear most often?
- When the marginal cost of custom software falls, how do the existing SaaS and general-purpose software markets respond?
- How much maintenance, security, and documentation does disposable software actually need? Is the claim that none is needed at all valid?
- Record a case study of a disposable or personal tool you made yourself. What was it built for, and what happened to it afterward (still in use, discarded, shared with others)?
Research pointers
- Search practitioner blogs and talks using keywords like “software for one,” “disposable software”
- Collect similar cases from communities where people share personal tools (e.g., Hacker News Show HN-type posts)
- Gather and organize personal tools made by students through surveys or interviews
4.3 The Economics of Prototyping
Not yet drafted. Check ownership and status in TOPICS.md at the repository root.
Brief. When the distance between the moment an idea occurs and the moment a working demo can be shown shrinks, the rationale for the various organizational practices that used to fill that gap (planning documents, approval processes, mockup tools) starts to waver. This section addresses what practices the change in prototyping speed has actually altered on the ground in startups and enterprises, and what has remained unchanged. It should also distinguish whether only the speed has increased, or whether the nature of the prototype itself has changed. It extends the discussion of personal software in §4.2 into organizational and startup contexts.
Seed Questions
- How much has the time to build a startup’s MVP (minimum viable product) actually shortened? What is the quantitative evidence?
- Has the internal approval process for prototypes within companies shortened as much as production speed has increased, or has the bottleneck simply moved elsewhere?
- What problems arise as the boundary between a “quick prototype” and a “prototype deployed directly to production” blurs?
- How has the role of the prototype changed in fundraising or internal persuasion processes?
- Actually measure the time it takes you to go from idea to a working demo and record it as a case study. What was the bottleneck (conception, building, or validation)?
Research Pointers
- Collect mentions of MVP build times from public materials by startup accelerators and VCs (verify figures against primary sources).
- News coverage of internal corporate hackathons and innovation lab cases.
- Record students’ own project build times and use them as comparative data.
4.4 Vibe Coding for Researchers
Not yet drafted. Check ownership and status in TOPICS.md at the repository root.
Brief. For researchers, vibe coding operates under somewhat different conditions. Data pipelines, visualizations, and simulation code are mostly not written once and discarded, but must pass peer review and reproducibility checks. This section covers how vibe coding is actually used in research settings, and where the vibe coding practice of “if it works, it’s fine” collides with the research requirement that results “must be reproducible.” Since this book is a product of the Special Topics in Data Science course at Seoul National University, this section also touches on the actual working methods of the author group itself.
Seed Questions
- How are researchers using AI coding tools to write data preprocessing, visualization, and simulation code? Are there differences across fields?
- Do reproducibility requirements (code disclosure, fixed environments, fixed seeds) actually conflict with the fast-iteration practices of vibe coding, or do tools resolve this automatically?
- In statistics and econometrics code, what procedures are needed to verify AI-generated results differently?
- What constraints do journal and conference AI-use disclosure policies place on writing research code?
- Record, as a case study, your own experience of vibe coding one of a data pipeline, visualization, or simulation for your research or coursework. How did you verify the results?
Research Pointers
- Accounts from econometrics and statistics researchers on using AI coding tools (blogs, X threads)
- Academic discussions of reproducibility (literature on the reproducibility crisis and its reexamination in the AI era)
- Compile each student’s own experience building research or assignment pipelines as case studies