There’s an old story about Richard Stallman and a Xerox printer at MIT that I’ve been thinking about recently.
The printer kept jamming, and nobody knew until they walked over to collect their printouts. Stallman had previously modified the software of another printer to notify users when there was a paper jam, and wanted to do something similar with the new one.
But Xerox wouldn’t provide the source code, so he couldn’t make the change.
This was one of the experiences that helped shape Stallman’s thinking about free software.
The idea was pretty simple. If you use software, you should be able to understand how it works, modify it, and share those modifications. You shouldn’t have to depend entirely on the company that originally wrote it.
Later, Eric S. Raymond wrote The Cathedral and the Bazaar, which included one of my favorite observations about why people build software:
Every good work of software starts by scratching a developer’s personal itch.
I’ve always liked that aspect of open source.
If you have a piece of hardware and the manufacturer stops supporting it, you can maintain the driver yourself. If a program doesn’t quite work the way you need it to, you can modify it. You don’t have to convince a company that your particular problem affects enough customers to justify fixing it.
Of course, there was a catch.
Having the source code doesn’t mean you can change it
If you want to modify a Linux kernel driver, you better know C, understand how the kernel works, and probably have a reasonable understanding of the hardware you’re dealing with.
Even if you’re an experienced programmer, getting familiar with a large codebase just to fix something small might take days or weeks. Sometimes the problem simply isn’t worth that much of your time.
So while open source gave us the freedom to change things, actually doing so required a fair amount of technical knowledge.
I think AI coding agents are starting to change this in a pretty significant way.
A few months ago, I wrote about asking Codex to reverse engineer my Anker webcam.
I use Linux, and while the webcam works fine, Anker doesn’t provide Linux software to control settings like the camera’s Field of View. You need their Windows or macOS application for that.
So I asked Codex to figure it out and write me a Linux command-line tool.
About half an hour later, I had something that worked. Codex had downloaded Anker’s macOS application, reverse engineered the relevant parts, figured out how to communicate with the camera, and written the tool.
I didn’t have to spend days understanding the USB protocol or reverse engineering the application myself.
I just wanted to change the Field of View on my webcam.
The interesting thing is that this wasn’t even an open-source project. Anker’s software is proprietary. AI helped me figure out how the device worked and create my own tool to control it.
In a way, it reminded me of that old printer story.
What happens when everyone can start fixing things?
Most of the discussion around AI coding agents focuses on making programmers more productive.
And that’s certainly happening. I’m using these tools every day.
But I think there’s something else here that’s potentially even more interesting.
What happens when someone who doesn’t know how to write a device driver can still get one written? Or when someone who doesn’t really know how to program can modify an application they’ve been using for years?
You no longer need to understand an entire codebase before attempting a small change. You can ask an agent to explore it, explain how it works, make the change, and help you test it.
Of course, that doesn’t mean everything will work. You still need to test the results, and sometimes you’ll need someone who understands the system to figure out why things are failing. And AI doesn’t magically give you the legal right to modify or distribute proprietary software.
But it makes it possible for a lot more people to at least try.
Think about all the small annoyances you encounter in the software and hardware you use. A missing feature, an unsupported device, an application that almost does what you need, or an integration that nobody bothered to build.
How many of these things would people have fixed themselves if the technical barrier wasn’t so high?
And how much software are we going to see that exists simply because someone needed it?
Not a startup or a commercial product. Just a small piece of software that solves a specific problem for one person, and perhaps a few others who happen to have the same problem.
I think we’re going to see a lot more of that.
There’s one more thing, though.
If you’ve spent any meaningful amount of time working with coding agents, you know they don’t always get things right.
Sometimes they go down the wrong path. Sometimes they need to try several approaches. Sometimes you spend an hour on something only to realize you should have done it differently and start over.
That’s fine. That’s how experimentation works.
But when every attempt costs money in tokens, you start thinking about whether it’s worth continuing.
Should I let the agent try another approach? Should I spend another hour figuring this out? Is this little fix really worth what I’m going to pay for it?
And that’s a shame, because some of the more interesting things happen when you can afford to try something without knowing whether it will work.
This is one of the reasons we created LunaRoute.
We provide private AI inference capacity at a fixed cost, rather than charging for every token. There’s obviously a finite amount of computing capacity, but within that capacity you don’t have to worry about every request, retry, or failed experiment adding to your bill.
We want people to have the freedom to let an agent explore a problem, make mistakes, try different approaches, and keep going. Or just spend an afternoon working on something that might not be particularly important to anyone else.
We offer a 7-day free trial with no credit card required, so you can test all the models we have. Try it now.
I think removing that meter changes how you approach building things. You become more willing to try something that might not work, or spend the extra time making something work exactly the way you want it to.
And that brings me back to the original open-source idea.
For decades, we’ve had this notion that people should be able to change the software they use instead of being completely dependent on whoever wrote it. Open source gave us the code and the rights to do that, but the technical knowledge required was still a pretty significant barrier.
AI is starting to remove a lot of that barrier. It doesn’t replace the need for open source, and it doesn’t mean everyone suddenly becomes an expert programmer. But it gives many more people a practical way to do something that previously required a lot of specialized knowledge.
I find that pretty exciting.
And with LunaRoute, we’re trying to make sure the cost of experimenting doesn’t become the next barrier.
Because sometimes you just want your webcam to work properly on Linux.