Building with AI, Carefully
If you ask me what I do, the honest answer fits in a sentence: I build software with AI, carefully. Both halves matter, and most of the loud opinions about AI and software come from people who’ve picked just one of them.
With AI
I use AI in my toolchain every working day. It drafts code, explores approaches, reads documentation faster than I can, and turns a week of work into something I can mostly see by the afternoon, often enough that pretending otherwise would be posturing. The economics are real. I bet a company on them, and they’re why a shop as small as mine can take on production work that used to need a team without pretending to be bigger than it is.
But the biggest lever isn’t typing speed. Where AI changes my work most is up front, in the planning and the thinking, before there’s a line of code to write. I can lay out a few different architectures and actually weigh them instead of committing to the first one that comes to mind. I can pressure-test a data model against edge cases I’d normally trip over months later, and walk through the ways a thing could fail while those are still cheap to fix. So it’s not only faster. What I end up with is usually more solid, and more capable, than what I’d have built alone under the same deadline.
So no, this isn’t a case against the machines. They’re useful. I’m a fan.
Carefully
The careful half is the one that takes discipline, because the tools won’t ask it of you. A few habits do most of the work.
A demo isn’t the product. A demo has to work once, for a couple of minutes, while someone’s watching. The product is what still works, and still makes sense to a person, six months later. AI is very good at the demo. Closing the distance between that and something a customer can run their business on is most of the actual job. I wrote more about why in the companion essay to this one.
Generated code is a first draft. It earns its way into production the same way any code does: review, tests, types, and changes small enough that I can actually reason about them.
A person owns the architecture. The tool works inside a structure someone has to be accountable for. The shape of the system, what talks to what, where the data lives, what happens when it fails: a person has to make those calls. On anything that matters, a real person decided it and stands behind it.
You should own what you paid for. I mean code and data and infrastructure that are actually yours, not something rented that can vanish the next time a vendor changes its pricing. That’s also why one of the three things I build is private AI that runs entirely on your own hardware, where you can ask questions of your own documents and records with nothing leaving your network. For some businesses that’s the difference between AI being usable and not.
How it all fits together
On paper I offer three things: custom software, AI solutions, and private AI on your own hardware. In practice it’s one idea. Software that does what it says it does, built with AI where it actually helps, checked before I trust it, and owned by the people who paid for it.
Arcana comes from the same place. I built it so that AI-generated code gets checked for correctness before it ever runs. I won’t claim a language fixes software, nothing fixes software, but it’s the same safety-first habit, taken seriously enough to write down as an open, public spec anyone can read.
And there’s a longer game behind all of it. I’m building Elemental Sites, a platform meant to give small businesses real software they own, and Arcana exists because that platform needs it. It hasn’t launched yet. Client work is how a bootstrapped company pays for that road, and I like the arrangement, because every project keeps me sharp at the same thing the platform has to be good at, which is shipping software people can actually rely on.
That’s the shop. If that’s the kind of building you want done, here’s how to work with me.