I just released a new open source tool called Clapper. It lets you generate videos by writing React code. It is not unique; other software tools like it exist. I built it anyway.
I developed a pretty bad habit since coding assistants have gotten to be so good. Instead of finding existing tools or open source software and reusing it, I just build whatever I need, from scratch.
Why do I do this? Well, there are a few reasons:
I can. I’ve been in the industry long enough that I have a pretty good idea of how to build most types of software and with agents there’s basically no barrier to doing so.
It’s useful. Whenever I reach for a tool, it’s because I have a particular problem. When I build my own piece of software to solve that problem, it’s useful. I now can solve this problem. Maybe I can solve adjacent problems and maybe other people have the same problem and will find my software useful.
It’s fun. Now what does fun mean? Well if you read the book Theory of Fun, fun = learning and I definitely learn a lot by building things. It’s also just really interesting to see what you can create and how it works.
It’s personal. I can make the software exactly how I want it. If I want a particular feature I can add it. If I don’t want a particular feature I don’t need to add it. As I use it, I can evolve it very quickly. Having total control of the software is extremely useful.
Now there are plenty of arguments that even with amazing coding assistants, this is a bad thing to do. Let’s go through a few:
Maintenance. Now you have to maintain all this software.
Focus. Doesn’t this take away your focus from other things you should be doing?
Hubris. Do you really think you can build better software than people who have dedicated years to focusing on particular domain or type of application?
Triviality. Does the software matter if it can be built so easily?
Let’s discuss these one by one.
Maintenance
Maintenance is mostly solved with coding agents. It is fairly straightforward, either locally or on a server, to hook up a loop, look for GitHub issues, and for each GitHub issue spawn a sandbox, go address the issue, and merge it. Test suites help keep this process on track and ensure their are no regressions. You could even have your local coding agent build a workflow to do this for you with cron.
Also, this workflow really only matters when you make your software public. If the software is only ever for you, there’s not much difference between maintenance and just evolving it to work better for whatever use case you start it with. It has the same overhead as writing the software in the first place.
Focus
Don’t you have a day job? Don’t you need to spend more of your time focused on your day job?
The thing with coding assistants is that, for side projects and for tools where you don’t really care about reading the code (provided it works for your particular use case and you can write a good test suite or set of evals to understand how well it works), the overall cognitive overhead is extremely low.
Maybe you spend 10 minutes typing up your problem, some high-level solution direction, and an example issue you want to solve. You then let the coding assistant go to town and direct it to work until it can actually solve that particular problem.
You can then give it adjacent problems or even ask it to generate adjacent samples and make sure it works on those as well. Some would call this loop engineering. The agent creates its own focus.
Hubris
What makes me think I can write any software I want and that it will be better than folks who have worked on that type of software for many years?
Well I don’t think my software will be better than theirs. They’re solving a much larger set of problems in that particular domain compared to me.
I do think that I’m much better suited to solve the problem that I have at hand than someone who’s built software to try to solve a much more generic view of that problem (and has to deal with things like the lowest common denominator of that problem).
And then let’s say I’m writing software in a domain I’m actually not an expert in. I would urge you to go back and look at my original reasoning. For this particular piece of software, doing it myself lets me learn that particular domain and makes it fun.
Triviality
There’s an argument that any software you can “vibe code” isn’t actually useful, is trivial, and doesn’t matter. I think that if the software doesn’t actually solve any problems, and you’re not building it for fun, and you’re just doing it to burn electricity, that’s probably the correct view.
But if the software solves a particular problem you have, then it matters. It’s not trivial, at least to you. Triviality is in the eye of the beholder.
If someone else has your same problem and they like your very simple, focused solution, then the software presumably isn’t trivial to them either.
So you see, most of the arguments that might have been completely valid before the era of coding assistants don’t really matter anymore.
I don’t really care if you think that my personal tool is useless. It was fun to build and it solved a problem. I can iterate it in whatever way I want. Over time it’ll become quite interesting. It might become complex in ways that are not really easy to vibe code.
In fact, this is how normal software is written before assistants: you start simple, you solve more problems and more problems and more problems, and you finally get something that is hard to replicate and does important jobs for people.
Limits
Now obviously, there are limits to this mindset. I haven’t vibe-coded my own operating system. When I need a database I use Postgres. I haven’t reinvented every distributed system out there just because I can.
No, there are certain problems in computer science where you really do want the system you adopt to be battle-tested and time-tested: operating systems, databases, distributed systems. These are the sorts of systems where you really do want that collective attention and wisdom, time spent hardening, to be the backbone of what you do.
The beauty of all this is that I could work on one of those things if I wanted to. I’d start simple, solve one narrow problem, and evolve it from there.
Ending Where We Started
If we return to Clapper and compare it against some alternatives out there, you can see where my opinion shows up.
I wanted Clapper to not just be a React to Video tool. I wanted it to be an opinionated DSL that makes video production as declarative as possible. It has many built in components for various animations, as well as a React DSL to fully compose music. My hypothesis is that by having a richer DSL rooted in video production, my agents will be able to more naturally produce really great looking scenes. I still need to prove this, but frankly, it doesn’t matter, because I built this tool for me.
And maybe, you’ll find it useful for you too. That’s the beauty of personal software.