"I use AI daily" is a claim that means almost nothing on its own — it reads as noise, because it could describe someone pasting error messages into a chat window or someone running a genuinely disciplined workflow. The difference isn't the tool. It's what you do with what it gives you. This is the specific version, from a recent six-week greenfield Kubernetes platform build, where it helped, and — more importantly — the specific times I had to catch it being wrong.
Where It Genuinely Changed the Work
Codebase archaeology. Several unfamiliar repositories, an undocumented authentication flow, a legacy configuration file carrying three environment tiers of accumulated decisions. I used AI to read broadly and fast across all of it, then verified every load-bearing claim against source or a real command before acting on it. That combination — fast breadth, verified depth — compressed what would normally be days of orientation into hours.
Evidence analysis at scale. The browser session capture from the authentication bug I've written about separately was roughly 90 requests in a 2.7MB file. Correlating across the whole thing — rather than opening requests one at a time by hand — is exactly the kind of bulk pattern-matching AI is good at, with the human still doing the actual interpretation of what the pattern meant.
Hypothesis generation with cheap disproof. The value here wasn't being handed an answer — it was generating candidate explanations quickly and, just as importantly, designing a fast, cheap way to test each one. Wrong theories got eliminated in minutes instead of hours, because the test for "is this even plausible" was cheap to run.
Where I Had to Override It
This is the honest half, and the half that actually matters if you want to understand what "using AI responsibly" looks like in practice, not in the abstract.
- Deployment configuration in the wrong repository. It placed delivery configuration inside the application repository, violating the separation between application code and how it gets deployed. Caught in review, moved to where it belonged.
- A signing keypair that would have broken authentication. It proposed generating a fresh signing keypair for a new environment during the identity-provider containerization work. That would have broken login — for a reason only visible by comparing a committed certificate against a configuration value, byte for byte. I checked before applying it. Plan changed.
- Deployment values written against an imagined chart interface. It wrote configuration against what a Helm chart's interface probably looked like, rather than what it actually was. Reading the real chart showed several assumed options didn't exist, and one directly contradicted how the chart actually delivers configuration.
- A container size comparison that wasn't actually comparable. It reported an image size pulled from a local tool without noting that figure was inflated by the local image store's own overhead — not an apples-to-apples comparison against the registry size it was being measured against. Corrected once I pushed on where the number came from.
- A branch recommendation based on convention, not verification. It suggested branching from an existing convention-named branch without first checking whether that branch had anything actually useful in it. It didn't — and it carried a pipeline pointed at a stale code path that would have quietly shipped the wrong thing.
The Practice, Not the Hype
I treat AI as a fast, well-read engineer with no accountability for the outcome. Excellent at breadth — reading widely across unfamiliar code, pattern-matching against things it's seen before, stating its reasoning clearly when asked. Confidently wrong in ways that look completely plausible, particularly about anything it hasn't actually read carefully. Both of those are true at once, and treating it as only the first one is where the expensive mistakes come from.
So the discipline is simple to state and easy to skip under deadline pressure: verify anything load-bearing by actually running it. Prefer a real command's output over an assertion, every time. Ask why, not just what — a wrong explanation is much easier to catch than wrong code that happens to look right. And keep the architectural decisions for yourself, because that's exactly where being confidently wrong costs the most.
A Concrete Example: Four Bugs, Found by Running Things
In this same engagement, local execution — actually running the thing, not just reading it — caught four defects that reading alone had missed entirely:
- A missing package meant a configuration directory silently didn't exist.
- An upstream test certificate had survived a cleanup step it should have been removed by.
- A volume mount silently resolved to the wrong filesystem when nested inside another container layer.
- A test assertion reported a false failure because the content it was checking arrived HTML-escaped, and the comparison never accounted for that.
None of the four were visible from inspection alone — reading the config, reading the test, reading the Dockerfile, all looked fine. All four were found in minutes once something actually ran and produced a real result to look at.
Takeaways
- "I use AI" is not a differentiator on its own — the discipline around verifying its output is, and that discipline is demonstrable in specifics, not adjectives.
- AI is strong at breadth and speed; it is not reliably strong at things it hasn't actually read, and it will state a wrong answer with the same confidence as a right one.
- Running the real thing catches classes of bugs that reading — by a human or a model — reliably misses. Prefer execution over inspection whenever it's cheap to do.
- Keep architectural and security-relevant decisions under direct human verification — that's where an overridden AI suggestion has the highest cost if it's wrong.