An agent is nine lines of code. I am sorry. I do not make the rules.

Right. Let us start with the part that will annoy you. The phrase “AI agent” has been used so loudly, so often, and by so many people trying to sell you something that it has acquired a mystical quality. People talk about agents the way medieval people talked about angels. Agents are going to take your job. Agents are going to run your company. Agents are going to do everything from book your flights to architect your wedding.

An agent is a for loop. It is a for loop that calls a language model and lets the language model push some buttons in between calls. That is the entire technical innovation. I have been writing software for fifteen years and I promise you this is what the industry got excited about. We can be embarrassed about it together.

The reason it matters — and it does matter, despite being conceptually unremarkable — is that the buttons turn out to be everything. Let me show you what the loop actually looks like.

The whiteboard problem (or, why an LLM on its own is not enough).

There is a classic technical interview where the candidate is asked to write a working program on a whiteboard. No computer. No internet. No compiler to catch your mistakes. Just you, the whiteboard, and the marker. I have done this. It is genuinely one of the most cognitively unpleasant experiences in modern professional life. You have to remember every detail of the language, every detail of the standard library, and you have to get it right the first time because the marker does not forgive.

Asking a language model to write a working program with nothing but a chat window is exactly the same thing. The LLM has to remember everything, has to invent the program out of pure recall, has to hope it does not hallucinate a function that does not exist or get a syntax detail wrong. It can do this surprisingly well. But it is still doing whiteboard programming, and whiteboard programming is hard.

An agent is the same LLM, given access to a real computer. It can run code and see if it works. It can search the documentation when it is uncertain. It can read files in your project. It can patch its own mistakes when the tests fail. The difference between the LLM-on-a-whiteboard and the LLM-with-tools is the difference between a stressed interview candidate and that same person sitting at their desk on a Tuesday afternoon. The skill is the same. The performance is dramatically better.

The unglamorous list of tools that makes the whole thing work.

If an agent is the for loop, the tools are the buttons. The list of buttons is shockingly short. I will list them here, mostly to demonstrate that there is no magic. These are the same primitives any working programmer has had since approximately 1973.

• bash  —  runs any shell command. This is the single most important tool. Everything else is, in some sense, a special case of this one.
• patch  —  edits a file. Specifically, it applies a small change to an existing file rather than rewriting the whole thing. This is what lets agents work on real codebases without destroying everything.
• grep / find / cat  —  the classic Unix navigation tools. The agent uses them to read your project the way a programmer would: search for a function name, find the file it lives in, read the surrounding context.
• web_search / web_fetch  —  lets the agent look something up online. Crucial when working with a library whose documentation is newer than the model’s training data.
• todo  —  a notebook the agent uses to keep track of multi-step tasks. Sounds silly. Is not. The difference between agents that lose their place mid-task and agents that finish what they started is often just this.
• codereview  —  a self-check tool. The agent reviews its own changes before declaring itself finished. Catches roughly half of the obvious mistakes.

That is it. There is no secret thirteenth tool. Every serious agent you have heard about — Claude Code, Cursor agents, Sketch.dev, GitHub Copilot Workspace — runs on some variation of this list. The fancy names are just different combinations of the same primitives, wired up with different defaults.

Why this should matter to you, specifically.

If you are not a programmer — and most readers here are not — the agent revolution looks like it is something happening to other people. It is not. It is happening to you, and you should know what shape it takes, because the practical consequences for what you can build by yourself are larger than the discourse suggests.

Three years ago, building a working web app required either learning to code yourself (months to years of investment) or paying a developer (thousands of pounds and the social cost of explaining what you wanted three times). Agents change this equation in a specific way. You can now describe a small useful thing in plain English to an agent — “build me a tool that takes a list of customer emails and groups them by sentiment” — and have working code thirty minutes later. The code will not always be perfect. It will sometimes be wrong. It will occasionally require you to push back and ask for a different approach. But it will exist, and most of the time it will run, and you will have written it without writing a line of it yourself.

That is not nothing. It is a structural shift in who gets to build software. I cannot overstate how much I think this changes the kind of person who ends up shipping useful products in the next decade. The constraint used to be the ability to write code. The constraint is now the ability to know what to build. Those are very different constraints. They favour very different people. They favour, in particular, the people Vogue and Code is written for.

How to actually start using one this week.

There are roughly three tiers of agent tooling available right now, and you should pick the one that matches where you actually are.

If you have never written code: Start with a chat-based agent like Claude or ChatGPT in its agent or “artifacts” mode. Describe what you want. Ask it to build a small thing. Iterate by asking for fixes. You will not be running the code locally yourself. The agent runs it for you in a sandbox and shows you the result. This is the easiest entry point and it is more capable than most people realise.

If you have written a tiny bit of code: Install Claude Code or Cursor on your laptop. These run an agent against the files on your actual computer. You can give them a folder and tell them to build something useful. You will need to be comfortable opening a terminal and following installation instructions. The reward is dramatically more capable agents than the chat interfaces.

If you are already a working developer: You already know which tools to look at. Go run Claude Code with the “dangerously skip permissions” flag on a project you do not care about, prompt it with something you have been putting off, and watch what it does. It is the most enjoyable I have had with my computer in three years. Possibly five.

In all three cases, the same principle holds. Pick something specific you want to build. Describe it concretely. Be willing to push back when the first version is wrong. Iterate. The skill you are building is not coding. The skill you are building is precise communication about what you want, which is the more durable skill anyway.

A short list of things you should not do (learned the hard way).

I will end with the warnings, because the warnings are real and the discourse around agents tends to either pretend they do not matter or treat them as proof the technology is useless. Both framings are wrong.

Do not let an agent run on your machine with sensitive credentials. Agents can and will execute commands that touch the file system. If your laptop has production database passwords sitting in a config file, an agent that gets confused enough or prompted weirdly enough could end up reading them, sending them somewhere, or running a command against the wrong environment. Use containers or sandboxes when you can. Use throwaway accounts when you cannot.

Do not skip the review. Agents are good. They are not infallible. The code they produce often works but sometimes contains subtle errors that a careful read would catch. The seductive thing about agents is that the output reads as confident, which makes it easy to accept without thinking. Do the thinking. Read what the agent wrote. Ask it to explain anything you do not understand. Treat its output the way you would treat a junior developer’s first PR — with appreciation for the work and the assumption that it needs review.

Do not assume the agent knows what it is doing. The agent knows what the LLM behind it knows, plus what it has read in the current session. It does not know your business, your users, your past decisions, or the unwritten constraints in your head. If you do not tell it those things, it cannot use them. The agents that produce the best output are not the ones running on the most expensive models. They are the ones being talked to by humans who took the time to explain the problem clearly. That part is on you. It is also, perhaps not coincidentally, the part of the work that has always mattered most.