6 Practice by Artifact Type

Even though it’s all called “made with AI,” the actual work differs entirely depending on what is being made. Each type has what works well, what doesn’t, where humans need to intervene, and how to check quality. This chapter compares these differences by type. This book itself is the case study in the final section.

6.1 Writing: Reports, Papers, Documents

Writing Status

Pre-draft. Check TOPICS.md at the repository root for owner and status.

Brief. Code can be verified by running it, but writing cannot. This asymmetry makes writing the most difficult artifact in the vibe coding discussion. This section covers how far AI use actually extends in writing reports, papers, and documents; where the line falls between tool and ghostwriter; and the problem of academic writing norms versus AI-specific style (including the cliches and inflated rhetoric this repository guards against). As the first section of Chapter 6 (artifact-by-artifact practice), it connects directly to the verification asymmetry discussion in §8.3.

Seed Questions

Unlike code, writing has no equivalent procedure to “run it to check.” What do practitioners use to fill that gap?
How far do journal and conference AI-use disclosure policies allow, and where do they draw the line at prohibition? What are the differences across fields?
How are the features identified as “AI style” (cliched expressions, inflated rhetoric, specific vocabulary patterns) being detected?
Is there any discussion that proposes criteria for distinguishing AI use as a tool from AI use as a ghostwriter?
Record your own experience of writing this book or other text with AI as a case study. How much did AI write, and where did you revise it yourself?

Research Pointers

Original text of major journal and conference AI-use policies (each journal’s homepage)
Discussions related to AI style (analysis pieces from linguistics and journalism)
Record the writing process of this book itself, especially the style discipline this stub follows (see the top of the brief), as a case study

6.2 Data Analysis and Visualization

Writing Status

Pre-draft. Check ownership and status in TOPICS.md at the repository root.

Brief. Data analysis is an area where vibe coding has taken hold particularly quickly. In the exploratory analysis phase, handing code over to AI produces graphs and statistical tables in an instant. The problem is that a result looking plausible and actually being correct can be two different things. This section covers, with real cases, how much exploratory data analysis has accelerated, and the trap where plausible-looking graphs lead to conclusions without verification. It connects with §4.4 (Researchers’ Vibe Coding), but this section covers business analysis as well as research.

Seed Questions

What are actual error cases found in AI-generated visualization or statistical analysis code (axis distortion, statistical misuse, data leakage, etc.)?
As the speed of exploratory data analysis has increased, how has the analyst’s role changed? Has the center of gravity shifted from writing code to interpreting and verifying results?
What concrete verification procedures do practitioners use to filter out plausible-looking graphs?
How is the landscape of data analysis tools (notebook-based agents, code-interpreter type tools) divided?
Record as a case your own experience of extracting data analysis results with AI and then verifying them yourself. What did you verify, and what turned out to be wrong?

Research Pointers

Collections of statistical and data visualization error cases (academic and journalism critiques of graph distortion)
Official documentation for code interpreters and notebook-based AI analysis tools
Document a verification procedure using students’ own data analysis assignments as a case study

6.3 Web Applications: From Frontend to Deployment

Drafting Status

Not yet drafted. Check the repository root’s TOPICS.md for owner and status.

Brief. Web applications are the most representative stage for vibe coding. Building a single frontend screen is a very different level of difficulty from connecting a backend and database and actually finishing deployment. This section follows the full path from idea to deployment, distinguishing where things go smoothly and where they get stuck, and whether that bottleneck comes from the limits of the tools or a lack of human understanding. Where §6.1 and §6.2 dealt with artifacts that are hard to verify, this section shows why an artifact that is comparatively easy to verify (you can see it by running it) is nonetheless hard to see through to completion.

Seed Questions

How common are actual cases of completing a full-stack web application from planning to deployment using vibe coding alone? How does this compare to cases of giving up midway?
Among frontend, backend, database, and deployment pipeline, which stage does vibe coding work best for, and which is it most vulnerable at?
In areas where mistakes are costly, such as authentication, payments, and permission management, how is the reliability of AI-generated code assessed?
Among web apps built with vibe coding, what is the difference between cases that acquired and retained real users and cases that remained mere demos?
Record your own experience attempting a web application from planning to deployment as a case study. At which stage were you stuck the longest?

Research Pointers

Full-stack vibe coding build logs (blogs, YouTube, X threads)
AI integration features and official case studies from web deployment platforms (Vercel, Railway, etc.)
Compile students’ own web app project progress logs as case studies

6.4 Automation Scripts and Personal Tools

Writing Status

Pre-draft. Check ownership and status in TOPICS.md at the repository root.

Brief. Short scripts that take over repetitive tasks, glue code that stitches together multiple tools, and CLI tools that automate personal workflows are considered the category where vibe coding succeeds most reliably. This section covers why this category is said to have a particularly high success rate, what structural reasons make the risk of failure low, and why this success does not generalize to other categories (web apps, writing). It is also the most concrete realization of §4.2 (software for one).

Seed Questions

What is the basis for the claim that automation scripts and glue code have a high success rate in vibe coding? Is there quantitative research, or is it just anecdotal impression?
Why is verification easy in this category? (Easy to undo, execution results are immediately visible, low cost of failure, etc.)
In what form are actual cases of personal workflow automation tools (CLI, cron jobs, notification pipelines, etc.) reported?
Under what conditions does failure occur in this category? (External API changes, permission issues, etc.)
Record an automation script or personal tool you made yourself as a case study. What did it automate, and how long did you actually keep using it?

Research Pointers

Collect cases from personal automation tool sharing communities (Hacker News Show HN, Reddit, etc.)
Empirical research on vibe coding success rates (check primary sources if available)
Accumulate a list of automation scripts made by each student as case data

6.5 Slides and Typesetting: A Case Study of This Book

Writing Status

Pre-draft. Check ownership and status in TOPICS.md at the repository root.

Brief. Presentation materials and typeset works like books pose a unique verification problem in that they require both visual polish and structural accuracy at the same time. This section covers how AI coding tools are actually used in producing slides and typeset works, taking this book’s own build pipeline as the primary case study. This repository manages the manuscript with Quarto, typesets the PDF with Typst, and uses a pipeline that translates the Korean original into English with AI. The person responsible should directly document how this pipeline is actually structured and where humans intervene.

Seed Questions

What stages does this repository’s (vibecoding) build pipeline (tools/build, tools/translate, Quarto, Typst) actually consist of, and what does the AI do versus what does the human do at each stage? Read and run the repository’s CLAUDE.md and tools/ scripts directly and document them.
How good is the quality of the AI translation (files in en/ marked MACHINE-TRANSLATED) actually? What error patterns appear when compared against the original text?
How does the way AI is used differ between slide-making tools (code-based slide generators) and GUI tools like Word or PowerPoint?
What counts as “it works” verification for typeset works? (successful rendering, no broken layout, compliance with print specifications, etc.)
If you have experience working with AI on slide or document typesetting tasks outside of this book, record it as a case study.

Research Pointers

Read and run this repository’s tools/build, tools/translate, _quarto.yml, and CLAUDE.md directly to document the pipeline
Check the official Quarto and Typst documentation for descriptions related to automation or script integration
Compare cases of other code-based slide and typesetting tools (markdown-based presentation generators, etc.)