How I organize my work with AI

This chapter is the most personal one in the guide. It isn’t a recipe: it’s how I work. The tools will change, which is why I don’t mention any of them by name; what I hope stays are the principles behind it.

A caveat about the kind of user I am: I use AI very little as a chat “assistant” and a lot as a building tool — to write code, design interfaces, analyze data, and produce documents. I use tools from all the major vendors. And today it would be impossible for me to work the way I do without them.

Where does your work live?

Principle number one has nothing to do with technology: each area of work is a folder, and each project inside it is a repository.

~/work
├── fgv/            classes and research projects
├── plancorp/       the company's products
├── unieuro/        student projects (one repository per product)
├── consulting/     clients
└── personal/       this site, studies, experiments

The practical consequence is huge. When I open an agent inside a project, it only sees that project. When I open it one folder up, it sees every project in that area — and I can ask “how are my students’ projects doing?” and get an overview of who did what, across all the repositories, without opening any of them.

The folder level where I open the tool is the size of the context I’m giving it. It’s the context engineering from chapter 8, done with the file manager.

It’s also why I avoid the “do-it-all” agent that stores things its own way. They find their way around their own mess; later, a human trying to read it suffers.

Do you need a terminal?

I work most of the time in the terminal: that black text screen that looks like DOS. AI coding tools have command-line (CLI) versions, and I prefer those for three reasons:

1. I get distracted very easily. A screen with a single little box to type in, full screen, is the best environment I know for not getting lost.
2. Everything already talks to the terminal. Git, the cloud services, the databases — professional tools were born there. The agent uses the same ones an engineer would, with no special integration needed.
3. I see what’s happening. Every command the agent runs shows up on screen. I like knowing how things work under the hood, and that makes me more comfortable delegating.

I’ll admit the irony: a while back I complained that we were going back to the terminal and throwing away decades of interface work. I still think that, for most people, a good interface wins. For me, today, the little box won.

You don’t need the terminal to apply anything in this guide. The same products have an app and a web version, and the logic is the same.

On my machine or in the cloud?

The agent can work in two places:

• On my machine: it opens the project folder and works there. Fast, and the files stay with me. It’s my default.
• In a cloud environment: the AI vendor spins up a temporary machine, downloads the repository, does the work, and hands me back a pull request. I use it when I want to keep work moving from my phone, leave something running overnight, or keep a company project isolated from my machine.

An environment like that is set up once and has four parts:

# runs every time the environment is created
install the project's dependencies
install the cloud tools the project uses
create the test database with fake data
run the tests once to confirm everything is up

TEST_DB_KEY=••••••••
TASK_BOARD_KEY=••••••••

allowed:
  - the code repository
  - the company's two cloud services
  - the task board API
  (and a few more: a little over a dozen in total)
blocked: everything else

Why not pick just one tool?

I pay for and use tools from three different companies. When I blow through the limit on one, I switch to another. But that’s not the main reason: it was a deliberate decision so I wouldn’t depend on anyone.

It took work. Each tool has its own way of doing things, its own config file name, its own quirks. What made it possible was the rule from the previous chapter — the knowledge lives in the repository, in plain text. Any of them opens the folder and picks up where the other left off.

And the recommendation I give to people who are starting out is the opposite of “pick the best one”: test all three with the same real task. The difference between top models today is more a matter of taste than of capability.

What does it cost — and how do you pay?

There are two ways to pay for AI, and confusing them gets expensive:

For heavy use, the subscription is much cheaper — everything suggests that monthly plans are subsidized by the companies, which are fighting over who gets to be the default tool for people who build software. One public sign of that: a vendor has already introduced weekly limits to rein in subscribers who left the coding tool running nonstop, day and night. I once tried using one of these tools on pay-per-use, with no subscription: in two hours I’d spent what a month of subscription costs.

To give a sense of scale for someone who works with this all day: I keep three professional subscriptions. Each one costs between a third and two-thirds of a Brazilian monthly minimum wage; together, a little more than one minimum wage. It’s not small — and it replaces an amount of tools and hours I can’t even calculate anymore. For someone just starting out, the most basic plan from one vendor costs a small fraction of that and is enough to practice everything in this guide.

About API keys, which you’ll run into when you build your own agent:

• One key per project or per person. Never a “general” key.
• Set a spending limit. Always. Before you use it.
• Revoke it when you’re done. I create keys for students during a course and deactivate all of them at the end. A forgotten key is a bill left open.