AI Is an Eager Puppy. Keep It on a Leash.

I have been building software for over 20 years, and I have seen a lot of approaches to building good products. Some held up. Others turned into vaporware within months or years.

I was one of the eager developers who jumped on the Silverlight and WPF wagon. I became a Microsoft MVP for Silverlight and then for WPF, and neither became mainstream. Silverlight went the way of Flash, and it wasn’t pretty. Several clients had followed my blog and my lead on what to use, and when Silverlight died, they — and I — were left holding the bag.

That’s when I made myself a promise: I would never again bet a recommendation, or a product, on a single company’s solution. It has been sound guidance ever since. I keep my dependencies few, and I don’t rely on third parties I don’t know and trust.

A new wagon to jump on

We’re now in an era of AI trying to do everything for you. If you’re a senior developer and you’ve looked closely at the code or projects an AI produces, I think you’ll agree: our future is sound.

There is no governance, no security, no architecture, no coding standards or linting rules — unless you put them there. You can write rules and you can try to train it, but the moment it compacts its memory or you start a new session, it may gloss over your guidance and reinvent the wheel. Worse, it will happily strip out your security and embed keys and API secrets directly in the code, ignoring your company’s policies.

That scares me. I have a lot of friends who are happily “trying” to build production-ready software without really knowing what’s under the hood.

I use AI every day — and I review everything

Don’t get me wrong: I use AI every day. I’ve settled on Claude Code, and we have our good days and our bad. But if you aren’t constantly reviewing what it generates, you are going to get burned, and it won’t be pretty.

Here’s a recent example. I’ve been using Opus 5.5 across several projects and Git repositories, and I wanted to audit and shore up their security. The request was flagged, and I had to switch back to Opus 4.8 to continue. The wording suggested I might be trying to harm Claude itself. I wasn’t anywhere near Claude — I was auditing my own code. Tools have guard rails too, and sometimes they fire in the wrong place; you have to understand enough to work around them safely.

I’m so cautious that I never let the AI commit or push code. I want to fully understand what it produced before anything gets anywhere near production.

Who gets hurt

This is why I worry about non-developers: creators, designers and even junior developers who have never written a line of code, or never felt the pain of fixing bugs across multiple paradigms. They can’t tell when the AI is confidently wrong — and that’s exactly where people get hurt.

I would never give it free rein over my personal data or accounts. It is still far too brittle.

A puppy that just saw a squirrel

The way I think about AI: it’s a puppy that wants to please its owner. It learns tricks remarkably fast. But the moment it sees a squirrel, you’re in for a world of trouble — especially if it isn’t on a leash.

I enjoy working with AI. I really do. And there are moments every day when I’m furious with what it generates. Both are true.

Guard rails, not good intentions

So what’s my point? Will AI get better? Yes, absolutely. Will it replace senior developers? Absolutely not.

What I’ve found is that AI works far better when the platform it’s working in uses domain-specific languages (DSLs). A DSL is a small, focused language for one job — describing a data schema, a screen, a printed layout. Because the language is small and the platform validates it, the AI can’t wander off into a detour that costs you hours. Anything outside the rules is simply refused.

I’ve gone as far as building my own DSLs across several domains, so I keep the speed and time to market without side-stepping the governance and policies my clients (and I) have already agreed to. For example, in Webend Creator a data schema is written in LiteSpec:

model Invoice object {
  customer_id: string @required
  amount: number @required
  status: string @enum(draft,sent,paid)
  due_date: string @format(date-time)
}

The AI can draft that in seconds. But every save is compiled on the server. If the AI gets creative — say it invents a money type that doesn’t exist — the save is refused with an exact, line-numbered error:

LiteSpec line 3: unknown type 'money' for field 'amount'

The AI reads the error and fixes it, and nothing invalid ever reaches production. The same idea runs through our page layouts and printed publications: the AI writes in a language the platform understands and checks, instead of inventing whatever it likes.

That approach has made a big difference for me, and I believe it will only get better.

You are the driver

So where do we go from here? We keep developing. We keep asking the bigger questions. And we challenge the AI when it flat-out lies to us with one hundred percent confidence — it does this a lot, and that isn’t going to change.

You’re the domain expert. You’re in charge. You’re the orchestrator. You guide the ship through perilous waters. The good news: you’ve done this before, and you can do it again. Just make sure your eager helper is working with you, not against you. There’s no fun in rowing upstream without a paddle while the motor pushes you toward the falls.

AI is here to stay, and I welcome it — with caution and circumspection. These are exciting times, and we can build some really cool products. Just don’t hand the AI the keys and let it drive. You earned your license, and you read the road far better than any AI can. It will try to reassure you and exude confidence, but challenge it with a simple question and it folds to your hard-earned experience and wisdom.

If you’re just getting started building with AI, my nine rules for vibe coding are a good place to begin.