What experienced engineers decide that AI tools don't

“Why not just use AI to build it?” It's the first question almost every founder asks me now, and it's a fair one. AI can write code faster than any human alive. So why pay for an experienced engineer at all?

Here's the honest answer: AI writes code. It doesn't decide. After 22 years building startups across healthcare, security, the gig economy, and commercial contracts, I can tell you the value was never in the typing. The value is in the decisions. AI is leverage underneath the judgment — it is never the hero.

Let me make those decisions concrete, so you can see exactly what you're paying for.

Code is not unlike regular language: it is merely an expression. The idea still must be had; the words are just how you write it down. AI is very, very good at the words. It is not the one having the idea, and it never asks whether the idea is worth having.

I treat AI the way I'd treat a developer I'm coaching: fast, capable, eager — and in need of someone with opinions pointing it in the right direction. Those opinions are the product.

The first decision about how to build is critical. Even using AI, you still want to know the tools you're building with well, so you have an inherent understanding of how things are built.

The first thing I do setting up a project is provide AI guardrails. I'm choosing the tools, how they connect, how the infrastructure is set up, coordinating how logic flows — all from opinions gathered across two decades. If I let AI take me into unknown territory, my experience won't be as useful, and the result won't be as trustworthy.

And notice what that decision is not about. The technology that powers it, especially at the start, is inconsequential compared to the product decisions about the value you provide and the people you involve. We don't talk about tech or tools — we talk about behaviors, goals, incentives, outcomes.

Some shortcuts are fine. Getting working, functional prototypes is one of them. Before AI, iterating on real code took time, so experimenting was risky. AI made volume a non-issue, so what used to be a shortcut is now the way forward. That part is genuinely great.

But because it's so easy to build now, people hyper-focus on the happy path and forget the entire level of making an app not just work, but robust — the boring work: catching exceptions, the non-happy paths, error states, logging, making sure the app still provides value when things go wrong.

Because that work isn't direct value to the user, it's tempting to skip as “not important.” Deciding what to make durable now versus what to defer is a judgment call, and getting it wrong is the difference between a demo and a product. My mantra here is simple: make it work, make it good, then make it fast.

Not every decision is about how to build. Some are about whether to build at all.

I was once asked to build an app that would diagnose people from a list of symptoms, using a database and AI. Going back to my healthcare roots, I said no. While there's a chance of helping someone, there's a non-zero chance of getting it wrong and hurting someone — and in a world where people are desperate for answers, that's an unacceptable risk.

Not everything that can be done is worth doing.

Not everything that can be done is worth doing. We must always ask whether we're being responsible with the trust being placed in us. AI will never volunteer that question. It will happily build the dangerous thing, beautifully.

If left unchecked, AI will solve a problem from start to finish with a single procedural set of code, instead of looking at code as Lego blocks you can reuse. It tends to do everything as if the rest of the application doesn't exist.

One of the first hurdles is getting it to write code within the context of a framework, so it writes efficiently. That isn't a cosmetic preference. It's the difference between an app you can grow and maintain, and one that quietly becomes impossible to change.

This is where building with real understanding earns its keep. Building creates a deep understanding of, and trust in, your app. If you're not developing that understanding, you can never fully trust your app, and you're blind to its gaps. It matters not just to write well, but to deeply understand why your app does what it does, so it stays predictable.

Here's the through-line. Every one of those calls — what to build first, what to make durable, when to say no, how to structure it — is a decision, not a keystroke. AI doesn't make any of them. It executes them, fast, once someone has made them well.

Every industry I've worked in had needs that have little to do with the tools and everything to do with the products you choose to build. The technology is a reflection of your delivery effort to bring value and the risks you avoid. That's what experience buys you. The typing is the cheap part now.

If you want experienced judgment on your build — someone to make these decisions with you and turn your idea into a real, launchable product you actually own — that's what we do.