Being curious is what makes you good at using AI

Before agents, I built AI automations in n8n. You had no choice but to understand what was happening, because you built every step of it yourself.

You drop a node. You run it. You get a JSON payload back. You look at that payload and you map its keys into the next step: this field goes into the system prompt, that one into the user message, this other one defines the shape of the structured output so you can use its keys three steps later.

It’s slow to set up and it teaches you everything. You end up with a very visual picture of what an AI call actually is: one step, with an input you chose, a prompt you wrote, and an output you have to do something with.

What that forced you to get right

A real one. A product feedback ticket arrives on a webhook. You pass the text to a model whose only job is to categorise it: is this a bug, is it urgent. You read the answer, and if it’s urgent you route it to a Slack notification with a two-line summary so the team knows.

Three small steps. Each with its own prompt. Each prompt containing only what that step needs.

Nobody hands the model the whole company and hopes. You couldn’t, the tool didn’t let you.

Agents took all of that away

Now I open Claude Code and throw the problem at it. It reads my files, it calls my connected tools, it decides on its own what to do next. It works, for almost anything, which is exactly why it’s worth using.

It also hides every one of the concepts above. And in some setups it loads the description of every tool of every connector before you’ve even asked anything, which is a lot of tokens spent on capabilities you won’t touch today.

Why you should care, even if you never ship a product

Two things break when you don’t look.

Your budget. If you burn a week of tokens by Wednesday, Thursday and Friday are a problem you created on Monday.

Your loop. If every message takes fifteen minutes to come back, you stop iterating. You write one instruction, go do something else, come back, find it went sideways, and start again. The cost is not the fifteen minutes, it’s that you only get four attempts in a day.

There’s also the model you’re using. Most of us run a big one for everything, and for more than half of what we do a smaller one would answer faster, just as well, for less. The rough rule holds: smaller is cheaper and faster, smarter is slower and more expensive. Knowing which half of your work is which is worth real money.

And if you do ship a product, it’s not a detail

When it’s you at the keyboard, a task taking ten minutes or twelve is (kind of) the same thing. You’ll check later.

Put the same thing in front of a customer and the numbers change meaning. Someone uploads a file, your automatic mapping takes twenty-five seconds, and you’re out. Not four minutes. Twenty-five seconds.

I ran into the sharp version of this building Lookio. Between an answer arriving in five seconds and the same answer in nine, one of them belongs in a chat widget and the other doesn’t. Between one cent per answer and nine cents, my margin is 85% or it’s 40%, and that decides what I can charge.

Same model, same product. The difference was in how it was put together.

What being curious looks like, concretely

You may never have built the n8n version. You can still get most of that understanding out of the agent you already use.

Read the list of tools a connector gives you

When you connect something, the platform will usually show you every tool it exposes, with a name and a description. Read it once. You’ll learn more about what that integration can do in two minutes than in a week of asking.

If your CRM connector has no tool for deleting a contact, and you spend ten minutes pushing an agent to delete a contact, it isn’t being lazy. The capability doesn’t exist and it can’t invent one.

You can also just ask:

List every tool this connector exposes. For each one: its name,
what it does, and whether you'd use it for what I'm about to ask.
Flag anything I seem to be assuming is there and isn't.

Click on the tool calls

From your message, the agent picks between a few things: call a tool, write you an intermediate note about what it’s about to do, or answer you and stop. Then it reads whatever came back and picks again. That’s the loop.

In Claude Code you can click any of those calls and see inside it.

Open a few of these and the magic goes away, in a good way. The agent invents nothing. It reads what a tool handed back, the same way it reads a file, and decides what to do with it.

Ask how it plans to do it, before it does

Say you ask for an MP4 built from code rather than from footage. Ask how it intends to go about it.

It’ll tell you it writes HTML and CSS for the animation, renders that in a headless browser, records the frames, and encodes them into a video.

Now you know something useful. You have HTML already, the one your website is built from, with your fonts and your colours in it. So you can ask the next question: can you reuse the styles from my site so the video looks like it?

You would not have thought to ask that an hour earlier. Understanding the path is what produced the idea.

Before you start: how do you plan to do this? Which tools, in what
order, and what does each step produce? Don't write any code yet.

Ask for three ways, not one

One answer will be quick to build and rigid. One will be slow to build and take any input you throw at it. One will be in between.

Left alone, an agent picks the simplest thing that works, which is a good default and is often not what you want. Challenging it costs one message.

Give me three ways to do this, with the trade-offs of each: how long
it takes to build, how it breaks, and what it costs to run. Tell me
which one you'd pick and why.

Ask what took the longest, and what it was missing

After something expensive, ask which steps ate the time, and whether it had the right tools for the job.

This is where you find out it was compensating. Ask it to pull data about companies from LinkedIn and, with no tool for it, it will improvise something slow and half-reliable. Give it a real scraping service like Apify and the whole thing collapses into one call.

I did this on my own video rendering. I asked whether the encoding could be faster. It went from fifteen minutes to three. Same output. That changed my day, because iterating five times stopped being an afternoon.

That's done. Now look back at how you did it: which steps took the
longest, where were you working around a missing tool, and what would
you do differently? Try the better version, then tell me what changed
and by how much.

Try three before you try two hundred

Before you point an agent at 200 competitors, have it do 3. Then ask what was painful to get at, what was slow, and where it guessed.

You’ll fix the process while fixing it is cheap. Sometimes that means giving it a tool it didn’t have. Sometimes it just means saying the thing differently.

Before doing this for all 200, do it for 3. Then tell me what worked,
what didn't, and what you'd change. Iterate on those 3 up to three
times if it helps. When you're happy with the method, explain how it
works and wait for me to approve it before you run the other 197.

What it adds up to

Every one of these takes a minute and gives you back a piece of the picture the tools stopped showing you.

After a while you stop handing over the whole problem and hoping. You know roughly what’s under there, so you ask better, you catch the confident wrong answer earlier, and you recognise a shape you’ve seen before on a completely different task.

That last part is the one I didn’t expect. Most of my better ideas in the last year came from understanding how something worked and realising it could be pushed somewhere else entirely.

Keep a place to try things

I have a folder called duv-lab. Its AGENTS.md says what it is, in one line: a laboratory, nothing in it is production, expect mess at the edges.

A few things are ready at the root so I never set them up again: an OpenRouter key for trying models, and Cloudflare credentials so anything can be online in a minute.

Then one subfolder per idea, each self-contained, each deletable with rm -rf without breaking anything else. Painting images with nothing but JavaScript. Taking apart a model that returns probabilities instead of text. Animating a video from code.

The point of it is that there are no stakes. Nothing to break, nothing to justify. Last week I screen-recorded something someone posted, dropped the clip in a new folder, and asked: if I asked you to build this, how would you do it, and can you try it three ways?

You want somewhere like that. Somewhere you can be wrong quickly, without it touching the work you actually have to deliver.