← All writing

A practical process for working with AI, day to day

Most of the advice about working with AI is either breathless ("it changes everything") or dismissive ("it just makes things up"). Neither is much use at 9am when you have a report to build. So here's the unglamorous middle: the actual loop I run, dozens of times a day, when I hand a task to an AI tool and get something useful back.

I'm a data analytics manager, not a prompt influencer. I use AI the way I use any other tool on my bench — for drafting SQL, sketching a Python script, summarising a messy dataset, rubber-ducking a tricky join. Over time the way I do that has settled into a small, boring, repeatable process. It isn't tied to any one product. It works the same whether I'm in a chat window, an IDE assistant, or a notebook. And the single most important part of it is the part most people skip.

The loop: frame, delegate, verify, iterate

The whole thing is a cycle, not a one-shot. You frame the task and give it context. You delegate the right slice — not the whole job. You verify the output rigorously. Then you either iterate on the same loop or escalate to a human. Round and round, in minutes.

1 · Frame task + context 2 · Delegate the right slice 3 · Verify read · test · check 4 · Iterate or escalate repeat until it holds up
A loop, not a one-shot. Most of the value lives on arrow three.

1 — Frame: spend the context up front

A vague request gets a vague answer that looks confident. The fix is cheap: say what you're actually trying to do, what the data looks like, and what "good" means. When I ask for SQL, I don't write "give me top customers." I paste the relevant table and column names, say which dialect (BigQuery vs. Postgres matters), define the metric — is "top" by revenue, by margin, by order count? — and name the edge cases I already know will bite, like refunds or test accounts.

Framing well is the cheapest leverage in the whole loop. Two extra sentences of context routinely save me three rounds of correction. It's the same discipline as writing a good ticket for a colleague: the clearer the brief, the less rework.

2 — Delegate: hand over a slice, not the job

The instinct is to delegate the whole task — "build me the dashboard." Resist it. AI is most useful on a well-bounded slice where I can describe the input and recognise a correct output. So I delegate the gnarly regex, the window-function skeleton, the boilerplate around an API call, the first draft of a docstring. I keep the parts that require judgement, business context, or accountability — what the metric should be, whether the result is plausible, what ships.

The smaller the slice, the easier the next step. A 200-line script I can't follow is a liability. A 20-line function with a clear contract is something I can actually check.

AI doesn't replace the thinking. It compresses the typing around the thinking — and only if you still do the thinking.

3 — Verify: this is the whole game

If you take one thing from this post, take this: the verification step is the work. Everything before it is setup. A fluent, well-formatted, completely wrong answer is the default failure mode of these tools — they're built to sound right, which is a different thing from being right. Public research has catalogued how often models state false information confidently; the practical lesson isn't "don't use them," it's "never ship anything you haven't checked." Anthropic's own research on model behaviour and reliability is a good reminder that fluency and correctness are not the same axis.

So I verify the way I'd verify a junior analyst's first week. I read the output line by line — not skim it. I run it on a small known case where I already know the answer. I check the numbers: does a sum reconcile to a total I trust, does a row count make sense, does the join blow up or drop rows? For a generated SQL query I'll run it against a slice with a known result before I let it near production. For a script I'll feed it an input I've computed by hand. For a dataset summary I'll spot-check the claims against the raw data, because a tidy paragraph can quietly invent a trend.

The one rule I never break I treat every AI output as a draft from a fast, confident, occasionally wrong colleague — useful, but never trusted on sight. If I can't verify it, I can't use it. The tool's job is to produce a candidate; my job is to decide whether it's true.

4 — Iterate, or escalate to a human

Verification has two outcomes. Either it holds up — ship it — or it doesn't, and now I have a choice. If the gap is small, I iterate: I feed the specific failure back ("this dropped the refunded orders, keep them but flag them") and run the loop again. Tight, specific feedback gets a better second draft than starting over.

But if the gap is about judgement — an ambiguous business definition, a risky assumption, something with real downside — I escalate to a person. That might be me stepping back to think, or it might be a colleague who owns that domain. Knowing when to leave the loop is as important as running it. AI is wonderful at the bounded and verifiable; it is not where I want final accountability for a number the business will act on.

The process, concretely

Here is the loop as I'd actually run it for a typical request — say, "draft a query for last quarter's churned accounts":

  • Frame it. Paste the schema, name the dialect, define "churned" precisely (no activity in 90 days? cancelled subscription?), and call out exclusions like internal test accounts.
  • Delegate the slice. Ask for the query body, not the whole pipeline. Keep ownership of the metric definition and what counts as "done."
  • Read it. Walk every line. If I can't explain what a CTE does, I don't trust it yet — I ask it to explain or simplify before going further.
  • Test it. Run it on one known account and one known month where I already know the expected result. Reconcile the row count and a total against a figure I trust.
  • Iterate or escalate. Small bug? Feed back the exact failing case and rerun. Ambiguous definition or material risk? Stop and bring in a human before anything ships.

That's the entire method. It's deliberately unexciting. There's no secret prompt, no magic phrasing — just a frame, a bounded handoff, hard verification, and a decision about whether to loop again or pull in a person.

Why the process matters more than the tool

The uncomfortable truth I keep coming back to: AI is a multiplier, and multipliers work in both directions. Drop it on top of a clear, disciplined workflow and you get real leverage — the same output in a fraction of the time, with you spending your hours on judgement instead of boilerplate. Drop it on top of a sloppy one — no framing, no verification, blind trust — and you get the same mistakes you'd have made anyway, just faster and with more confidence behind them.

That's why I don't think the interesting question is "which AI tool is best." The tools are converging and they'll keep getting better. The durable advantage is the process around them: how clearly you frame, how carefully you delegate, and above all how rigorously you verify. Get that right and almost any capable tool becomes useful. Skip it and the best tool in the world just helps you be wrong on a deadline.

So my honest, balanced take after a year of this: AI hasn't made the analyst's craft obsolete. It's moved where the craft lives — out of the typing and into the framing and the checking. The loop is small. The discipline is everything.

Oleksandr Tverdokhlieb
Oleksandr Tverdokhlieb
Data Analytics Manager · Dubai — building data platforms, automation and applied AI.
More writing → How I use AI Connect on LinkedIn ↗