Vibe Coding AfterAGI.IO

Originally, I despised “vibe coding.” Software development and design were the areas I was most skilled in, having studied them for over six years, and out of pride, I vehemently didn't want to be a vibe coder. Andrej Karpathy had coined the term in February of '25 (Andrej Karpathy 2025), three months before I began this project. By the time I finished, it was how most people wrote software.

In early '25, AI coding assistants couldn't read an entire codebase and generated plenty of broken files that wouldn't compile. Humans were still required to design the architecture of the full system themselves. I liked it that way because I still felt needed. By '26, that had changed completely: it is now commonplace for coding platforms to write entire software architectures without you touching a line. When those features rolled out, I was uncomfortable.

In contrast to my process of making the musical, I thought it was important to document how AI could help me develop software to expand the story. One of my missions is to make academic work more accessible to the public, so I thought it would be important to host the thesis online and make it engaging for a broad range of readers. This was the original idea for this web app.
I began building Afteragi.io in September ‘25, after the first draft of my script was complete. In the mornings, I practiced producing music, creating a new track every day. Then, in the afternoons and late into the evenings, I was glued to my computer, building this immersive narrative site.

Narrative Web Apps

Intending to develop for the browser meant there were some nice constraints from the start. I was inspired by prior work I’d seen using the browser for experimental narrative experiences. So, as I created a virtual world on AfterAGI.io, I looked up other projects that explored the potential of storytelling through this interface. Some key references I will describe here, broken into the categories: web-native narratives, immersive web experiences, and AI-native narrative sites.

What makes web-native narrative projects unique is their use of browser-specific capabilities to enhance the literary experience. To drive a story, they use browser-based interactions such as infinite scroll, multimedia, and hyperlinks. An example is Jon Bois's 17776 (Bois 2017), published on SB Nation in 2017. It tells the story of an immortal human society in which American football is played across the galaxy, using animated GIFs, satellite imagery, and embedded video.

This work comes from a longer lineage of hypertext fiction, reaching back to the works of Michael Joyce, such as afternoon, a story (“Eastgate: afternoon, a story” 1990), which was delivered on a floppy disk. This hypertext story could change depending on the reader's choices, like a choose-your-own-adventure story. You might be familiar with Bandersnatch, the choose-your-own-adventure film produced by Netflix (“Bandersnatch” 2018) in 2018. Neal Agarwal's The Deep Sea (Neal Agarwal 2019) is a simple yet common example used in classrooms for educational purposes. This web-based narrative turns a single scroll gesture into a descent through the ocean, giving users a sense of the depths at which different ocean creatures live. It uses a single interaction, the scroll, to evoke awe. From this category, I drew inspiration to use web-native interactions to change how an audience engages with text, as you can try at ReadMe.txt

Immersive web experiences instead turn the browser into an interactive stage, often capturing a visitor's own data as material. The Wilderness Downtown (“The Wilderness Downtown” 2010), created by Chris Milk in 2010, asked for your childhood address and then drove Google Street View footage of your own street into the music video as it played. A different immersive tactic is used in Bear 71 (“Bear 71 VR” 2016), a National Film Board of Canada documentary from 2012. It takes footage of a wild bear caught on surveillance cameras, with location data, and places it into a 3D landscape, charting the story of a single grizzly bear and implicating the viewer in the bear’s journey. Another intriguing take on this genre is Stealing Ur Feelings (“STEALING UR FEELINGS” 2019), which runs emotion-recognition AI on your own face through your webcam while explaining what such systems do with the results.

What I took from these works is that the browser is most powerful when it uses something the visitor already carries, their street, their data, or a 3d environment to place an audience in the story in ways traditional media can’t. This is why AfterAGI.io is built as if it is the main character's IDE (Integrated Development Environment) on his local computer. Since Theos, the main character, is a software engineer who spends most of his time programming in an IDE, it was an easy narrative frame that would also host a variety of file types. The audience is invited to explore the IDE as if it were on their own computer and is encouraged to rummage through the files, where they might find additional content and hidden easter eggs about the story.

The most current category, AI-native narrative sites, use AI as an engine to generate dynamic content unique to each interaction. AI Dungeon (“AI Dungeon | Free AI Text Adventure Game” n.d.), released in 2019, used a language model to improvise an infinite number of narrative trajectories. Using a game-like platform, they use AI to build a never-ending fantasy world that users can tailor. Similarly, Hidden Door (“Blog | Introducing Early Access · Hidden Door” 2025), launched in 2025, pairs LLMs with role-play and fan fiction, allowing an audience to create characters within a structured world that they build upon each time they return to the site. This genre uses AI in the browser so the characters respond directly to instructions, a tactic similar to what I used to animate CLEO on my IDE site. Using the script text as a reference, CLEO from the story can be spoken with on the CLEO.ai page to explore Theos’s computer.

AfterAGI.io and its subdomains, Book.AfterAGI.io and Shop.AfterAGI.io, sit at the intersection of these categories, and it was developed with the now-prevalent vibe coding practice. Designed as if Theos and CLEO had created it together, it extends the musical's story and the concept of human-AI collaboration into the real world through an interactive medium.

Designing a Digital World

The web app structure was designed so that each domain — the Book, IDE, and Shop — had its own platform shell with a different purpose. What holds them together is the same visual aesthetic and narrative focus.

The Book.AfterAGI.IO is built like a custom audiobook app, similar to Audible, but in the browser, within the techno-apocalyptic musical-visual world, with some custom features. The interface is deliberately traditional, so anyone who listens to audiobooks can navigate it. Each is underscored with music and has minimal effects throughout the text to emphasize phrases beyond what is possible on a static page. It also embeds unique elements, like Splats, for image references rather than just the 2D images possible in print.

For the main AfterAGI.IO IDE, I wanted it to feel as if you were in the main character's computer. So there are files that seem unfinished, like working drafts that Theos lost track of. Built like an IDE, it uses the traditional IDE look and feel with a similar layout and design, but again using the techno-apocalyptic musical-visual world with unique twists. Going to the debug tab leads you to a literal, interactive bug-squashing experience, and the git log tracker acts more like a comments thread that you yourself can commit to. I also took inspiration from theatre production, converting documents typically printed during a stage production, such as character briefs, costume designs, and set designs. I implemented digital versions of these documents but intentionally kept them hidden, accessible only via the IDE search functionality. With this, I hoped to encourage you to explore the depths of the repo while offering a behind-the-scenes look into how it was built.

Shop.AfterAGI.io was the latest addition to the system architecture. I wanted to build a satirical prediction market so people who watched the musical could vote on what happens next to the main characters. This also ended up inspiring an underground market clone of a retail site like Amazon. But instead, this is where Theos is selling everything he owns, clearing out his apartment after he has to go into hiding. This is the cliffhanger of Act One. I screen-printed a custom shirt for Theos’s character and made a limited number available for purchase on the site if you can find them before they sell out.

Having built over 10 software apps before, I found AI the easiest to integrate into the generation, feedback, and iteration phases of this project. I knew how to speak the language of code, and AI made it frictionless to implement something I'd already built on a past project. I built out features quickly, even when I wasn't certain I would need them. This was a benefit of using AI, but it is also how you get “feature creep”, developing elements that ultimately make your interface more confusing. So there is a new set of problems that human-AI collaboration in coding brings to light.

P5: Personalize your Scale of an Iterative Loop (Know how to speak the language)

Even the most advanced computer engineers can't compete with the speed at which AI can code. AI’s raw speed in reading and generating text files gives it a ridiculous advantage over human beings. But when collaborating with AI, we must be aware of what I called the scale of an iterative loop, which is my next principle: Personalize your scale of an iterative loop.

When coding, you might have a list of features to be built as you develop a system's architecture. Typically, as you are making these changes, AI may want to make more alterations than you originally set out to build. Or if you are just beginning a software project, AI will build the entire system from scratch. Depending on your level of knowledge, this can get tricky.

Generally, my rule of thumb is that the more knowledgeable you are in a field, the larger your iteration scale can be. But if you are just beginning, you should keep your iterations small, so you learn how the system is built from the ground up. Making a loop smaller, for example, would mean working with AI to build a single function, component, API, homepage, or hook for a web app rather than your entire idea. Working at a smaller scale will help you speak the language of a domain that will be opaque to you when you start.

If you have no experience in coding, allowing an AI to build a system in its entirety will seem cool. In reality, you didn't build anything, and you don't know the technical language to guide its progress. Forcing yourself at each level of production will give you the right knowledge and perspective on what changes to make and, more importantly, what is really possible. This is key! If you are less knowledgeable in a field, you are also less knowledgeable about the possibilities in this domain. This will take some time to learn, but it will be worth it in the long run.

P6: If you don't know how it works, you're in a bad place

If you don't know how it works, you're in a bad place. No matter your skill level, this will likely happen to you. You might think it's funny, but it's true. This could lead to “intellectual debt”, a future where we depend on a system that we ourselves don’t know how to build. This concept is easiest to explain in the context of coding, but it matters in any co-creative project. Make AI explain things to you, often. And actually read the explanation.

There are many memes online about struggling to find a bug when vibe coding. The issue is that if you weren’t involved in your software's design, you won't know how to fix it when it breaks. In vibe coding, you can build a lot of features really quickly, which means your codebase can explode in size and complexity in just one week or even a single day. This can lead you into some corners. Building things you never finish. Testing spur-of-the-moment ideas that lead you down a rabbit hole. Creating multiple versions of an FX or function, leading to discrepancies when calling it throughout your build.

An important method for addressing this problem is making a system diagram for each of your projects. A system diagram for each of my repos for the AfterAGI.IO site is in Figure 10. These diagrams will help you gain a high-level understanding of your system architecture, and they should be updated periodically as you continue to develop. In my diagrams below, I attempt to lay out all the elements in my codebase so I can easily develop them further. I also add tags to items I know are finished vs those I still want to improve. Especially if, in your coding practice, you are not looking directly at your codebase, this method will give you a clearer window into what is going on under the hood.

You can also make a system diagram for a song or script; this is not limited to coding. But another thing I encourage you to do is read AI’s responses and descriptions carefully. If you are iterating at a very large scale, making many changes all at once, you need to pay close attention to what is developing in each iteration. Ideally, you have already developed a plan with your coding assistant, mapping out your build to reach each upcoming version of your project. But this doesn't excuse you from reading and confirming the deliverables at each stage of the development process. Because it only takes one misunderstanding to severely alter your work and unintentionally lose a large portion of what you’ve built.

Vibe Coding has definitely changed what a coding practice looks like. Therefore, we need new behaviors to still develop with the 3Rs of software engineering, making our work readable, resilient, and reusable (Connolly et al. 2023). These two principles are high-level guides to this new paradigm.

Unquestioningly Embracing Progress

As of August ‘26, coding agents like Claude Code and Codex make it so you don't need to write a single line of code. The improvements in AI coding capabilities between August ‘25 and ‘26 are the most striking and astonishing out of all domains. Most programmers have no choice but to adopt these tools because not doing so would lead to an indescribable disadvantage.

Meanwhile, these improvements are also leading to drastic inequities. People with access to the best models have significant capability advantages. Running multiple agents, such as Fable 5, over a month-long period can cost thousands of dollars in computing power alone. This inequity is only increasing as compute power becomes increasingly sought after, and these models consume more energy.

“Tokenomics: Token economics” is a new phase for learning how to be most cost-effective when using AI. Choosing the appropriate models for certain tasks is critical to avoid using a more costly model for menial jobs. These AI-use tactics are important for creating sustainable co-creative practices that are affordable and environmentally conscious. Yet, it must be stated that there will be a cost barrier for a large portion of the population, excluding them from the benefits of AI in software development. This is an ongoing problem that we are in the midst of uncovering. While my principles don't yet address these inequities directly, I'm developing this framework with more tools and direct guidance on varying costs to give everyone a way into this future.