So many projects are not attempted because of a lack of technical expertise, or a lack of design skills, or any number of other things that amount to a required investment of time, money, or other resources. This is an example of a moat, or barrier to entry, that companies claim keeps them safe from competition and keeps their customers (i.e. you and me) locked in.

I believe that AI agents, and in particular AI coding agents, erase a sizable chunk of the moats that big tech companies have. By lowering the cost of producing software, we'll build new software that we'd never have written before because it's so cheap.

We may be entering a future where the best app for your needs is something you prompted an AI agent to build. This is incredibly exciting if, like me, you want to move away from the monopolies of big tech. There's nothing more "small tech" than an app with a user count of 1.

🔗My First Agent

I kept hearing about agents. VS Code eagerly told me I could search my codebase by just describing what I wanted and some AI would find it for me. Was that an agent? I dunno, but it didn't really seem to work. Maybe all of this is just an overblown fad. I was skeptical, you might say. Not exactly a curmudgeon, but definitely keeping :old-man-yells-at-cloud: in my back pocket.

What finally got me to try out a proper agent was a small paper cut bug in my preferred editor at the time, Zed: generator functions were not included in the outline view for TypeScript/JavaScript files. I decided I'd write a fix for Zed in Zed using Zed's agent coding. Turtles all the way down! I could have fixed the issue by diving into a new-to-me codebase and doing a bunch of searches, reading a bunch of code, making some changes, figuring out how to build and test those changes, then doing a bunch more validation to ensure the fix was the right way to do it.

And I would have, if it were my job. I always started at a new company or a new work codebase by finding and fixing a small thing as a way to get my feet wet and gain some initial context on the project. However, I knew I wasn't going to do that here. The paper cut bug was too small to warrant spending what would likely be at least a couple hours on a project that I'm not paid for to complete all the steps above and create a pull request. That was time I could be spending doing other, more useful, work. Or just not working. Maybe reading a book, or relaxing with my kids. Whatever. So, I figured I'd kill two birds with one stone and try out Zed's agent coding features while also fixing the bug. I remember thinking it was a long shot that it'd actually work, but… it did. And pretty quickly, too. Granted, the actual fix was pretty small. But this was in July 2025 with a now-outdated model, which is essentially ancient history in AI timelines.

This experience planted the idea that maybe I could use these tools to take on other projects that I previously just didn't have time to do.

🔗A more ambitious project

I decided to try out a project I'd wanted to do for ages but never felt I could do in any sane amount of time before: porting zbar to Rust. zbar is one of the best open source barcode/QR code readers. It has a high success rate in detecting and decoding QR codes in my projects at work. But it's about 20K lines of C code, and so is all but guaranteed to contain some subtle memory safety bug. A Rust version with no unsafe code would be great to have.

My first commit to port zbar to Rust with Claude via Claude Code doing most of the coding was in the Fall of 2025. I did some initial work to ensure I had lots of good example images of barcodes to validate that there were no regressions. The rule was that no code would be accepted unless it passed all the tests, whether I wrote it or Claude wrote it. This may sound obvious if you're a software engineer, but it's an extremely important rule for safely working with AI agents. More on this later.

Together, we quickly made progress and I learned that Claude Sonnet is better than I am at porting C to Rust while preserving the behavior of the original. I kept taking stabs at doing it myself, especially when I hit my session or weekly token limits with Claude Code, but more often than not I'd mess up something subtle by trying to make the code be idiomatic Rust. I often had to revert my changes or ask Claude to come in and clean up my mess. And this was before Claude Opus 4.5 came out, which is what some mark as the point where Claude Code became better than many if not most professional software engineers.

Over the next couple of months, in my spare time, I directed Claude on how I wanted the porting project to go, finally reaching the milestone of no more C code. A little after that I removed the final blocker for release: use of unsafe Rust. I now had a pure safe Rust barcode reader with exactly the same success rate as zbar, and I called it zedbar. As a bonus, it was now trivial to run it in the browser or Node.js by building for WebAssembly (WASM).

Knowing what I know now and using the biggest and baddest Claude model, Opus 4.6, I bet I could do this port in a week given sufficient tokens.

🔗My own bespoke software

I have long been the sort of person who would build software just for myself, without any AI help. I started such a project years ago, and over a couple of trials and restarts ended up with a Svelte+SurrealDB app called Summer for tracking my personal finances. This was also initially written without the help of AI, but lately that's changed.

Just like with the projects mentioned above, there were features and improvements to Summer that I was just never going to get to. I could never carve out enough time to fully ramp up on the task and get it over the finish line. Several times I'd start one of these tasks, planning to land changes incrementally, only to come back to it weeks or months later to find a quarter-completed feature that I no longer had context on. I would just throw away the changes, because it never saved time to try to pick up where my broken work-in-progress left off.

Using Claude Code, though? Now I can get one of those features done in 30-60 minutes most of the time. For Summer, I do only a cursory look at the code. The stakes are just not that high. My job is a different story, but here it's fine if I push some code that works but is not amazing.

🔗Keeping agents grounded & safety tips

As mentioned earlier, AI agents must have guard rails and specific instructions. AI agents work so well for software development because they constantly get reality checked by their tools. The compilers and linters reject all sorts of bad code. The tests verify that the features work as expected. The benchmarks can catch a performance regression. It's harder to see how these reality checks might happen in many other fields, like law or medicine. Summer has a large and growing set of end-to-end tests that run the whole app in a browser, ensuring that the features the app is supposed to have actually work as advertised. This is why coding is one of the first domains where agents have become genuinely useful at scale, and I wouldn't want to tackle these sorts of projects without the grounding provided by these checks.

If you're interested in trying to build something with an AI agent, here is an incomplete list of guidelines for you to keep in mind:

  1. You must have automated tests to verify the code works as expected. Don't panic! The agents can write the tests, too. I suggest using Playwright for anything web-based. The tests are high-level enough that you should at least skim them to validate they're testing the thing you want them to.
  2. Be specific in your requirements, and have Claude interview you to fill in gaps. Sometimes Claude will ask questions proactively if your initial instructions leave details unclear, but you can also specifically ask it to interview you to help it create a detailed plan if you don't already know what to ask for.
  3. Use sandboxing to the extent possible. Don't grant Claude or any other agent free reign (looking at you, Moltbot). Use a virtual machine, or a Docker container, or a hosted web app builder like v0. Only give them access to data and accounts they really need access to. Maybe use entirely different accounts from your main/real ones to let them use instead (e.g. GitHub or Google).

🔗Go scratch your own itch

Not all moats are gone. Regulatory moats, for example, still exist. But for software? You probably rely on Facebook/Google/Apple/etc for some aspect of your digital life. Consider that their moats may be shrinking and you may be able to build your own thing even if you're not a software developer. Maybe that's a tool like Summer that is its own standalone thing, or maybe it's just a little helper tool that can be your bridge from Facebook or Twitter/X to Mastodon or Google Photos to Immich. Though there are risks with AI agents, I believe they're manageable. It's never been easier to step away from the tech giants, and I'm hopeful that this rising tide — in addition to lifting all boats —1 will drain the big tech moats too.

1 I used emdashes before the AIs did and I'm not about to stop now.