27  “Vibe Coding”

Vibe coding is often used to describe building software by telling an LLM what you want and refining the result through conversation. The term was coined by Andrej Karpathy in a post on February 2, 2025; see also this Ars Technica overview. There is an important distinction, though: Karpathy’s original description involved accepting generated changes without reading the code closely, particularly for throwaway projects. In this workshop, we’re using the term more broadly for iterative, conversational development, while still reading, testing, and taking responsibility for the code. That is more precisely described as AI-assisted development.

27.1 From an Idea to a Working Draft

Rather than prompting for one-off answers, this workflow is iterative, conversational, and adaptive. The goal isn’t simply to have the AI generate a complete script for you, but to engage in a process of co-development—exploring options, refining syntax, and solving problems together. For R users, this means moving beyond “write me an app” to something more like “help me build a Shiny app that allows users to visualize item difficulty by grade level.”

In this framework, the AI functions as a thought partner and code generator, helping translate your intent (“vibe”) into a draft of R code that you can test. You might start with a broad goal (“I want users to upload a CSV and filter items by domain”) and then ask the model to scaffold the basic UI layout. As you test and refine, you can return to the model for troubleshooting (“I’m getting a reactive context error—how do I fix it?”) or optimization (“How can I make this app load faster?”). The iterative nature of vibe coding encourages exploration and experimentation—key skills for both creative developers and educational measurement professionals who often need to prototype analytic tools quickly.

AI-assisted development can also help lower the barrier to entry for frameworks like Shiny. Because reactivity and UI design can feel conceptually distant from typical R scripting, working with an AI assistant can make the process more approachable. You can ask the model to explain why certain elements belong in the server versus ui sections, or how to use reactive() and observeEvent(), then check those explanations against the Shiny references. Over time, you can develop a sense of how Shiny feels—its rhythms, its syntax, its underlying logic—by co-creating with an AI partner that provides just-in-time feedback and examples.

No specific AI model is required for vibe coding. Choose an approved chatbot or coding assistant that fits your R workflow; the AI Coding Assistants chapter discusses tool choices and review practices. The key is to maintain the vibe—a rhythm of asking, testing, refining, and learning. This approach can accelerate development and deepen understanding, but the learning comes from examining and testing the result, not simply accepting it.

27.2 Give the Model Something You Can Check

A useful prompt describes the intended behavior, the data, the boundaries of the task, and what would count as success. For example:

Help me build a small R Shiny app for exploring item difficulty by grade. Use a synthetic table with one row per item and grade, with columns item_id, grade, n_correct, and n_tested. Define difficulty here as the proportion correct (n_correct / n_tested), not an IRT difficulty parameter. Add a grade selector and a table showing the selected items and their proportions. Use only shiny and base R, with no uploads, external services, or LLM calls. Include one item with 8 correct responses out of 10 and one with zero tested students. Display the latter proportion as missing. Explain the UI and server code, and provide checks I can run locally.

Before adding another feature, check that selecting a grade changes the displayed rows, that 8 out of 10 produces 0.8, and that zero tested students produces a missing value rather than an infinite or misleading result. A working interface is not evidence that the calculation is correct. If something fails, describe the action you took, what you expected, and what actually happened; include the relevant error message without sensitive data.

Using AI to write an app does not mean the finished app needs to call an LLM. This small example needs no API connection at runtime. We’ll combine app development with LLM calls in Activity: Making a Shiny App.

27.3 Helpful Vibe Coding Resources

27.3.1 Google AI Studio

Google AI Studio’s Build mode lets you describe an app and refine it through conversation. For web apps, its documented environment uses a web frontend (React by default) and a Node.js server runtime. It can be useful for exploring app ideas, but that environment is not an R Shiny runtime. For this workshop’s Shiny examples, ask explicitly for R code and run it in your R environment.¹

27.3.2 Add Chat to an App With shinychat

Unsurprisingly (again), Posit has created an interface to help you add an AI chatbot to a Shiny app. That package is called shinychat. It provides chat UI components; its R documentation pairs it with ellmer for model responses. This is a tool for adding chat to the finished app, not a coding assistant that builds the app for you. The Conversations via API chapter already uses it through ellmer’s browser interface; the package documentation shows how to incorporate chat into your own app. I haven’t extensively worked with this, but wanted to suggest it for those ambitious workshop participants who might want to integrate an AI chatbot in their Shiny app.

---

1. The term’s origin, Google AI Studio’s web-app runtime, and the role of shinychat were checked against the linked original post and official product documentation on September 20, 2026.