Everyone’s got a “I built this with AI” story right now. Most of them are the same story: prompt goes in, code comes out, developer feels clever, post gets written. Mine’s a little different — and if you’ve been in this industry long enough to remember when “the cloud” was just someone else’s server, you might find it useful.
I’ve been a senior software engineer for over 20 years. I have a Master’s in Information Systems and a BA in Psychology. I build things at digibots.foo. I am not an AI evangelist, and I’m not here to sell you on anything.
What I built is digibots-rigged — a Cost of Living Explorer that combines official benchmark data with real crowd-sourced numbers so you can actually compare what it costs to live somewhere versus what the government and economists say it costs. Spoiler: those two numbers are often having completely different conversations.
Here’s what building it taught me.
The “AI Replaces Developers” Crowd Has Never Watched AI Work Unsupervised
Let me be blunt: the people confidently declaring that AI is going to replace software engineers have probably never sat down and tried to build something non-trivial with one.
I used Claude and Gemini. I used Claude exclusively for the project I’m referencing. They’re both capable. They can both write code that compiles, passes linting, and looks reasonable on first read. What they cannot do — at least not without you — is think like a systems engineer.
When I started on digibots-rigged, I didn’t just paste “build me a cost of living app” into a chat window and wait. I came in the way I come into any project: thinking about data models, infrastructure decisions, how data gets loaded, what the actions need to look like, how state flows through the application. I was architecting. The AI was implementing.
That distinction is everything.
Experience Changes What You Ask For
Here’s the thing I kept noticing: the quality of what I got back was directly tied to the quality of the context I gave. And the quality of my context came from 20+ years of knowing what questions to ask before you write a single line of code.
When I said “set up the data model to handle both official benchmark data and crowd-sourced submissions with provenance tracking,” I got something useful. When I just said “add a data layer,” I got generic boilerplate.
I was doing something that, I’d wager, most non-engineers building with AI aren’t doing: I was treating the AI like a capable junior developer. I gave it constraints. I pushed back when something felt architecturally wrong. I made infrastructure decisions it wasn’t qualified to make. I knew when its “solution” was going to create a maintenance headache six months from now, even if it worked today.
The AI didn’t know those things. I did.
Where It Actually Helped (A Lot)
I don’t want to spend this whole post dunking on the tools, because honestly they saved me real time in the right contexts.
The implementation of things I’d already designed in my head? Fast. Boilerplate that would’ve taken an hour of typing? Done in minutes. Catching syntax errors and suggesting fixes in real time? Legitimately useful. Generating test cases for edge conditions I might have glossed over? Better than I expected.
The speed multiplier on execution is real. I’m not going to pretend otherwise.
But execution is downstream of design. And design is still a human job — at least for anything more complicated than a CRUD app with no opinions.
The Honest Comparison: Claude vs. Gemini
Both tools are good. Here’s my unvarnished take:
Claude tends to reason through problems more carefully before producing output. When I gave it architectural context, it held onto that context better across a session and pushed back in ways that were actually useful — not sycophantic “great idea!” responses, but genuine “here’s a potential issue with that approach” feedback. For a project where I was making real design decisions, that mattered.
Gemini was faster in some respects and occasionally surprised me with code generation quality. But it had a tendency to confidently produce something that looked right and wasn’t, in ways that required me to actually read and understand the output — which, fine, you should always be doing that anyway. But it happened more often.
Neither one is a replacement for knowing what you’re doing. They’re both power tools. A power tool in the hands of someone who doesn’t know what they’re building is just a faster way to make a mess.
So What’s the Real Story Here?
The real story isn’t “AI is amazing” or “AI is overhyped.” The real story is more uncomfortable for both camps:
If you know what you’re doing, it multiplies your output. If you don’t, it multiplies your mistakes and buries them in confident-looking syntax.
For a senior engineer working solo on a project like digibots-rigged, it’s a genuinely useful collaborator. I shipped something real. It works. The data model is sound, the architecture is maintainable, and I didn’t cut any corners I’ll regret.
But I didn’t get there by turning the wheel over to the AI. I got there by knowing which parts of the wheel to hold onto.
I know the app isn’t “perfect.” I’ve already come across edge cases and errors that ultimately came down to, “attention to details.” I’ve already seen areas for improvement. You know what, that’s software engineering. Every app you create is a web of updates, added features and modifications.
One other thing I’ll add about digibots-rigged, because if you do go look, and use the Disposable Income Calculator, you’ll see a dead end. I’m still trying to decide what I’m going to do when you press “Share.” I’m open to reasonable suggestions.
What This Means If You’re Building Something
If you’re a developer with experience, stop apologizing for using these tools and start using them like a senior engineer would: give them context, push back on bad outputs, make the architectural decisions yourself, and treat their code as a first draft that needs review.
If you’re someone who doesn’t have that background and you’re building something with AI — I’m not saying don’t. But please, please have someone with engineering experience look at what it produced before you put it anywhere near production. The code it gives you looks more correct than it often is.
And if you’re one of the people writing hot takes about how AI is going to make developers obsolete: go build something with it first. Something with real requirements, real edge cases, and something you’ll actually have to maintain. Then come back and we’ll talk.
digibots-rigged is in beta here. Go poke around. And if you want to talk shop about building with AI, you know where to find me.