Vibe Coding in Production: A Facilities System and an Identity Platform

What if the people who understand a problem on their campus could build the software they have needed for years? Not with an expensive project. Not by waiting in a priority queue. But by building it themselves. In sixty hours.

Almost every institution has a backlog of problems that will never become projects. Perhaps they are too specific for a vendor product, too small to justify a six-figure contract, too complex for a spreadsheet, or too far down the priority list to compete with large projects, such as an ERP upgrade.

Back-office operations tend to suffer the most. Imagine the benefits of being able to access any floor plan and view layers such as department ownership and occupancy. Or imagine a management system for real estate holdings and lease agreements that tracks actions and responsibilities in automated workflows.

The Problems

At Emerson College, as at many institutions, the barrier to that future was the facilities data itself. The data existed. It was sprawled across various spreadsheets, a few legacy systems, and disparate consultant work over the years. All buried in an endless accumulation of digital and physical files and file shares that would fit right into the 1990s. Utility bills, floor plans, fax-like scans of lease agreements. Finding information felt like an expedition, and trusting what we found was harder still.

It was a crisis of entropy, and the data had a critical fault. Each data set was isolated from the others, disconnected, and difficult to use. Worst of all, much of the data produced were never used. Without interconnection, data invariably diverge, and without use, errors and inconsistencies metastasize.^Footnote1

The commercial market for facilities management software is mature. For a midsized institution managing fewer than thirty buildings, the gap between what those platforms offer and what we actually needed was vast. We would end up paying for capabilities we would never use, and we would still need to customize the software heavily to match how our operations work.

So, we lived with inefficiency.

The other barrier we faced was account management. Help desk requests were often deceptively complex: alumni whose accounts had been disabled and who needed to retrieve old data; contractors who needed system access but had no record in the ERP; remote students who were navigating disconnected online systems; and former employees who were requesting a W2 a year after their departure. Each request required broad system access, knowledge of the interrelationships between systems, familiarity with exceptions, and the right documentation. Our student employees couldn't handle these requests. The learning curve was simply too steep, and the systems were too fragmented. The tickets were escalated to full-time senior staff and system administrators, who spent valuable time on repetitive work. On nights and weekends, when students staffed the desk alone, work often waited.

Again, we lived with inefficiency.

Coding Reimagined

In fall 2025, we began vibe coding in Claude.^Footnote2

Vibe coding means running code you have not read.^Footnote3 We do that, but our trust has boundaries. We treated the code as flawed and constrained it. It was then tested and iterated relentlessly by someone who knows the operation from bottom to top.

The work started with account management. What began as several new help desk forms became a comprehensive campus-wide privileged access management (PAM) system integrating more than twenty applications, from Wi-Fi and computer inventory to single sign-on (SSO) / multi-factor authentication (MFA) and Dynamic Host Configuration Protocol (DHCP). Security guardrails allowed help desk students to re-enable alumni accounts and manage group memberships, name changes, computer deployments, email access, and dozens of other capabilities through a single interface. Institutions that have shopped for a standard PAM system know it is expensive. But a tailor-made system that saved us $52,754 in vendor costs in the first few months after deployment is new ground.

We realized the same approach could solve the facilities problem. GRID was born from that wilderness of old leases and utility bills: a facilities information system that manages buildings, floors, and rooms across the campus portfolio. Interactive floor plans provide instant information about square footage or staff office assignment. Utility dashboards track consumption across buildings and normalize for the weather, so a cold February is understood in context. Commercial lease agreements, occupancy data, and role-based access for different user groups are all built in. What had been scattered across dozens of disconnected sources could now be found in seconds.

These solutions were accomplished for the price of a Claude license and the time of an employee. The question then became: Could we make this process repeatable?

Building a Strategy

It was repeatable. Seven applications are now in production. We built these applications using a methodology: a standardized development environment with authentication, logging, version control, and custom instructions that provide the AI tool with consistent context about our technical infrastructure and development practices. This infrastructure also provides continuity. Because every system is built within a shared environment with consistent conventions, a second vibe coder can quickly orient to an unfamiliar project.

The AI is also a maintenance tool. Given the doctrine document and the codebase, it can explain a component or trace a decision back to the session that made it. It is worse at janitorial work: replaced code sits where it is until someone clears it out, and bad architecture persists until it is rigorously critiqued.

We organized our vibe coding workflow into the following steps:

1. Vision: Before writing any code, the system builder needs to write a comprehensive development plan that defines what the system is, what it isn't, who it serves, and what success looks like.^Footnote4 This foundation becomes the doctrine, an anchor point for every subsequent conversation with the AI. Without these requirements, the coding process can easily change direction, pushing and pulling a project in random directions. This documentation will evolve throughout the project. Major architectural decisions must be recorded and fed back into the AI to prevent contradictory choices that undermine the foundation.

2. Data architecture: The schema design comes next: the atomic data elements, the relationships between entities, what is sourced and from where, and what the system owns versus what it consumes. The tables, field types, sources, and even resolution rules for integrations should be laid out. Getting this right early reduces the need to constantly restructure the database as features are added.^Footnote5 In this vein, Emerson's Institutional Research department is actively building a data hub application to integrate directly with our data lake to replace a myriad of reports and dashboards.

3. Foundation: Coding can now begin. The first series of instructions should focus on basic functionality: create, read, update, and delete (CRUD) operations, basic lists and detail views, authentication, and basic security roles.

   The foundation for our PAM was a basic identity lookup and a single system integration with Active Directory. Later on, we connected many other applications. Our goals were to (1) prove the architecture worked with real data and (2) validate that the platform infrastructure (Docker, SSO, database connections) worked before we built complexity on top of it.

4. Experience: Once the data foundation is stable and populated, the interface that makes the data come alive can be built.

   For GRID, we developed interactive floor plans with layer controls, category-specific detail views, and dashboards for electricity, water, waste, and steam usage. For PAM, we created a flexible identity lookup, as well as logging and alert mechanisms. We described how the dashboard should look and feel, iterated rapidly on the visual design, and left the implementation to the AI. This step worked well only because the first three steps provided the AI with the context it needed about what data exists and how it is structured.

5. Operations: Next, the application should evolve from being a data viewer to an operational tool: automated reminders, cross-cutting analysis, and decisions that generate new data.

   For GRID, we included a reporting suite that surfaces data problems. Another system, Zero, now in production, started as a dashboard to replace budget spreadsheets and has become the system for managing departmental budgets.

Finding the Right People

A successful vibe coder needs to have a thorough understanding of the problem and the desired solution, and be able to articulate it clearly. The process is iterative: describe the next feature and ask the AI to code. Carefully evaluate the result, not the code. Provide the AI with new instructions, and revise. A single feature may require only two to three rounds of iteration or dozens, depending on its complexity and how well the initial requirements were defined.

A vibe coder must develop the following skills:

1. Domain expertise: A vibe coder must clearly understand the need at an operational level. For GRID: the practical difference between inventory assets and tracked assets, the implications of making "room" the atomic unit, and the compliance reminder escalation paths. For PAM: which account types require which approval workflows, how contractor access differs from alumni access, and what security validations are nonnegotiable for student employees. None of that could come from an AI. That knowledge comes from understanding how teams actually work, what questions they need answered, and where existing tools fail them.

2. Data knowledge: It is not necessary to have written a SQL query or worked with a database. However, thinking in relational structures is essential. For GRID, this meant that leases for our commercial tenants had to attach to the retail unit, not to the tenant. The unit persists when the tenant changes, which is what gives us a complete lease history. It is also important to think about data definitions. Usable square footage and gross square footage differ, and which one is structurally important depends on the use (e.g., furniture planning versus utility analysis).

   A similar challenge arose in our PAM system. Building a communication-management tool for the Marketing department required organizing hundreds of email distribution lists by school, department, and building. It required a relational structure that only someone who understands the institution's organizational hierarchy could define. AI can't reliably do this on its own. However, it can easily take the project in a variety of different directions, some of which would make the project more difficult to manage as it progresses. The more this is resolved in planning, the easier the journey will be.

3. Systems thinking: A vibe coder needs to understand how systems interconnect, including how they authenticate and what security boundaries they require. In GRID, this meant developing a map of authoritative data repositories, sync frequency, and key data mapping. It required someone who knows the systems environment, the canonical source for employee data versus location data, and how to handle overlap.

   In PAM, this meant mapping integrations across more than twenty systems, each with its own authentication model, data format, and administrative practices. It also meant driving the AI to build an encrypted credential architecture, because its default was to store credentials directly in the code. AI coding assistants may apply some security defaults, but architectural security and regular code audits are something the vibe coder must drive. The AI will not automatically build identity validation gates or role-based access boundaries.

4. Product sense: Vibe coders must have a sense of what makes software usable and a reasonable understanding of user interface design. For GRID, this meant lists that adapt to the type of building. When walking a building, the questions are about what is in each room, who is assigned to it, what condition it is in, and whether it still works for the people using it. Because our mental model of a building is spatial, the floor plans needed to be interactive, showing square footage, room assignment, inventory, etc.

   In designing PAM, we identified student employees as the primary operators. They are asked to field a broad range of campus technology issues with which they often have limited experience. Auto-responses, clear alerts for common issue types, and security guardrails for every workflow ensure that the application leads the user. As a result, when student employees are unable to solve a problem with PAM, they are eager to share ideas for how it can be improved. These types of user-experience decisions require a clear understanding of who will use the system and what they need in the moment.

5. Relentless patience: Perhaps the most important skill is a borderline obsessive amount of focus. It took around sixty hours at a keyboard to move GRID into production. Prompts between meetings, testing at night and during breaks in the day. PAM took hundreds of hours more. Running multiple prompts in parallel is possible, but doing so requires a careful approach because the vibe coder must ensure that the sessions do not interfere with each other. Every detail must be scrutinized, reconsidered, and adapted until all outputs are intentional. Interestingly, once this process is underway, there is a dopamine-like effect that compels further progress: each iteration brings the vibe coder one step closer to the vision, building excitement and anticipation for the next step.

What isn't in that list? A vibe coder doesn't need to know how to code or interact with a database. They don't need to understand technology stacks, how routing works between applications, or the technicalities of the extract, load, and transform process. What they do need is an IT organization behind them, running a purpose-built environment that can scale, a data architecture that sets clear standards, and robust security safeguards.

When an AI generates thousands of lines of code for a production system, especially one managing privileged access, institutional risk requires diligence. We maintain code in version control, the development environment is separate from production, and our review focuses on functional testing, input validation, and access verification. But our process is still imperfect: the pace of AI-assisted development creates a genuine governance challenge. Changes are so easy and quick to make that the process struggles to keep up. We don't have a solution for that yet. Also, using AI for code review is limited: it can inherit assumptions and blind spots in the code. For institutions considering this approach, building a review framework before the first deployment is essential. Expect the framework to evolve alongside the development process.

Rethinking the Constraint

The commercial platforms we evaluated would have required us to adopt someone else's taxonomy for how to organize our environment and perform our work. PAM knows precisely the issues our students and alumni encounter most often. A tool should extend what people can do, not dictate how they do it.^Footnote6

It would be easy to frame this as an AI story. And certainly, our work would not have been possible without Claude. But despite the persistent hype from technology companies, AI does not possess intent. It has no idea what problems we need to solve. It does not know our lived experience with systems and challenges, nor does it know how our teams work. What we found through this experience is that AI is an outstanding translator, but it is not an author. People are essential to this work.

And this is not a story about "doing more with less." On the contrary. It is a story about making new work possible. AI enables teams to tackle work that was not viable before. The people best positioned to do the work are the ones who understand the problems.

In 2022, Sam Altman wrote, "A decade ago, the conventional wisdom was that AI would first impact physical labor, and then cognitive labor, and then maybe someday it could do creative work. It now looks like it's going to go in the opposite order."^Footnote7

Our experience says otherwise. Creative work never left human hands. The misconception is that the process is a single prompt, then an output resulting in a finished thing. The machine does all the work. That is not what building an enterprise application looks like, and it isn't what effective AI use looks like. Vibe coding requires countless decisions to be made continuously by a person: what a number should be measured against, which condition deserves an alert and which is noise, what data the system shouldn't display, and how work moves from one person to the next.

The creativity in PAM and GRID was never in the code. It was in the operational insight that informed every design decision, and there were thousands of them. AI handled the syntax. The intent was ours.

This is what creative vision means. Every creative work is made one decision at a time, and every decision reveals more opportunities. This vision is the capacity to hold one direction constant: a fine discernment of what is necessary and what must be absent. Commodity AI tools tend to produce the average of their training: a generic answer for anything left unspecified. But a decision without creative vision is a default by another name. And defaults compound. The file shares we started with were not a failure of effort; they were decades of decisions no one made. That is institutional entropy: a default, accumulated.

A platform that arrives with its own assumptions about how work is organized is yet another default: someone else's average. Why adopt it and then spend years conforming to it? Large platforms are here to stay, for now. What has changed is the constraint. It used to be budget, or a vendor's roadmap, or a developer you couldn't hire. No longer. AI has never taken on creative work. Instead, it lays bare the constraint that remains: knowing which problem is worth solving and making the time to solve it.

Why haven't you started?

Notes

1. Information theory and organizational design both explain this failure. Claude Shannon showed that errors are only detectable when the parts of a system constrain one another. Our records had duplication and contradictions, but without constraints, there was no way to determine which of two different square-footage figures was correct. Herbert Simon described what happens next: "a wealth of information creates a poverty of attention." When the cost of adjudicating data exceeds the immediate value of the answer, the data becomes functionally nonexistent to the institution. See Claude E. Shannon and Warren Weaver, The Mathematical Theory of Communication (University of Illinois Press, 1949); Herbert Simon, "Designing Organizations for an Information-Rich World," in Computers, Communications, and the Public Interest, ed. Martin Greenberger (Johns Hopkins Press, 1971). Jump back to footnote 1 in the text.↩
2. "Vibe Coding," Merriam-Webster, Slang & Trending, last updated June 4, 2026. Andrej Karpathy introduced the term in a February 2, 2025, post on X. See, Andrej Karpathy, "There's a new kind of coding I call 'vibe coding,' where you fully give in to the vibes, embrace exponentials, and forget that the code even exists," X, February 2, 2025. Jump back to footnote 2 in the text.↩
3. Of course, every enterprise runs code no one has read internally. The trust and the legal liability reside in a software corporation. With vibe coding, the risk is accepted internally. Jump back to footnote 3 in the text.↩
4. If you skip this step and just allow an AI to do it for you, you are wasting your time. AI is decent at critiquing thinking and suggesting some alternate paths, within constraints, but an AI tool doesn't know the problems or opportunities at your institution, and it is only ever as good as the context that it has to work with. Jump back to footnote 4 in the text.↩
5. Note that the AI will readily put key data elements into code, or even into memory, if you don't instruct it properly. Jump back to footnote 5 in the text.↩
6. Ivan Illich, "Convivial Reconstruction," in Tools for Conviviality, (Marion Boyars, 2001): 10–45. Illich's broader argument is that institutions tend to invert the relationship between tools and people once a threshold of complexity is crossed. This dynamic is visible in any enterprise software implementation. Jump back to footnote 6 in the text.↩
7. Sam Altman, "DALL•E 2," Sam Altman (blog), April 6, 2022. Jump back to footnote 7 in the text.↩

---

Brian Basgen is Vice President, Digital & Physical Infrastructure, at Emerson College.

Frankie Frain is Assistant Vice President, IT Security & Infrastructure, at Emerson College.