A Plugin I Probably Shouldn't Have Been Able to Build
Several months ago, I found myself annoyed by a very specific OBS problem. When I adjust audio levels programmatically, the change happens instantly. That is fine most of the time, but there are moments where I want music or another audio source to fade smoothly instead of jumping from one level to another. So, I decided to build a plugin for my Stream Deck, which is a physical interface consisting of buttons and dials to control applications like OBS on your computer.
 |
| My Stream Deck+ and Stream Deck XL |
This was also not my first attempt at this project. About a year ago, I tried to build something similar in C#, and it went nowhere. The problem was not that the idea was impossible. It was that there were too many unfamiliar pieces at once: plugin architecture, OBS integration via the WebSocket protocol, development tooling, packaging, and the usual pile of side-project friction that quietly kills momentum.
This time, using my personal ChatGPT account, I worked through the project conversationally. We designed the plugin, wrote code, debugged problems, refined behavior, and eventually got it working. That was surprising, not because AI can generate code, but because a project that had previously felt impractical suddenly became manageable.
The plugin itself is useful, and I'll continue using it. What interested me far more, however, was why this attempt succeeded when the previous one failed. On the surface, the project hadn't changed very much. The goal was the same. The problem was the same. What had changed was the process I used to get there.
Too Many Unknowns
The plugin itself was not particularly ambitious. At its core, it was just moving an OBS audio fader from one value to another over a period of time. If I had already known the relevant technologies, it probably would have been a weekend project...but I didn't know any of the relevant technologies.
The Stream Deck plugin architecture was new to me. OBS WebSockets were new to me. TypeScript was new to me. The IDE was new to me. (I was using Visual Studio Code while all of my prior development experience had been in Visual Studio Community Edition.) Even the build and packaging process was unfamiliar. None of those challenges are especially difficult in isolation, but software projects rarely present their obstacles one at a time.
What made my earlier C# attempt fail was not a lack of programming ability. It was context-switching overhead, meaning every question led to three more questions. Before I could solve the original problem, I had to understand plugin lifecycles, deployment models, WebSocket communication, OBS APIs, project structure, and a collection of tooling decisions that had nothing to do with smooth audio fades.
Anyone who has spent time building software has experienced this phenomenon. The implementation itself is often straightforward but acquiring enough context to implement it correctly is where most of the time goes. That was the real obstacle in my earlier attempt - not writing code but instead navigating unfamiliar territory without getting lost in it.
What AI Actually Changed
When I attempted this project a year earlier, progress was painfully linear. Every unfamiliar concept required its own research project. I'd read documentation, search forums, examine examples, test assumptions, discover I misunderstood something, and repeat the process. Each answer uncovered a new set of questions, and eventually the effort required to acquire context exceeded my motivation to continue.
This time, the workflow was fundamentally different. Instead of stopping whenever I encountered an unfamiliar technology, I could explore it conversationally. I could ask how a Stream Deck plugin was structured, how OBS WebSockets worked, why a particular approach was preferable to another, or how TypeScript differed from the JavaScript I remembered from years ago. More importantly, I could immediately follow up when something didn't make sense.
The result wasn't that I stopped learning. In many ways, I learned more than I would have through documentation alone. The difference was that the cost of exploration dropped dramatically. Questions that previously required thirty minutes or more of searching and reading could often be answered in a few minutes of conversation. When those answers were incomplete or wrong, I could challenge them, test them, and refine them without losing momentum.
That last point is important because I don't want to create the impression that ChatGPT simply built the plugin while I watched. The model was useful, but it wasn't infallible. Some suggestions were better than others. Some approaches needed refinement. Some ideas looked reasonable until they were tested against reality. The value came from the interaction, not blind acceptance of whatever appeared in the chat window.
In other words, ChatGPT made it easier to explore possibilities, evaluate approaches, and move through unfamiliar territory, but it didn't eliminate the need for judgment. If anything, my responsibility increased because I was able to consider more options in less time. The role shifted from generating every answer myself to evaluating, steering, and refining the answers being generated.
That changed how I thought about the project. The interesting part wasn't that ChatGPT helped me build a Stream Deck plugin. What stood out was how incidental the code itself seemed to the process, i.e. success was ultimately determined not by my ability to write TypeScript or understand OBS WebSockets. It was my ability to explore an unfamiliar problem space, evaluate alternatives, and gradually converge on a solution. AI accelerated that process, but it didn't replace it.
The Bigger Realization
That observation connected directly to a theme I've explored in earlier posts. In both We're Asking AI the Wrong Questions and AI Raises the Bar, It Doesn't Remove Builders, I argued that AI is shifting the nature of work rather than eliminating the need for people. This project gave me a chance to test that idea against reality.
AI clearly made me more productive. A project that had previously stalled became achievable, and I reached a working solution far more quickly than I would have on my own. What surprised me was where the value actually came from. The code obviously mattered, but it wasn't the scarce resource in the process. I still needed to decide which ideas were worth pursuing, which suggestions made sense, which tradeoffs were acceptable, and whether the resulting behavior actually solved the problem I was trying to solve.
Around the same time, I came across a post on X claiming that anyone could fork one of the most popular open-source projects on GitHub, build on top of it, and essentially print money. I found that argument completely backwards because my experience suggested the opposite. Building software is becoming easier. Prototyping is becoming easier. Learning unfamiliar technologies is becoming easier. Those barriers are still real, but they are lower than they have ever been.
What isn't becoming easier is everything that happens after the software exists: customers still have to be found; trust still has to be earned; and products still need positioning, support, documentation, marketing, distribution, and ongoing improvement. Those are the activities that turn software into a business. Source code, by itself, does not.
AI wasn't making software more valuable. It was making software less scarce. When something becomes easier to create, it naturally becomes more abundant. And when that happens, the value shifts elsewhere, which is why the lesson from this project isn't that AI can build software. Instead, it is that software itself is becoming less of a differentiator. The real differentiators are increasingly the things that AI cannot yet do on your behalf: exercising judgment, understanding customers, identifying opportunities, building relationships, and executing consistently over time.
What Happens When Software Stops Being the Bottleneck
If software is becoming less of a differentiator, then the implications extend far beyond hobby projects and Stream Deck plugins. For decades, software development was constrained by implementation. Having an idea was one thing but turning that idea into working software was something else entirely. The technical barriers created a natural separation between people who could imagine solutions and people who could build them.
AI is changing that equation. The ability to implement ideas is becoming more accessible, more efficient, and less scarce than it has ever been. That doesn't mean software engineering is disappearing any more than spreadsheets eliminated accountants. It does mean the bottleneck is moving, however. My plugin was a small example of that shift.
 |
| My Stream Deck plugin |
It also reminds me of an old observation that success often happens when preparation meets opportunity. The opportunity in this case was AI-assisted development. The preparation was decades spent learning how software systems behave, how to evaluate tradeoffs, how to debug problems, and how to recognize when something isn't working. Neither one would have been enough on its own.
That's why I don't see AI as a replacement for builders. I see it as a force multiplier for them. The people who benefit most won't necessarily be the ones generating the most code. They'll be the ones who can combine judgment, experience, curiosity, and domain knowledge with tools that dramatically reduce the effort required to turn ideas into working software.
The plugin works, and I'm happy to have it. But the plugin isn't what I learned from this experience. What I learned is that software is becoming easier to create, and that makes everything around the software matter even more.