How I Actually Use AI: The Real Workflow Behind These Posts

Everyone has an opinion about AI. Far fewer will show you their actual desk — the tools they open, the things they refuse to delegate, the moment they stop trusting the output. I’ve written the essays about whether AI makes us sharper or softer. This is the other half: the mechanics. What I actually do, on a normal day, building and writing and thinking with these tools.

I’m not a developer. I’m an IT and infrastructure person who builds with AI. So this isn’t a senior engineer’s setup. It’s the workflow of a generalist who figured out how to take an idea all the way to a working thing — and who has gotten burned enough times to have rules.

The loop matters more than the model

People want a tool recommendation. They ask which model, which app, which subscription. That’s the wrong question first.

The thing that actually does the work is a loop: describe what I want, look at what came back, correct it. Tight and fast, over and over. When that loop is fast, I stay engaged for hours and the output gets good. When it’s slow — when I’m waiting on a giant response I then have to read like a stranger’s code — it falls apart. So the first thing I optimize is the speed of that loop, not the brand on the box.

This is also why I don’t get religious about models. They change every few months, and the one that’s best at coding today might not be the one that’s best at arguing with me about a design decision. What stays constant is the loop and my role in it: I’m the one deciding whether the last turn was right before we take the next one.

What I reach for, and when

The honest tool list, and the job each one actually wins at.

Claude Code, for building. Anything that touches a real project — this site, the journaling app, the publishing scripts — happens in Claude Code, Anthropic’s agentic coding tool. The difference between this and pasting code into a chat window is the difference between a pair programmer and a help desk. It has the actual project in front of it. It can read the files, run the build, see the error. I can ask “why does this deadlock instead of erroring” with the real code visible, and the answer builds a mental model instead of just patching the symptom. That continuity is the whole game. The first version of my journal app was built in a chat window with text files, and I burned it down partly because I kept losing the thread between sessions.

The lab it reaches into. A lot of my work isn’t on my laptop at all. I keep a small homelab — virtualized pentest and test machines I can get to from anywhere over Tailscale, so my dev box, my test box, and whatever I’m poking at this week sit one flat network away no matter where I’m working from. Wired up that way, Claude Code isn’t limited to editing files in front of me; it can sometimes drive those machines directly — SSH in, run the scan, kick off the test, read back what actually happened on a box that isn’t the one I’m typing on. That’s the point where “pair programmer” stops being a figure of speech. It’s working in the real environment instead of reasoning about a description of one.

A structured harness on top of it. Partway through building MoodHaven I started using gstack — a set of workflow skills built by Gary Tan that plug into Claude Code and march it through a real process: planning, engineering review, design review, QA, shipping. The difference between “review this” and invoking a review skill is the difference between whatever the model felt like returning and a structured pass that asks the right questions in the right order. AI plus structure beats AI alone, reliably, and it’s most of why my later work is cleaner than my early work.

A local model for the private stuff. In the journal app, the optional prose cleanup runs through Ollama if it’s installed — a language model running entirely on the machine, nothing leaving the device. When the data is private by design, the AI has to respect that too. There’s a version of “AI-assisted” that quietly ships your data to someone else’s server, and for a privacy-first app that’s a contradiction, not a feature.

Plain web search, still, for quick facts. This is the one people are surprised by. If my question is a single fact — a version number, a date, who said a thing — I use a search engine, not a chatbot. Search gives me multiple sources, a sense of who’s saying what, and the friction of having to judge. A chatbot gives me one confident paragraph with the seams sanded off, and confident is exactly the failure mode I’m trying to avoid on a fact. I save AI for the things I’ll work with over many turns. That’s where it earns its keep and where I stay engaged instead of switching my brain off.

Writing — but on a short leash. AI helps me draft and restructure, never finish. I’ve learned its tells, and the worst thing I can do is let it “improve” my words, because what comes back is smoother and emptier and not mine. When I migrated this site off Wix, one of the most important steps wasn’t building anything — it was reading every old post again to cut the AI-slop and the small fabrications that creep in when a model polishes your sentences. The voice has to stay mine. I’d rather publish something a little rougher and true than something frictionless that any of ten thousand other people could have generated.

A thinking partner, for the non-code stuff. This is the use I’d least expected to rely on. For a charged interpersonal situation, or untangling a half-formed idea, AI is a genuinely good mirror — it gives me a different frame to think the thing through. I have plenty of emotional read on those situations; what I’m short on is the structured mental version, and that’s what it hands me. It doesn’t decide. It gives me another angle, and I take it or leave it.

Decomposition is the actual skill

Here’s the part nobody puts on a feature page: the bottleneck in building with AI is not the AI. It’s whether you can break the problem down well enough that it can help.

When Claude asks “how do you want this to work?”, you need an answer. You can’t hand-wave it. Working on a long project is a constant exercise in decomposition — break it down, decide what matters, throw out what doesn’t, sequence the steps, drive it to done. You’re not outsourcing the thinking. You’re doing more of it, faster, with a partner that forces you to be explicit.

The site rebuild is a clean example. Before I wrote a line, I knew the shape: owned, fast, boring in the right ways. Owned meant everything lives in a git repository I control. Fast meant a static site. Boring meant a well-trodden, free-at-my-scale stack, which pointed at Astro and Cloudflare Pages. I didn’t have Astro memorized. I didn’t need to. I needed to know what I wanted and recognize a good answer when I saw one. The AI brought the framework details; I brought the constraints and the decisions.

The journal app went deeper, because it forced me to form opinions before I could ask for anything. You cannot vibe-code a sync engine if you don’t have a position on what sync should guarantee. I had to understand why a device-to-device design fit a zero-knowledge model and a cloud relay didn’t — well enough to reason about it, not well enough to implement it from scratch — and that took about four “why” questions in a row. That’s the right pace. The understanding wasn’t a bonus on the side of the building. It was the prerequisite for describing what I wanted clearly enough to get it.

The guardrails I don’t break

This is the operating manual, made concrete. Each of these exists because I got burned without it.

Make it disagree with me. Left alone, these tools validate a bad idea as cheerfully as a good one, so I ask for the friction on purpose: “argue the other side,” “where is this reasoning weak,” “give me the version a critic would write.” You have to request the sparring partner every time — it won’t volunteer that you’re wrong. Why a yes-man is genuinely dangerous, and not just annoying, is its own post: When the Machine Always Agrees.

Verify anything load-bearing. AI is confidently wrong often enough that any fact, number, or quote that matters gets checked against a real source before it ships. The optimistic essay I wrote is the proof of this one: AI helped me gather the studies, and then I verified every single claim against its primary source and linked them so anyone can check my work. The research-gathering is the cheap part. The verification is the part I don’t skip.

Understand as much as I can before it ships. I won’t pretend I understand everything that goes into what I build — there’s plenty I don’t, and I’d be lying if I said otherwise. What I do is work to close the gap: I follow the transcript with Claude instead of just accepting the diff, look things up when a term goes by that I don’t know, and ask “why” until the answer sticks. That recursive back-and-forth is how I actually learn — it’s why I now know what a Mutex is, what a wire protocol does, what a Cargo feature flag is for, none of which I set out to learn. I get a little better every time, and the goal is to understand more of each thing than I did on the last pass — not to refuse to move until I understand all of it.

A draft-to-approved gate, so nothing auto-publishes. This one is wired into the system, not just my habits. Every blog post carries a status field, and it sits at draft until I’ve read the whole thing and explicitly move it to approved. The publishing pipeline — the automation that announces a post to LinkedIn through Buffer when it goes live — only ever touches approved posts. The social caption gets written and reviewed at the same moment I approve the post, so nothing unseen ever ships. There’s even a linter that auto-rejects the AI-slop phrases — “game-changer,” “delve into,” “in today’s fast-paced world” — so the machine can’t quietly talk like a press release on my behalf. The automation does the tedious work. The judgment about whether something is ready stays a human gate, on purpose.

Slow down exactly where it’s dangerous. The rest of the day can move fast; the parts that can actually hurt you can’t. When I cut this site over to the new host, the real risk was never the website — it was the email, riding on the same DNS records I was about to repoint. So I treated that step as the opposite of vibe coding: capture every record first, verify the mail records came across before changing anything authoritative, keep the old site serving until the new one was wired, send myself a real test email to confirm mail still flowed. The IT job teaches what the vibe coding doesn’t: the last 10% is where the outages live, and it doesn’t care how fast the first 90% went.

The boring uses that compound

The flashy demos get the attention. The wins that actually add up are dull.

Context-building, mostly. Walking into an unfamiliar problem and getting just enough understanding to find the thread to pull — which is most of my actual day job. Sharpening a half-formed thought until I can see whether it holds. Staying on track through a long, sprawling build without losing the plot. None of that makes a good screenshot. All of it is where the leverage really is.

There’s a habit underneath all of it that I noticed somewhere strange: jury duty. Sitting through testimony, I caught myself doing the exact thing I do all day with AI — taking in a flood of information, organizing it, setting aside what wasn’t load-bearing, walking the evidence to a conclusion. No AI was in the room. The habit it had trained was. That’s the tell that I’m using it right. If the muscle only works while the tool is open, I’ve offloaded the thinking. If the muscle is sharper even when the tool is closed, I’ve used it to structure my thinking instead of replace it. That’s the whole distinction, and it’s the one I watch in myself.

I also ran a serious, multi-round penetration test against my own software with AI’s help — not because I’m a security specialist, but because it let me go as deep as I needed on each specific question without first spending a year becoming an expert in all of it. That found real problems: a timing oracle in a PIN comparison, a path-traversal gap, a password check running in the wrong place. The depth was available on demand. The instinct for “wait, this doesn’t fit how the rest of the system works” was mine, and that’s the part that doesn’t automate.

What it has not replaced

The taste, the responsibility, and the final call. None of those moved, and I don’t think they’re about to.

AI did the volume on everything I’ve built — the boilerplate, the first drafts, the framework details I never memorized, the tireless second pass when I changed my mind. It compressed the distance between an idea and a working version of it from days to minutes. That’s real, and it genuinely changed what one person can do in an afternoon.

But every decision that mattered was mine. What the site should say and who I actually am versus who the draft wanted me to be. Which clever feature to keep and which to delete. When to move fast and when to slow all the way down. The model doesn’t feel embarrassment, so it’ll defend a bad idea as readily as a good one. Knowing where its competence ends — where it’s powerful and where it fails subtly — is the actual skill, and you only learn it by using it a lot and paying attention to which is which.

That’s the workflow, with the hood up. It didn’t make me a developer. It made me something I find more useful: someone who can take an idea all the way to a real, owned, working thing — as long as I keep bringing the judgment and let the AI bring the speed.

---

Companion piece: Optimistic, Eyes Open is the why behind these habits — the research on what AI actually does to how we think, and why I land on the optimistic side anyway.