This Is Not Autocomplete

A month ago, I wrote about my “I Know Kung Fu” moment — the first rush of building real software with Claude Code after two decades away from programming. I expected the novelty to wear off. Instead, it accelerated. Since that post, I’ve shipped MBOMail — a native macOS app for mailbox.org, written in Swift, published and downloadable — built Voxtral Memos for iOS (now in beta), submitted a Raycast extension called Bluepost for review, and started FreeReps, a self-hosted server that ingests Apple Health data, visualizes it with configurable correlations, and doubles as an MCP server for LLMs. All documented, all open source, all real.

This isn’t a honeymoon phase. It’s a different way of working, and I want to talk about what I’ve learned — both about the tools and about the reactions they provoke.

The Experience of Building

What strikes me most, a couple of months in, is how sustainable the energy is. I’ve spent 25 years in IT — SAP consulting, management, architecture — where I planned and mostly delegated the building to others. Having the ability to go from an idea to running software myself again, in days rather than months, has reconnected me with something I thought I’d left behind. Every idea can become a real thing now. Not a spec, not a ticket — something people can download and use.

That sounds like hype, and I’m aware of it. But I’m a 52-year-old computer scientist, not a fresh convert looking for a movement to join. I’ve been around long enough to know the difference between genuine capability and marketing noise. And what I’m experiencing is genuine.

There Is Something Here

I want to be precise about this: there is something here, and it is more than a better autocomplete for code.

I know the criticisms. The models hallucinate. The code isn’t always clean. They lack true understanding. Some of this is fair. But none of it captures what it actually means to sit down with an idea in the morning and have working, documented software by the evening. The gap between the criticism and the lived experience is enormous, and I think most of the critics haven’t done the work of closing it.

The people who dismiss this wholesale are not describing the experience of building with these tools. They’re describing their assumptions about it. And assumptions, however well-reasoned, are not a substitute for doing the thing.

What I’m Not Claiming

I should be clear about the limits. I’m not building enterprise systems in a chat window. I spent enough years inside large software organizations to know what a million lines of legacy code feel like, how systems grow in ways nobody intended, and why well-meaning rewrites fail. The tools I’m using are not going to replace that kind of engineering — not today.

What they do is make a different kind of building possible: personal tools, utilities, applications that solve a specific problem well. The scope is real but bounded, and I have no interest in pretending otherwise. That said, I believe the boundary is moving, and faster than the skeptics expect. Even in the world of complex systems, AI-assisted development is contributing more than most people realize, and that contribution is growing.

The Hostility

The part I wasn’t prepared for is the contempt. Mention on Reddit that something was built with AI assistance, and the response is immediate and predictable: vibe-coded garbage, LLM slop, not real software. It doesn’t matter what you built or how well it works. It doesn’t matter that you’re giving it away for free. The verdict arrives before anyone looks at the result.

I understand the fear behind this. If your craft is software development, watching the barrier to entry drop overnight is threatening. That anxiety is legitimate, and I don’t dismiss it. But there’s a difference between healthy skepticism and reflexive contempt — and what I see online is mostly the latter. Someone builds something, documents it, open-sources it, and the reward is derision. That’s not a community protecting its standards. That’s people lashing out.

What makes it worse is that the loudest voices almost never come from people who have actually tried building something this way. They’ve read about it, seen bad examples, and formed a position. But they haven’t sat down with a real problem and worked through it. Their criticism is theoretical, and on this particular topic, theory doesn’t hold up well against experience.

A Pragmatic View

I’m not asking anyone to be enthusiastic. I’m asking them to be empirical. Try the tools before judging them. Build something real — not a toy demo, but something you’d actually use — and then form your opinion. If you still think it’s worthless after that, fair enough. But most people who go through that exercise come out the other side with a different view.

The broader reality is straightforward: the share of code written with AI involvement is going up, across open source, startups, and enterprises. It’s not a question of whether this becomes normal — it’s a question of when. Categorically refusing to use AI-assisted software will, before long, mean refusing to use most software. That’s not a prediction I’m excited about or worried about. It’s just where things are heading.