Chapter 3 — Ditching the editor

Editors had been my workplace for about fifteen years. Not just a tool I used, but the room where the work happened.

At the beginning it was Notepad. The work was close enough to plain text that plain text felt honest. Dreamweaver belonged to a different period, when seeing the page and building the page felt like the same job. JetBrains made sense when the codebase became a world of its own and I needed the room to understand more of it. Sublime and Atom made the room lighter. VS Code made it expandable.

I tried vim. I tried living in the console. I always came back.

Each editor answered the question I had in that year: what am I here to do? Write the file. Understand the project. Move through it faster. Keep more of the system nearby. When the friction changed, I changed editors, but I never questioned the window itself. There was code in the middle, a tree beside it, and me making decisions line by line.

That arrangement survived every change in my career. Languages changed. Frameworks changed. I moved from writing code to managing people and back again. The editor stayed.

That is why leaving it took longer than it should have. I was not comparing two applications. I was admitting that the place where I had worked for fifteen years no longer matched the work.

When coding agents arrived, they arrived inside the editor.

Cursor, Windsurf, the VS Code-shaped tools — they let me keep the familiar room while changing who did the typing. That mattered. I could ask for a feature, see the files change, inspect the result, and fix the parts I did not like without learning a new way to sit at the computer.

For a while, that was exactly what I needed.

Buenos Bakery was built that way. The agent wrote. I read. It moved quickly, and I kept quality under control by reviewing the work the same way I had reviewed human work: line by line. The editor was useful because editing was still the job.

But the agent in the pane also hid what had changed.

Typing was no longer scarce. Judgment was. The important questions were moving away from whether this function should be split or that type should live in another file. They were becoming: did we build the right thing, does it work, does it belong in the product, and can the system prove it is safe to merge?

Chapter 2 was about the walls around the code. Standards, placement, guards, tests — the structure that lets an agent work without inventing a new studio every time it opens a repository. Those walls matter because I cannot personally inspect every brick.

That was the contradiction sitting on my screen. I was building a system designed to work without my line-by-line attention, then spending my day in the one place built to demand line-by-line attention.

An editor is where you edit.

This sounds too obvious to be useful, but it took me months to take it seriously. Everything in that window pulls you toward the code. The changed line asks to be read. The file tree asks to be navigated. The agent finishes and presents a diff, so the responsible thing appears to be checking the diff.

With one agent on one project, it is responsible.

With several agents across several projects, it becomes a choice about what not to do. Every minute spent polishing one worker's change is a minute not spent checking the product, unblocking another worker, or deciding what matters next. The code can be perfectly reviewed while the studio waits for me.

Another AI editor would not have fixed that. It might have made the same loop smoother, but the loop itself was the ceiling: ask, watch, inspect, correct. One person supervising one stream closely.

I had already learned in the bakery project that making the writer faster does not make the whole operation faster. Now I had to accept the more uncomfortable version.

Once my review moved to the product level, staying in an AI editor was pretending my job was still editing.

The code window was the wrong workplace.

I left the editor for terminal supervisors.

The visible change was small. Ghostty first, then Most. Instead of arranging code windows, I arranged spaces around supervisors and orchestrators. Each supervisor held a project or a part of the operation and sent work to smaller agents — drones — that could write, test, inspect, and report back.

These days there are usually around six or seven supervisors, each working with roughly two to five drones. The exact number moves with the day. Lately, much of the work has been infrastructure-heavy. On another day, more of it may be product work. The point is not how many terminals fit on a screen. The point is that I am no longer inside each task with each worker.

I manage the work.

That means the questions on my screen are different. What is blocked? What failed its checks? Which change is ready to merge? Does the product behave correctly? Which supervisor has enough context to decide, and which decision still needs me?

The code and tests still live locally. Agents still make bad choices. A green check can still hide the wrong product decision, and a clean implementation can still solve the wrong problem. Leaving the editor did not remove review. It moved review up a layer.

That distinction is the whole thing.

The workshop model put me beside one worker, looking at one piece as it was made. The factory model puts me on the floor, moving between lines, checking outputs, fixing the system that produces them. I can step into a repository when I need to. I just do not live there anymore.

I keep a cockpit that counts pull requests and merges. The number jumps around — some days a flood, some days ordinary — and I do not trust a neat multiplier for work this uneven. A one-line repair is not a feature. Still, put next to how I worked before AI, a strong day in that cockpit looks like a different scale of shipping.

That gain does not come from typing faster. It comes from no longer making every piece of work wait for my cursor.

Software people like to believe we have finally found our tool.

We tune the shortcuts. We move the settings from machine to machine. We learn the odd corners, forgive the annoying parts, and slowly turn familiarity into a principle. The tool becomes part of how we describe ourselves. I am a JetBrains person. I am a vim person. I build in Cursor. This is my setup.

I did this too. Every move felt like it might be the last one: the editor good enough to stop thinking about editors.

But tools belong to the work, not the other way around. My habits are allowed to expire.

Not every review deserves the same distance. When I was writing each line, the line mattered most. When one agent was writing inside my editor, the diff mattered most. When several supervisors are coordinating several agents, the product, the tests, the standards, and the state of the whole system matter more. The lower layers do not become unimportant. They become somebody else's immediate responsibility, held inside walls I can verify.

This is also where the people in the system change. At first, the workers sit in the editor and a person manages them from the same pane. Then the person leaves the pane. The agents keep working close to the code; the person starts managing the conditions around the code.

That was the doctrine change in January. Nothing broke. I simply stopped treating the last tool that felt magical as the place I had to stay.

By the time I admitted it, I had already ditched the editor. I just had not closed the window.

Leaving the editor created a different problem. The agents' brains were remote — Anthropic, Codex, and others — but the code, tests, containers, and all the work they touched were still running locally. A MacBook or PC has a very ordinary limit, even when the workers using it do not sleep.

Most spaces, around seven orchestrators, ops-layer, Cortex, AgentBus, Nomad: those names belong to the system that grew after the code window disappeared. They are later chapters. For now, it is enough to say that once the workshop became a factory, the factory needed somewhere to live.

Next chapter: the laptop ran out of room — and the studio moved onto its own server.