How I Actually Use AI

Direct answer: the right question about AI isn't "do you use it?" anymore — most of the industry is past that one. The right question is: when a model tells you something wrong with the exact same confidence it would use for something right, do you notice before or after it becomes a real problem? The whole difference lives there, and it's more a discipline than a tool.

TL;DR

• Using AI isn't a binary question anymore (yes/no): almost everyone does. The question that matters is where you trust it and where you verify.
• AI is excellent at speeding up drafts, repetitive code, initial exploration. It's weaker exactly where judgment matters most — that's where I deliberately slow down.
• I don't fix a bug just "because the explanation sounds plausible": I try to reproduce it for real, before fixing it, as often as I can.
• I check the primary source, when I can, instead of the summary someone (human or model) made of it — for code, for logs, for data.
• There's a category of things I never hand to a model, no matter how good it is: anything that, if I trust it wrongly, can't be undone.

The question that gets thirty seconds

"How do you use AI in your work?" has become a ritual question. You hear it in interviews, on client calls, in the meetings where somebody has to decide how much to invest in it. And it almost always gets the same thirty-second answer — mine included: I use it to move faster, I stay critical. That is a slogan, not a description.

The trouble with the slogan is that it contains nothing you can check. It does not say what you actually use it for, where you stop trusting it, what changes in the work when producing costs almost nothing. Here I am trying to write the long version: the one an hour never leaves room for, and the only one useful to somebody deciding how to use it in a company.

The question isn't "whether" I use AI, it's "where" I trust it

Trust isn't an on/off switch — it's a decision I make case by case, and the rule behind it is simple to state and a bit harder to always follow: the easier a decision is to undo, the more willing I am to delegate it without checking right away. The costlier it is to undo, the more I try to verify it first, not after.

A first draft of a function, a first pass at a query, the shape of a test: cheap to get wrong, I reread and fix them in seconds, so AI saves me a lot of time there and I let it move fast. A design decision I'll live with for months, a claim about how some library or external system actually behaves, anything touching data or sensitive access: there I deliberately slow down, because the cost of finding out later is usually higher than the time I'd have saved by trusting it upfront.

The discipline that matters most: try to reproduce before you fix

If a model offers a plausible explanation for a bug — and it almost always offers one, with the same confident tone it would use for the correct one — the question I ask myself isn't "does this make sense?" but "did I actually see this happen, or am I trusting a well-told story?" Before touching a line of code to fix something, I try to reproduce the problem for real: make it happen again, under controlled conditions, and only then fix it. Not because I distrust it in general — but because a plausible explanation and a true one often look the same when told by someone convincing, human or AI. The only reliable way to tell them apart, when it matters, is to go and look.

The same discipline runs the other way: when I find a mistake rereading my own code — which I try to always do, even on code that "worked on the first try" — I try not to trust my own first impression of what caused it either. I reproduce it, isolate it, and only then write the fix. It's slower than "looks like the problem is here, fix it and move on." But it's one of the more real differences between code that works and code you know works.

Checking the source, not the summary

A model describing how some library, API, or system you didn't write behaves is giving you — at best — an accurate summary of what it saw elsewhere. A summary, however accurate, isn't the source. When a decision hinges on "does this actually behave that way?", I try to go look at the primary source: the real code, the real response from a real system, the real log of a real execution — instead of a third-hand description of how it's supposed to behave.

This isn't skepticism aimed at AI specifically: it's roughly the same principle I'd apply to a brilliant colleague telling me "that library works like this" from memory. Brilliant doesn't mean infallible, and memory — theirs, mine, or a model's statistical version of it — is often the wrong place to let a fact live when it's thirty seconds away from being verified.

What I never delegate, no matter how good the model is

There's a category of things where "verify if it matters" isn't enough, because even a single mistake is already too many: anything touching access to data or systems — keys, credentials, anything that, if it ends up in the wrong place even once, can't be treated as if it never happened. There I don't delegate the decision, and I don't delegate the check either: I do it by hand, every time, without many exceptions for being in a hurry. It's not paranoia — it's mostly recognizing which mistakes are reversible and which aren't, and treating them differently as a result.

The question that actually matters

Almost anyone can answer "yes, I use AI, it saves me time" by now — on its own, that's not much of a signal anymore, because it's true for almost everyone. The more interesting signal is what happens in the exact moment the model is confidently wrong: is your way of working set up to catch that mistake before it costs something, or only after? I don't have a permanent answer to that — I have a habit I try to honor every time, one that sometimes slows me down on purpose exactly when it would be more convenient not to. That, more than any tool, is the answer an hour-long interview has never had time to let me give in full.

FAQ

What's the most common mistake people make when they delegate too much to AI?

Treating the confidence with which a model answers as a signal of correctness. It isn't: a model can be equally confident when it's right and when it's wrong. The most reliable way to tell the two apart is still to verify, not to listen to the tone of the answer.

How do you decide what to verify without losing all the time you gained?

By looking at how costly the mistake is to undo, not how likely it seems that the AI is right. If getting it wrong costs a two-minute rollback, you can move fast. If getting it wrong costs a week, or a piece of data you can't get back, better to verify first, almost always.

Doesn't reproducing a bug before fixing it waste time compared to "just fix it and move on"?

In the short term, yes, a few extra minutes. But it helps avoid the category of fixes that appear to work while hiding the real problem one level deeper — those, when they resurface, cost far more time, usually at the worst possible moment.

---

If your company is trying to figure out how to use AI in a way that genuinely speeds up work without quietly moving the risk somewhere nobody's watching, it's one of the things I work on as a Fractional CTO: let's talk.