# Keep the thinking

> Why the part of the work that feels slow is often the part worth keeping, where to let the agent run, where to slow down, and how to tune out the noise about tools.

Module: Working with AI · Level: beginner · 7 min · https://school.agents.org.in/foundations/working/keep-the-thinking

It's eleven at night. You had an idea over dinner, and by midnight an agent (A language model plus a harness: the model decides what to do, the harness gives it tools to read files, write code, run it and check the result), the AI that reads, writes and runs code on your computer, has built three versions of it. They all work. None of them answers the question you never stopped to ask: should this exist at all?

That's the new trap. Building used to be the slow part, so you only built what you'd already thought through. Now the building is fast, and the thinking has to happen on purpose.

## What the effort used to do

When a feature took a week, the week itself did a job. It filtered your ideas. You'd sketch, talk to someone, sleep on it, and half the ideas quietly died before anyone wrote code. The ones that survived had been thought about.

Agents took away the cost, and the filter went with it. So you put a little of it back, but only where it matters. Call it selective friction (Keeping some effort in the work on purpose, only where your judgment is the point: deciding what to build and why. Everything else you let the agent speed through): keeping some effort in the work on purpose, in the places where your judgment is the actual product, and letting the agent speed through everything else.

> **In plain words.** Think of a kitchen with a food processor. You let the machine chop the onions. You still taste the sauce yourself.

## Let it run, or slow down

Most of the work splits cleanly once you ask one question: is my opinion the point here, or is this just work?

| Let the agent run | Slow down and do it yourself |
|---|---|
| Research: how five other apps handle bulk export | What the feature is for |
| Summarising 300 support tickets into themes | Who it's for, in one sentence |
| Renaming forty files to a new convention | What you'll leave out |
| First drafts of test data for a table | Which of three directions to keep |
| Finding every file that imports a component | When it's good enough to stop |

Notice what's on the right. None of it takes long. Writing down who a feature is for might take four minutes. It just can't be skipped, because **an agent will happily build for nobody in particular**.

Try sorting a week's worth of tasks:

*[Interactive demo: Eight tasks from one feature. Pick a side, then read the reason.]*

## Get questioned first

The easiest way to keep the thinking is to have the agent ask before it builds. Give it your one-line idea and tell it to question you, one question at a time, until the goal, the person and the reasons are written down. One question at a time matters: a list of ten questions gets ten lazy answers, and one question gets a real one.

Matt Pocock's public grill-me skill is a ready-made version of this, a skill that interviews you about a plan until it's solid. A skill (A folder of written instructions an agent loads when a task matches, so it does the work the way you want instead of its default way) is a folder of notes your agent reads when a task matches, so you can install it once and call it whenever you start something new. You don't need it, though. A plain prompt does the same job:

**Question me before you build (paste into your agent):**

```text
Before you build anything: I want a shared reading list for my team.
Ask me questions one at a time until we've written down who it's for, the problem it solves, what's out of scope and how we'll know it worked.
Don't propose solutions or write code until I say "build".
```

Here's how that goes in practice. Four questions, four honest answers, and a brief you'd actually build from:

*[Interactive demo: One idea in, four questions one at a time, a five-line brief out.]*

*(The brief is the payoff, not the code. If you can't write those five lines, the agent can't build the right thing either.)*

## The noise

Every week someone posts that a new harness (The hidden layer of ordinary code around a model: it lists the tools, notices when the model asks for one, runs it and sends the result back. Model + harness = agent), the app that wraps a model and gives it tools, or a new model, makes everything ten times better. Sometimes it's a little better. Usually the difference is smaller than the thread suggests, and your setup matters far less than the clarity of what you ask for.

So before you switch, run one of your own real tasks in both tools and compare what comes out. That's the only evidence that counts. And keep an eye on the numbers people brag about: a hundred pull requests a day is a number, not a product.

Pick tools by how they feel to use day to day, and keep the setup boring. The interesting part of the work should be the work.

## What to remember

- Building is fast now, so the thinking has to be on purpose: slow down on what, who, what's out and when to stop.
- Before anything new, have the agent question you one question at a time until a short brief is written down.
- Judge a new tool by running your own real task in it, not by the thread that announced it.

**Check yourself:** Which of these is worth doing slowly yourself?

- [ ] Summarising 200 survey replies
- [x] Deciding what the new feature leaves out
- [ ] Finding every file that imports a component
- [ ] Drafting fake data for a table

*Why:* Summaries, searches and filler data gain nothing from your opinion. What a feature leaves out is a judgment about your users, so that's where your time belongs.

Go deeper: [Briefs that work](/learn/agents/briefs-that-work) · [Hand it over, or do it yourself](/foundations/working/delegate-or-do) · [Turn what you know into a skill](/foundations/working/knowledge-into-skills)

## In the skill

- https://school.agents.org.in/skill/meta/directing-agents.md