Vibe coding for librarians

Vibe coding is building software by describing what you want in plain language and letting an AI write the underlying code. The person doing the building does no programming. You describe the tool, review what the AI produces, describe what should change, and iterate until the result works. The process is conversational rather than technical.

This is a genuine shift. For most of the history of software development, building a custom tool required either programming knowledge or a budget to hire someone who had it. Academic libraries have faced a specific version of this constraint for decades. Some tool needs are too particular for a vendor product, too small to justify a development contract, and too complex to solve without code. The result has been a steady accumulation of workarounds. Spreadsheets manage workflows that deserve proper tools. Paper processes persist because no one could build the replacement. Staff time goes to tasks that could be automated if automation were accessible.

Vibe coding closes some of that gap. It is worth naming honestly why this capability appeals in a library context, because understanding the motivation is part of using it responsibly. In a May 2026 article in C&RL News (Michalak et al., 2026), Ava Wallace, an LIS student in dialogue with a library director and a senior leader in the profession, discusses AI tools generally. She describes them as measures that address a chronic funding crisis, useful precisely because libraries have been asked to do more with less for so long. They are not, in her account, a substitute for the sustainable investment communities actually need. That framing applies directly to vibe coding. It is a workaround made newly accessible, and naming it as such is more honest than calling it a solution.

None of these require programming knowledge. They require the ability to describe what one wants clearly enough that an AI system can build it.

One constraint is worth naming at the outset: vibe-coded tools are functional, not polished enterprise software. They work. They are reasonable in appearance. For patron-facing tools that must be sustained over multiple years, vibe coding is best understood as rapid prototyping, a way to test whether a tool is worth building properly. For internal staff tools, it frequently produces the final product.

Lovable (lovable.dev) is the most beginner-accessible vibe coding tool currently available. You describe an application in a chat interface, Lovable builds it, and a live preview appears immediately. The tool is designed to produce polished-looking web applications without requiring the builder to make design decisions. It is the recommended starting point for most library vibe coding projects.

Strengths: Strong default design, straightforward iteration, live preview. Well suited to patron-facing tools where visual quality matters. Limitations: Less control over structural decisions; complex logic can be difficult to implement precisely. Pricing: Free tier has limited builds. Paid tier (Pro, from $25/month) is appropriate for active use.

Replit (replit.com) is a development environment with strong AI assistance built in. It is more flexible than Lovable and supports a wider range of project types. The AI within Replit, called Agent, can build more complex tools and allows the builder to see and interact with the code directly if they choose.

Strengths: Very flexible, handles complex requirements, supports more unusual tool configurations. Appropriate for tools that need capabilities Lovable cannot provide. Limitations: Defaults are less visually polished; requires slightly more comfort with iteration. Pricing: Free tier is functional for most library tool builds.

Claude (claude.ai) or ChatGPT directly: You describe a tool in plain language and ask the AI to write the code. You then paste the code into a text file with an .html extension and open it in a browser. This approach works for simple, self-contained tools such as calculators, quizzes, and interactive pages.

Strengths: Free, immediate, works well for simple tools. Reading the code, even briefly, builds some understanding of what the tool is doing. Limitations: Iteration is manual; each revision requires repeating the process. Requires knowing how to open an HTML file in a browser.

For a first project, start with Lovable. For later projects that need more flexibility or complexity, Replit is the natural next step. Direct use of Claude or ChatGPT suits quick, simple tools where a dedicated platform would be more overhead than the job warrants.

The workflow is the same whichever tool you use. The quality of the result depends more on the quality of the description than on any other factor.

Step 1: Write a clear description of what you want. Technical terms are not necessary. Describe the tool as you would explain it to a colleague who could build anything. A useful description covers what the tool does and why, who will use it, what inputs the user provides, what the tool shows or outputs, and roughly how it should look.

An example of an insufficient description: "Make me a library app."

An example of a description that works: "Build a web page with a simple quiz. It asks three multiple choice questions that test whether a student can identify a hallucinated citation. Each question shows a citation and asks: Real or Hallucinated? After all three questions, show the score and a brief explanation of each answer. Use a simple, clean design with a navy blue header."

The difference is specificity. The more precisely you describe the inputs, outputs, and purpose, the closer the first version will be to what you actually need.

Step 2: Let the AI build a first version. In Lovable or Replit, paste the description and let the AI generate. In Claude, ask it to write the HTML and JavaScript, then copy the result into a file with an .html extension.

Step 3: Review and iterate. The first version will not be exactly right. That is expected. The next step is to describe what should change: "The colors are wrong. Use dark green instead of blue." "The explanation after each question is not appearing." "Add a Start Over button at the end." "The text is too small on a phone screen."

Step 4: Test as a user. Move through the tool as a patron or student would. Identify what does not work as intended. Describe each problem to the AI. Repeat.

Step 5: Share or deploy. Lovable and Replit both provide shareable links that work immediately. For HTML files built directly through Claude or ChatGPT, the file can be uploaded to a library website or a simple file hosting service.

The iteration cycle (describe, build, review, revise) is the core skill. It is conversational in nature, and it rewards clarity and specificity at every stage.

The following examples are tools a librarian with no programming background can build in a single afternoon or evening. They illustrate the kind of problem vibe coding addresses well.

Citation Reality Check is an instruction tool that presents students with five citations, some genuine and some hallucinated by an AI, and asks them to identify which is which. It gives immediate feedback after each selection. The tool works in any browser, requires no login, and can be shared as a link before a library instruction session or embedded in a LibGuide.

Approximate build time: 45 minutes including iteration.

Database Matchmaker is a reference tool that asks three questions (subject area, type of information needed, and level of depth) and recommends the library's databases based on the answers. The builder provides the recommendation logic; the AI builds the interface.

Approximate build time: 90 minutes including writing the recommendation logic.

Research Log is an instruction support tool that gives students a structured form to complete as they work. It records their research question, the search terms they tried, the databases they used, the sources they found useful, and the questions that arose. Students can export a summary of their process. The tool helps scaffold research as a skill rather than an outcome.

Approximate build time: 60 minutes.

Subject Glossary is a patron support tool: an interactive glossary for a specific subject area (nursing, legal studies, social work, environmental science) in which patrons can search terms and receive plain-language definitions. The builder provides the term list; the AI builds the searchable interface.

Approximate build time: 30 minutes once the term list is prepared.

These are not complex applications. Before, they would have required a developer or a vendor product that roughly fit the need, or the library would simply have gone without. The point is how much is now achievable in a single afternoon.

Vibe coding is not always the right answer. Before building anything, ask a series of questions that will clarify whether building is the appropriate response.

Does a tool for this already exist? LibCal handles appointment scheduling. LibGuides handles resource organization. Most integrated library systems and discovery layers have features that are underused. Configuring an existing tool often solves a problem faster and more sustainably than building a new one. Before building, investigate what is already available.

Does it need to integrate with another system? If the tool must connect to an ILS, Alma, a database, or another institutional system, vibe coding can produce a starting point but will often hit its limits quickly. Integration typically requires API access and more than vibe coding alone can provide.

Does it need to be maintained over the long term? Vibe-coded tools are easy to build and can be fragile to maintain, particularly when the person who built them is no longer available. For tools that must work reliably for years, a formal development project or a vendor product may be the better answer, even if it is slower.

Is it patron facing and high stakes? A broken patron-facing tool erodes trust. Any tool deployed to patrons should be tested extensively and should have a plan for when something goes wrong, including when the person who built it cannot diagnose the problem.

The most important characteristic of vibe coding is also its most significant liability: the person who builds the tool does not know what the code is doing. This is not a temporary limitation that will be engineered away; it is structural to the approach. Understanding the risks it creates is a professional obligation, not an optional consideration.

The code opacity problem. When a librarian builds a tool through vibe coding, the AI produces code that may run to dozens or hundreds of lines. The builder almost certainly cannot read it. They cannot tell whether it handles edge cases correctly, what happens when a data format changes, or what occurs when a user does something unexpected. The tool works until it does not, and when it fails, the builder may have no way to diagnose why. This is acceptable for low-stakes internal tools. It is not acceptable for any tool that gates access to resources, stores patron data, or makes decisions with meaningful consequences for patrons or the institution.

Security and patron privacy. Patron data carries professional and often legal protection obligations. A vibe-coded tool connected to patron records, authentication systems, or personally identifiable information must be reviewed by someone with security expertise before deployment. There is no exception to this. An acquisitions reporting tool that processes only institutional financial data carries different risk than a tool that handles student research records or reference requests. Make that distinction explicitly before any tool goes live.

Maintenance and institutional memory. A vibe-coded tool was built through a conversation with an AI, and that conversation is gone. The builder may leave the institution, or simply forget what decisions were made during iteration. The tool then becomes effectively unmaintainable by a successor who cannot read the code. Libraries have long struggled with institutional knowledge that lives in individual staff members rather than in documentation. Vibe-coded tools create a particularly fragile version of that problem.

Skills that may not develop. In the same May 2026 C&RL News article (Michalak et al., 2026), Trevor A. Dawes raises a concern about AI generally that applies directly here. When AI can instantly generate plausible-seeming answers, patrons and staff may lose the capacity to evaluate sources, understand what a system is producing, or distinguish synthesis from analysis. The same dynamic operates in vibe coding. A librarian who learns to build tools entirely through AI assistance from the start of their career may never develop the data literacy to understand what a query returns, what a formula calculates, or what an algorithm selects. Any staff development program built around these tools should examine this carefully.

Equity across library staff. Russell Michalak makes a point in the same article that applies directly here: free is not the same as full. The AI tools that make vibe coding effective (Claude Pro, Cursor, GitHub Copilot) are subscription products. The librarians using them now are mostly those who already had the technical curiosity to experiment and the institutional latitude to try new approaches. They also had access to paid tools, through personal subscriptions or existing institutional licenses. If vibe coding becomes a meaningful capability for library services, expecting individual staff to procure the tools on their own creates a two-tier workforce. Equitable access to the tools is a prerequisite for equitable distribution of the capability.

This capability has a consequence directly relevant to academic libraries' relationships with their technology vendors, and it deserves explicit attention.

Frustration with vendor lock-in is a recurring theme in library technology conversations. Platforms do not quite do what a library needs. Feature requests wait years for implementation. Interfaces are designed for an average use case that does not match a specific institution's workflows. For decades, the practical answer to "why can we not simply build what we need ourselves?" was always the same. Building requires developers, developers cost money, and libraries do not have that budget.

Vibe coding changes that calculation, though not entirely. Integrated library systems, discovery layers, and electronic resource management platforms are not going to be replaced by vibe-coded applications. But for the small, workflow-specific tools libraries have always needed and never been able to build, the barrier has dropped. It has gone from "requires a developer" to "requires a clear description and an afternoon."

A librarian who can produce a working prototype of a needed tool in three days is in a different position when discussing feature timelines with a vendor. This does not mean that building a workaround is always the right response to a missing vendor feature. A workaround may not be sustainable, and it may create maintenance burdens that exceed the original problem. It does mean that the question of where to build and where to rely on a vendor is now genuinely worth asking, in a way it may not have been five years ago.

Libraries can and should think strategically about this. For workflow-specific tools that a vendor is unlikely to build, and whose maintenance burden is manageable, building is increasingly a realistic choice. For tools that must integrate with core systems, be sustained over many years, or meet security-level reliability standards, vendor relationships and formal development remain the right answer. Drawing that distinction clearly, instead of defaulting to either "we cannot build anything" or "we can build everything," is part of approaching this capability as a professional.

The most useful framing for approaching vibe coding as a library professional comes from Ava Wallace, in the same May 2026 C&RL News article (Michalak et al., 2026): "Literacy does not only mean how to use something; it also means how to think critically about it, how to assess its accuracy, and how to determine when it is or is not an appropriate tool to turn to." That definition, literacy as judgment rather than mere adoption, is the right frame for building a vibe coding practice in a library.

The goal is not staff members who can build anything using AI tools. The goal is staff members who understand what they are building, know what the tool cannot do, recognize when to stop, and have documented what they have made clearly enough that someone else can use and maintain it. That is a library value applied to a new capability, not a technology value imposed from outside the profession.

To build a sustainable practice, establish the following principles at the outset.

Start with low-stakes internal tools. Data cleaning, reporting, internal routing, and prototype instruction tools are the appropriate initial experiments. Patron-facing systems and anything connected to authentication or core library systems are not appropriate starting points, regardless of how promising the prototype looks.

Find the people who are already doing this. In most libraries, at least one staff member is already building tools this way without calling it vibe coding. Find those people, give them time and access to appropriate tools, and learn from what they have built. That is more productive than creating a formal program from scratch.

Establish documentation habits before they are needed. When a tool is built, the builder should produce at least a single-page summary. It should state what the tool does, what data it touches, what it cannot do, what assumptions were made during the build, and whom to contact when something breaks. This does not fully solve the institutional memory problem, but it reduces the damage when the builder is unavailable.

Treat tool access as an equity question. If vibe coding is to be a meaningful capability for library services, access to the AI tools behind it should not depend on individual staff subscriptions. That would be structurally equivalent to giving some staff access to library databases and not others. The resource must be available equitably, or the capability cannot be deployed equitably.

Engage IT before deploying anything. Security considerations, data handling requirements, and acceptable use policies are far easier to address before a tool is live than after. A disagreement about policy discovered in advance is preferable to one discovered retroactively.

The question for academic libraries is not whether vibe coding belongs in this environment; it is already here. The question is whether libraries will approach it with the professional intentionality they bring to any new capability. That means evaluating it critically, deploying it equitably, and sustaining it with the institutional care that patron trust requires. Those habits already exist in the profession. Applying them to this new capability is the work.