Before automating, be curious: the AB-Arts method

You see plenty of users rush at Claude with one question in mind: "what can I automate right away?". The instinct is good, the timing is wrong. Before automating anything, two disciplines make the investment pay off over time: curiosity, which pushes you to explore what the tool can actually do, and documentation, which keeps memory of what you've discovered. Without them, every automation is an island. With them, you build a coherent archipelago.

This article describes the method we use at AB-Arts. Three movements: be curious, be interested, write down what you learn. It's not flashy. It's simply what makes the difference, three months in, between a team that surfs on Claude and a team that gives up.

Curiosity, the muscle we no longer train

Curiosity, in the relationship to a tool like Claude, has nothing mystical about it. It's the urge to test what isn't written in the manual. To click on a menu you've never opened. To type a command you've never seen anywhere. To ask Claude something you'd never ask a human assistant, just to see.

That's what separates lazy usage from living usage. The first consists of copying the prompts you saw on LinkedIn. The second consists of asking yourself, in front of each task: what if I tried it another way? What if I asked for another angle? What if I plugged it into this base? The second is more tiring for the first few weeks. It pays off infinitely more in the ones that follow.

Concretely, you keep this curiosity alive through small repeated gestures. You follow two or three reliable sources that show what others are doing with Claude: Anthropic's blog, specialized YouTube channels, newsletters you read in the morning. You reserve ten minutes a day to try something you didn't try the day before. You note the result, even if disappointing. Over three months, that adds up to dozens of tries, and the acquired knowledge is no longer the same.

Take an interest before you optimize

Interest is the second pillar, and it differs subtly from curiosity. Curiosity explores. Interest leans in. When you read an article, you can skim it or pause on it. When you discover a new Claude feature, you can sort it mentally ("useful / not useful"), or sit down five minutes to grasp how it works, where it could help, what it changes against the existing.

💡 Interest is the decision to slow down in front of a tool while everyone else runs. That's exactly what produces, six months later, the competitive edge.

In front of a feature like the official MCP connectors, for example, you can settle for installing Notion and moving on. Or you can spend half an hour going through the full catalogue, spotting three or four MCPs that touch your work, reading exactly what each one allows, and noting the ones that deserve a deeper trial. The first approach costs five minutes and changes nothing over time. The second costs thirty minutes, and transforms your vision of what's possible.

Interest, by construction, isn't in a hurry. It's even calm. But it's lucid. And in a world where the pressure is to test every model released the night before, slowing down becomes an act of method, not of laziness.

The notebook, the note, the README: three shapes of the same gesture

Curiosity explores, interest deepens, documentation conserves. Without the third movement, the first two fade. We've all had the unpleasant experience of vaguely remembering that we tried something two months ago, without being able to put our hand back on the result. Documentation is what stops that from happening again.

It takes three main shapes, which complement each other.

Shape	Role	Typical tool
Notebook of intuitions	Catch an idea in flight, before it fades	Voice memo, sticky note, quick-capture app
Deep note	Dig into a subject when you take interest, keep the structured trace	Obsidian, Notion, local Markdown file
Project README	Describe a setup at a moment T so you can find it again six months later	README file in the repo, shared team doc

The three have the same function at heart: protect your memory against forgetting. The difference is in the grain. The notebook catches the lightning. The deep note keeps the understandings. The README keeps the configurations. To see those three shapes cohabit over the long run on a personal vault, read our piece on Obsidian and Claude daily, which details how each grain (notebook, note, README) feeds the others. But the intention is identical everywhere: what you understood must not be lost.

The map of the tools you know

Practical case, which we recommend to every team starting seriously with Claude: keep a map of the tools Claude can connect to, and that you've already tested. That document, fitting on two pages, changes the daily life.

Concretely, you list each MCP or integration tested. You note what you expected, what you got, the traps you ran into. You sort by category (creative, project, dev, marketing, finance). You mark the ones already deployed in production, the ones still at the trial stage, the ones you ruled out and for what reason. You update it after every new trial.

Why is this document so valuable? Because it turns the scattered knowledge of each team member into shared assets. A newcomer reads the map and saves two months. A team having to decide on an automation looks at the map before reinventing the wheel. At the end of a quarter, this document becomes one of the most precious assets of the project, and it's free to produce.

A daily exercise, ten minutes a day

To anchor this discipline without it becoming a burden, here's a short ritual that works, and that we teach in our masterclasses. Every morning, ten minutes before opening your inbox. No more.

• Minute 1 to 3. Read one short source. An article, a release note, a forum thread. Pick a thing you hear about without knowing it.
• Minute 4 to 7. Test one thing in Claude. Anything, but one thing you didn't test the day before. A new MCP, a new way of writing a prompt, a new type of task.
• Minute 8 to 10. Write two sentences in your notebook. Not a literary essay, not a report. Just: what I tried, what it gave, what I keep.

On ten minutes, it looks small. Over three months, that's sixty documented tries. Over a year, more than two hundred. At that pace, Claude usage becomes a discipline rather than a lukewarm habit.

Why this discipline pays off

You might think that, at the end of the day, the method doesn't matter, as long as you automate. That's missing what's at stake. Well-designed automations always rest on a fine understanding of the domain. That understanding can't be bought. It's built by this curious-interested-documented routine this article describes.

The more time passes, the wider the gap grows between a team that holds this discipline and one that just follows trends. The first knows what works at home and what doesn't. It can explain its choices, defend its architectures, find why such a decision was taken six months ago. The second simply re-implements, with each new model, what it was already implementing with the previous one, without real gain.

The AB-Arts method in two sentences: we never automate what we haven't understood, and we only understand by having been curious then interested then methodical. That discipline is what we transmit in our masterclasses, because it's the root of everything that comes after, from prompts to deployment. For a tailored setup in your professional context, reach out through our contact page.

---

To go further on the practice of personal documentation, read our piece on Obsidian and Claude. To measure concretely the difference between passive and active curiosity, read our article on creativity as raw material.