Welcome to 2026! It’s going to be an eventful year, and there’s nothing to be done about that. I know some of us were hoping AI would go away over the break, but it’s here to stay. I have spent the past couple of months going deep on Claude Code, and I want to share some very high-level observations.

“Going deep” sounds intense, but actually involves typing a chat message into your phone and then coming back to it 20 minutes later to see if it worked, over and over again. You can finally write complex software on the bus. (And if Mayor Mamdani gets his way, that bus will be fast and free.)

Just so you know I’m not a fraud, I’ll share my very broken work-in-progress: A digital audio workstation that runs in the browser on iOS Safari or on Chrome on the desktop. It’s extremely buggy, and uses technologies that I do not understand one bit. It may not even make sound for you (it does for me). I’m consciously trying to code something where I don’t understand the ingredients, but can judge the output, like one of the more annoying guests on Top Chef. 

That said, I built the workstation in such a way that I can say, “Use our open-source component library to clone a Prophet 5 synth by getting the manual from Archive.org and add that,” and it will do it in about five minutes and sound pretty good. Whole new frontiers of intellectual property challenges await us!

A huge amount of the discourse about vibe coding has to do with “one-shotting”: Describing your application in a set of bullet points, walking away, and coming back to find that an army of agents has done the work that used to take weeks, months, or years. You tweak it, and you’re golden. This approach was well-visualized in the classic Disney short “The Sorcerer’s Apprentice.” 

For a few weeks, I kept trying to one-shot big chunks of this thing, but over time, I realized that’s not the right approach. As I explore this new way of working, I keep murmuring the three “A”s: Aim, Architecture, and Accountability. This isn’t just more of my business-speak nonsense. I really need to remind myself, every five minutes, of the three As.

Aim. It’s incredibly easy to lose sight of what matters. I spent eight hours trying to get a clone of a synth from 1983 that I don’t even like running in the browser. I went to sleep frustrated at 2 A.M. I also utterly neglected practicing real piano while I was trying to synthesize a piano; my piano teacher has sent me back to Bach as a punishment. 

Code has its own gravity. It’s hard to see it as disposable, just like it’s hard to erase paragraphs you’ve written when editing. The cost of building the wrong thing is so low that you need to constantly say, “Wait, do I even want this?” 

Architecture. This is a tough one. I think people are being sold AI as a massive miracle, but when you get it home and open the box, it turns out to be little miracles mixed in with spare coins and old socks, and you have to sort through it.

If you want to build sustainable software, you must fully understand and manage its architecture: What kinds of components to use, where it’s supposed to run, the kinds of state you manage, how data is represented. Architecture is deeper than “stack”—it’s about the way data flows through a system. A good decision can yield infinite flexibility; a bad one can yield endless pain.

A shocking number of architectural decisions are not purely technical, but come down to taste—because they drive the experience of the end product. For example, I could not get Claude to generate UX for my synths that made the least bit of sense until I completely stripped everything down to raw data, got rid of all styles and widgets, and started from pure JSON, then slowly built up a UX from the actual state of a “song” in the system, slider by slider. 

By doing that, I also have a version of a “song” that I could save and restore, and mechanisms for undo/redo. Yes, Claude helped me code all of that—but only after I took a huge step back and thought about where every single note and synth and sample came from, and how they would be represented. Once you lock in on your data flow, you’re off to the races. You can start to just tell the bot to extend the system, and because your architecture is the baseline, your confidence that it will do the right thing will go up, not down.

That’s the good news. The bad news is that this is still programming, even if it’s a lot faster. There were countless points over the past few weeks when I had to draw on 30 years of experience and a solid understanding of how data flows through audio systems in order to make progress. At one point, I read C++ code to understand how the Yamaha DX7 synthesizer packed its voice information into 156 byte arrays, an absolutely terrible thing to learn.

My argument isn’t that AI won’t be able to help with this stuff in the future. But AI is your general contractor, and you are the architect. Are you building a Burger King in Peoria or an art museum in Los Angeles? Both have extremely different goals about function, throughput, ingress, egress, and fire safety—it’s on you to make those decisions, because while AI can simulate intent, it doesn’t actually possess it.

Accountability. The little synths I’m making run only in the browser with no backend. They’re purely read-only. This is by choice: I don’t even have analytics or know who’s visiting. Pure GDPR compliance out of the box.

Most web applications, however, have a lot of data, often about individuals. To manage those apps, there are hosting companies like Vercel or even Amazon AWS, which used to promise simplicity over managing your own servers, but now are absolutely incomprehensible. 

I’m working on a different app on the side of this side project and wanted to host it, but after reading a bunch of hosting provider docs and getting cryptic error messages, I told Claude, “Here’s a server with root access. Start deploying everything there.” And my God, it did all the hateful stuff: Configuring the web server, setting up the https/SSL connections, just hours of the worst work being sent to work heaven. Paradise.

This is for a personal project, and I have total control, so it’s fine. But while I was doing it, I had a panic attack. Imagine a developer for your company doing this. Everything is set up and running and working. You, the boss, are so excited! You forget to ask about the long-term management of the project and where the keys will be kept. Obviously they used your existing system, right? 

Now they quit, and the server crashes two weeks later. How do you log into it? Where is it hosted? How is it managed? Who has root access? Where are the backups? AI won’t help you now. You’re screwed.

It’s about to become very, very easy to circumvent all kinds of systems and processes in the interest of ease, to just skip a bunch of steps and hack something together to make your boss happy, so you can get back to playing games on your phone. This has always been a profound danger and there are countless approaches to managing it, but there’s also just a natural amount of friction built into coding and deploying, and everyone tends to follow the rules because other kinds of friction are worse. These stakes will get a lot higher—as will the stakes around privacy, accessibility, and all kinds of compliance, because it’s going to be so easy to do a half-assed job and call it a day. Accountability!

Anyway, I’ve got a ton to do on my DAW, but plenty of time to do it. It’s a good learning project, and I finally have a solid understanding of some of the uglier corners of the web platform, things like WebAssembly, WASI, and the AudioWorklets. It’s ironic, but I’ve learned more about web coding in the last two months than in the last five years. When I’m done with my project, I’ll either keep it around or throw it away.

I would point out though, when I looked at my GitHub logs, it wasn’t a one-shot project. I’ve taken 1,000 turns to get it to this state. How many turns remain? Another thousand? Twenty times that? I don’t know. My guess is I’ll never be done. That’s just how this goes.