The Things I Wanted to Make
This essay expands on Rift, which I published in May, and follows what’s happened since. It was originally commissioned but ultimately wasn’t accepted for publication. I’m sharing an edited version here.
When I was a teenager, my family took a weekend road trip from Warwick, Rhode Island to Mystic, Connecticut. It was on that trip that I purchased Billy Breathes, the 1996 album by the band Phish, from a head shop in Mystic Village – I often wonder if the shop is still there. From that moment on, I was hooked, and not a single day has gone by that I haven’t listened to Phish.
Despite growing up in New England, where Phish often played because they were an up-and-coming band from Vermont, I didn’t get to see Phish often. Instead, Phish became the soundtrack to what would go on to dominate my personal life: programming. In 1998, my first job was that of a tech support agent at an early tech startup. There, between work – which I did after getting home from high school – and my home life, all I did was program. I programmed and listened to Phish.
If you’re not familiar with Phish, they’re known for their heavily improvised performances. The shows are so diverse and improvised that no set is ever alike, even if the setlist happens to be the same. Fans travel from all over to see the band on multi-night runs, where they’re guaranteed to see multiple nights of different songs and different, deep improvisation.
For the last 30 years, I’ve programmed and listened to Phish. It started with my 1998 job in telephone technical support, where I was eventually promoted and took on more serious programming tasks. It continued into my next job at Berklee College of Music in 2006, where I also got to take courses for free and base my student projects on Phish songs. After that, I spent time at several tech startups and eventually started my PhD in Europe. I completed my PhD at Carnegie Mellon University in 2024. Phish earned a special place because their free-form improvisation gelled incredibly well with the deep technical exploration and programming work I did daily.
When I can’t go see them, I couch tour: I watch the shows from home. During my dissertation (2021 to 2024), I couch-toured every show on their tours. At some point the music and the code merged into one, and the flow took over. That’s just what Phish does to you.
In 2024, as I was graduating, many of my collaborators at Carnegie Mellon University became obsessed with AI. This meant shifting their research programs and their students’ projects into AI and AI-adjacent work. I remained steadfast, skeptical that it was more than a novelty. At the time, I believed AI would never replace the deep, focused technical thinking required to write the kind of systems I worked on: large-scale distributed systems and microservice applications comprising hundreds of different services.
In 2026, that all changed. Around then, I was assigned a project at work to write programs in a programming language I didn’t know. I started with Cursor, an IDE with integrated AI auto-complete. What I found confirmed my hypothesis: I still needed to know the basics of the programming language I was working in, and AI was nothing but smart auto-complete. But, much to my chagrin, the auto-complete helped me write a lot of boilerplate, which most programmers don’t want to write in the first place. It seemed quite a compelling trade-off.
By February 2026, Claude Code was inescapable in the news. Articles posted almost daily showed you could build entire clones of SaaS products in a matter of hours with a simple prompt: no IDE required; you don’t even need to know the programming language the application will be written in. I remained skeptical, but decided to try it. To test its capabilities, I picked one of my most frequent and irritating tasks. This involved organizing development tasks, reviewing requests for comments (RFCs), and making sure the proper stakeholders approved mine. Within an hour, I had an application, written by Claude Code, that found all my documents in Google Drive, parsed them to find all the delinquent approvers, automatically pinged them on Slack, and organized my day around what was most pressing.
This software could make my life easier and free up my time for other things, and I built it in an hour.
I didn’t have a personal computer at the time, but I wanted to try this, so I took my iPad Pro, installed the Claude Code iPad app, and asked it to build me an app. My prompt said something like, “Could you build me a social network app?” with details like login, a feed, and the ability to share music albums you are listening to. The idea came from buying a lot of vinyl records at the time and taking photos of the particular editions I bought, cataloging the editions that I was listening to – depending on the year and label, there can be a lot of differences between editions for particular albums – and sharing my thoughts on the album and release.
At the time, I shared this primarily on Facebook, but I increasingly found my posts never reached the people I wanted them to, and it was hard to format them the way I wanted because they were just generic posts with photos. In essence, I wanted an app that let me share what I wanted, the way I wanted: selecting an album from Spotify, adding release information, showing the album artwork, and classifying the genre. So, that’s what I asked Claude Code to build me, and that’s what it did… quickly, very quickly.
Claude built this application in about 30 minutes. It never asked me the programming language – one wonders if it really matters in this new world. It told me a service I could use to deploy it so others could access it, gave me instructions on getting a domain name, helped me pick the domain name and configure it, linked my GitHub account to the deployment service, and pushed the code to GitHub from a Claude Code cloud container my iPad was driving. Within an hour, the app was deployed, and that moment made me obsessed with AI and agentic development.
I continued to iterate on it. What if I wanted to post about an album that wasn’t on Spotify but only on Discogs? 10 minutes, get a token, implement the API. What if I wanted to show the cover art? 5 minutes. What if I wanted to show the track listing? 5 minutes. What about favorites? Sharing? Profile pages? Scope creep wasn’t even a concern: it was a five-minute detour for Claude Code.
From there, I quickly learned I needed a native mobile application.
When I shared the website with most of my friends, they said, “Is there an app?” The answer was no. To me, I’d already built an app. To my friends, it was still just a website. So I worked with Claude to learn how to build an iOS app and publish it in the App Store, something I had little experience with. After overhearing conversations at my day job, I learned that a technique called SDUI (or server-driven user interface) would let you ship a mobile shell and drive most of the app design from a backend. This sounded appealing for the fast iteration cycle that I wanted: many interface changes could ship without a new App Store release. I didn’t need to know how to implement SDUI: Claude knew how to build an app in that style.
The one problem that remained was that iOS mobile applications required Xcode, and you couldn’t run it on an iPad. So, using the Apple Store app and same-day delivery, I had an iMac delivered. That night I had Claude build a mobile app using server-driven UI, build the mobile shell for the application, build the Xcode release, and walk me through every step to submit it to the App Store. Within days, I had an application running on my iPhone: my new social network, Zabriskie.
The first major change I noticed in this new development model was that most of the cycle was spent telling AI to do something, waiting a while, coming back, and testing the results. I immediately found myself doing other things: cleaning dishes, taking out the trash, organizing the apartment, making the bed. I had lost the concentrated focus on programming, but I was using that time for chores. This wasn’t alarming, but rather liberating: I’m no longer writing a lot of code that I never wanted to write in the first place. As a trained Ph.D. researcher, it’s never exciting to struggle with verbose Java APIs to implement your research or someone else’s algorithm just to establish a benchmark baseline. AI simply took away the repetitive work that you didn’t want to do in the first place.
From there, things escalated significantly. First, I built features in the app so quickly and with so little effort that I exhausted my basic Claude Code allocation in a matter of days, so I upgraded to the 20X plan. From there, I signed up for more AI resources. Each time I ran out of tokens mid-week, I signed up for yet another AI plan, trying different providers and models to keep shipping. Shipping: it was addictive.
In April of 2026, Billy Strings was playing several shows in St. Augustine, Florida. Several nights before the shows started, I had an idea: it would be cool to have a live chat that showed the setlist of the songs being played and gave those watching at home a chat experience. My friend Patrick agreed it was a cool idea, and I told him I would try to prototype it in a week. In a single evening, the day before Billy Strings’ first show in Saint Augustine, I built it. Over the next three nights of Billy Strings shows in Saint Augustine, we tested the feature with my friends watching Billy Strings at home while we debugged both a new Android app and an iOS app. Sadly, neither worked correctly.
This was our first time debugging features that didn’t work correctly live, even though they worked fine in development. Patrick, on an Android device in Massachusetts, and I, on an iOS device in Pittsburgh, repeatedly iterated with Claude: every fix on Android broke the feature on iOS until, days later, we both had it working. We finally saw everything work a few nights later, when Pigeons Playing Ping Pong played a live show that was broadcast on Nugs, a live streaming service. We both joined the live chat and saw the setlist updates in the chat work perfectly. What remained was a test with one of us at the venue.
The following week I booked a trip to New York to see one of my favorite directors speak at the IFC Center and present her new film. I booked the wrong weekend, and ended up in New York a week early. I worked at my company’s office for that week and decided not to fly all the way back to Pittsburgh, but instead spend the week in the city. Trying to find something to do, I learned that Tedeschi Trucks Band was playing a multi-night residency at the Beacon Theatre that week. I figured this was the perfect time to really test the app’s functionality.
The Tedeschi Trucks Band run identified several issues in the app. First, it didn’t know where to get the setlist from, and second, the live chat and live activity on iOS were again not working correctly because something had caused a regression in their behavior. Using a remote Claude Code session back to my iMac in Pittsburgh, I was able to not only fix the feature, but force a new release to TestFlight, download it on my phone, and see real-time setlist updates and a working chat delivered during the set break of Night 2 of the show. I was truly amazed at the power of this technology.
When I returned to Pittsburgh after my New York trip, I bought a MacBook and got ready for the Goose Spring tour. At this point, we had Android and iOS apps that worked great, and my friend and I had alternating schedules for the shows we were going to: we knew that we’d overlap at a couple, but for the most part he would be at the show when I wasn’t, and I would be at the show when he wasn’t. We planned to use the chat experience to communicate during the show, share photos, see the set list, and hand out stickers at the shows we were at, prompting people to join our app.
Goose spring tour starts in Asheville. When we get there and get to the venue, the app works great: setlist updates in real time, and friends are in the chat from the pit, from home, and from the stands. It’s the first real Goose show on the app, and we have the chat active. My neighbor in the stands asks me what I’m doing on my phone, and I show them the app I built that shows me the real-time set list and lets me chat with my friends at home and in the pit.
In the hours between shows, the app is buzzing. People are posting interesting books that they’ve read; they’re also posting about videos and films that they’re watching and commenting on other posts. There’s a constant stream of activity from a small group of ten regular users. I know that the key is that we have to get more users on the platform.
The next show is Birmingham, and it’s the same; the show after that is Orlando. Orlando is a festival set. Most people don’t travel to the festival set because it’s only a single set played by Goose, instead of two sets with a set break. Because of this, it’s a shorter Goose set, and the travel to Orlando and lodging is expensive. I’m there because I’ve had good luck with festival sets with Goose, and Goose plays an all-timer featuring Sinnerman, with a deep jam. In the chat, the few folks following along are getting real-time updates to the setlist because the show isn’t live-streamed. We’re telling them how awesome things are going, and I continue to wish more people were using the app.
After Orlando, I drop out. I’m heading to the Sphere in Vegas for a big trip I planned the previous year for 9 nights of Phish across three weekends. My friend Patrick, who also works on the app with me, is joining the Goose tour at this point. We know people join and leave the tour at various stages, so we built the app with an interactive timeline that shows when people join and leave as the tour moves across the United States. This is how I knew Patrick was joining on at that point of the tour without explicitly asking him; conversely, that’s how he knows I’m dropping off for Phish.
One of the benefits of the app that we had built was the ability to monitor the setlist of a show you weren’t at – dual Live Activities for shows that you’ve expressed interest in. This allows me to join the Goose chat during their East Coast show while I’m still working before heading to the venue in Vegas: the shows overlap by an hour or so, so when I’m waiting at the Sphere for the show to start after doors, I can follow along with the Goose encore. On the ground at the Goose shows, Patrick diligently hands out stickers and gets people to join the app, promising a new social media app focused on live music that provides Goose setlist information and song statistics.
At the closing of Goose’s 2026 Spring Tour, Patrick had grown the number of registered users from 271 to 460. For all intents and purposes, the app delivers the experience exactly the way we want it to and, from our perspective as the app’s authors, the only thing that could improve it is more users and higher engagement. This is the AI promise realized: reduced time authoring boilerplate code that’s been written hundreds of times over, and more time doing the things we want to do: seeing shows and hanging out with our friends.
Everything we built for the app led up to Red Rocks in August. Goose was playing three nights at Red Rocks Amphitheater in Colorado. It was a huge event: many people had traveled across the US for the event and were at the concert – including myself – and many people who couldn’t come to the concert were following along at home on the app. This mattered because the first two nights of Red Rocks were on the nights leading up to a weekend, and the third night was on the following Tuesday, when many people had traveled for only the first two days leading into the weekend. It was exactly the moment when we needed the app, and everything the AI had built, to work correctly. It didn’t.
The problem first showed up right after the doors opened, when many of my friends came to me trying to use the app, but it wouldn’t load at all. The app showed only a spinner before showing a generic “Something went wrong” error, and I shrugged them off, blaming poor cellular service and Wi-Fi signal at the amphitheater, which is located in the middle of the mountains outside of Denver, Colorado. The problem wasn’t on their phones: it involved a configuration setting that the AI had coded in a very early version of the app developed back in March that became extremely problematic once the application scaled to a larger – and not very large – number of users. Trying to debug from the seats of the amphitheater, I frantically copied and pasted information from the various consoles I could into the AI chat. The small programming error inherited from the app’s early days should have been fixed in minutes, but it wasn’t.
The bug itself was small. However, we ran into a problem while deploying the bug fix, as the AI had tied our deployment pipeline to the production system, the very system that was experiencing the issue. In short, the bug fix had to pass CI – continuous integration – before it was allowed to merge, but the CI depended on the production database being able to service queries, which it was unable to do. One possible escape hatch existed: forcing a merge without waiting for CI; however, this had to be disabled because it was consistently abused by the AI agents to deploy changes without waiting for CI to pass. The protections we had added to stop agents from shipping untested changes now blocked the fix too. The checks depended on the system we were trying to repair.
This situation wasn’t unique to Red Rocks, however. As another example, many of the Goose performances on that tour weren’t broadcast live: people who couldn’t catch the tour joined our live chat for real-time updates on what was happening at the venue, as reported by folks there. Instead, they were broadcast after the fact. One such performance, Goose’s performance at the Dillon Amphitheater the night after their third performance at Red Rocks, was scheduled to be broadcast in the weeks after their tour ended.
To prepare for this live broadcast, we used AI to rewire the application for a couch tour that didn’t coincide with a live performance. The moment the show went live, the application didn’t work correctly. Several UI problems surfaced almost immediately, but finding the underlying cause took longer. By 9:12, we had identified and reproduced the bug, with an hour of the show still left. The fix was two lines. The show ended at 10:12. The fix didn’t merge until 10:17, five minutes after the show ended. The reason was that the AI had built such a house of cards around how the software was built and tested that minor changes became impossible to make in a short time. We had asked for tests to prevent failures, but ended up with a process that made failures harder to recover from.
We had experienced this many times: it wasn’t new or unexpected. In fact, the pattern kept repeating: we asked the AI to build a feature, we asked the AI to test a feature, we asked the AI to test a feature under a particular number of scenarios, but we kept finding problems when it needed to launch. We should’ve learned our lesson by running simulations, which we asked the AI to do. Still, we kept running into assumptions that were violated in the moment. The software worked in development, but live shows kept exposing assumptions we hadn’t tested.
And when I wasn’t fixing what we’d already built, I was adding what people wanted next.
The centerpiece of the app from our users’ perspective was the live chat: the chomp, as we call it, a reference to “chomping,” the annoying behavior of talking during live performances – not allowed in the venue, but very much allowed on the app. Over many weeks of using it for real shows, we gathered requests for new features: watch apps that let you see the setlist and read chat messages, and statistics on when a song was last played and whether you were there the first time it played.
It also let you guess the next song. This is a feature I pushed back against very, very hard because I don’t like the gamification of apps, and I think it takes away from the experience of enjoying a rare song when it pops out, rather than a common song you guessed correctly.
People would get into the chat and say, “Oh, it’d be cool if I could see this.” Many of these features were requested at the beginning of shows and deployed before the show was even over, with AI building them in minutes and most of the latency spent getting them out safely through testing and our continuous integration process. We added features as users requested them to keep them engaged, to make it seem like we were the best app for jam band fans out there, and to make it seem like we offered everything they would possibly want to know about the live show experience.
While we built the features users requested, the rest of the site experience suffered. To improve engagement and address persistent feedback that folks didn’t know how to use the site, I created a new page called the Lot: it was meant to mimic the stalls you see before a Phish show in the parking lot, where merchants sell various wares they’ve made. The Lot was a series of cards that highlighted the show you were going to, the show you were talking about tonight, upcoming shows you might want to go to, and other shows in your area you might want to attend. With the emphasis on the Lot, the app shifted toward an experience designed around live show consumption and couch touring. The main social feed that I had built – the primary feature of the app when I originally developed it – was relegated to a secondary tab.
I liked what we had built for the shows. But I still wanted to post about a record or a film and hear what my friends thought. That was why I’d started building the app, and now I was making less room for it.
These changes further increased engagement in the live experience but completely deemphasized the main part of the app that I was trying to build for myself: the reason for the app originally existing. As a result, only a few die-hard users kept posting what they were listening to and most user engagement focused on the Lot and what it had to offer: calls to action about reviewing last night’s show, RSVPing to new shows, and looking at the previous night’s setlist.
Every waking moment I wasn’t working at my day job was spent shipping app changes in response to bugs in the experience and user feedback, and therefore I stopped paying attention to what was actually happening in the broader jam-band community. Those same features had started appearing in other apps, both new and existing. In fact, in just a few months, developers built setlist apps that pushed to your watch for a variety of bands. They had built apps to compute statistics over songs. They built their own social networks for all different subcultures and bands.
AI let me build the app I wanted, and it gave other people the same opportunity. They could build their own versions, with the features and choices that mattered to them.
What started as a mostly hands-off experience – AI developing features while I cleaned my bathroom and made my bed – had grown to consume not only the hours that I dedicated to the continued development of the application, but now even my time at shows where the app was supposed to enhance the experience, not dominate it.
It became very clear to me that something about software had fundamentally shifted. I could build an application for the way I wanted to do something, even if nobody else wanted it that way.
I like to call this idea “software for one”.
We had handed out stickers promoting the app’s live experience, not the social feed, and then treated every request in the chat as something we had to implement to keep people using it. We even built an automated system to track which features people clicked on, remove those they didn’t use, and tweak calls to action and button placement to keep them engaged.
I wanted other people to use it. But somewhere along the way, getting them to keep using it became more important than what I wanted to build.
What I was really looking for was the experience that you have after a show, which is that after you finish the show, you end up going back to somebody’s house or somebody’s hotel room or somebody’s patio and reflecting on the show, saying what you thought about it, recalling what they played, what you thought was the best, and talking about other things that you’re into with the people that stood next to you at the show.
One of my fondest memories was ending up at an Airbnb around a pool in the middle of the night, drinking beer with my friends after a show, talking about our favorite highlights of the show, and then being able to tell them about one of my favorite movies, Close-Up, directed by Abbas Kiarostami. This film is truly mind-bending because it distorts the reality between storytelling, re-enactments, and factual events. My friends still remember me telling them about this story, this movie, and how much it blew their minds and made them want to go out and explore new things. That’s the type of connection I’ve always wanted the app to facilitate and be about: a diary of the interesting movies and media your friends consume, and a way to build connections that last beyond standing beside them at a show for a few hours.
My app was born out of the ethos of “software for one” – it just took me months to understand what I meant by that, what it was, and how it all fits together. In retrospect, I built it for myself because I wanted a particular way to connect with other people: through the music, films, and books we were interested in. The receipts are there: when posting an album, you can share a picture of your copy because I have a large vinyl collection; when posting about a film, you can share if you are watching the Criterion Collection’s physical edition because I collect physical media from the Criterion Collection.
Nowadays, I treat my app as a personal app. We still have devoted users who show up every time Goose or Phish plays a show and participate in the live chat; these are mostly my friends. Both they and I enjoy seeing when a song that is playing was last played, and they enjoy seeing when one of us was at a show where a song currently playing was played for the first time. They especially cheer – using the app – when one of us is at a particularly exciting show and always want a full report through the chat about how the crowd is, the lines, the weather, and the vibe. In the end, we share moments between a closely connected group of people. That’s not massive engagement, but it’s engagement that matters to me.
I still use the features we built, and I’m glad we built them. What’s changed is that I’m no longer treating every request as something I need to deliver to keep people using the app. I’m focusing on the things I want to make and use.
This includes building ways for me to find connections between what others have posted and what I’ve posted – for example, two films sharing the same cinematographer – but given that the feed is still de-emphasized for the live show experience, those opportunities are becoming fewer.
Along the way, I’ve built several other things that I personally find interesting: an audio player built from audience recordings of shows played on this day in past years, which allows me to explore a band’s live performance history and discography during the workday, and a feature that allows me to find related media along a theme of what I’ve recently been exploring: my latest obsession is postmodern cinema and literature. In the most “software for one” sense, I’ve built a mechanism that allows me to pull my live show RSVPs from the app and then find hotels, flights, and even safe gluten-free food that can be delivered to my hotel – things that make travel for someone who can’t eat gluten, but loves live shows and traveling to live shows, much easier.
Thirty years ago, I started listening to Phish, and it accompanied me through some of the hardest programming challenges of my life. I embraced the long, deep improvisational nature of their music, which allowed me to lose myself in the task I was working on for hours at a time – in essence, surrendering to the flow. I never expected the way I spent those hours to change so much. Surprisingly, what I found on the other side wasn’t more programming, but an easier way to see Phish perform more often.