Español
Use is a person using AI; collaborate is person-to-person; coordinate is session-to-session. Underneath, one move: cut the work into blocks that don't depend on each other, leave an explicit interface, no cosplay anywhere.ensayo · standmeet2026.10.30 · ensayo
2026.10.30·lectura de 1 min

Use, Collaborate, Coordinate: How I Actually Work with AI / 使用、协作、协同——我怎么用 AI

Use is a person using AI; collaborate is person-to-person; coordinate is session-to-session. Underneath, one move: cut the work into blocks that don't depend on each other, leave an explicit interface, no cosplay anywhere.

Use, Collaborate, Coordinate: How I Actually Work with AI

Keep the three words apart. Use is me using the AI — I put it to work. Collaborate is person to person — my teammate and I working together. Coordinate is session to session — a row of AIs open at once, each running its own thing.

The internet's "how to use AI well" almost only covers the first, and usually stops at "write a good prompt." The leverage is in seeing that all three are the same move repeated at three scales: take a pile of work, cut it into blocks that don't depend on each other, leave one explicit interface between them. Cut all the way down until it lands in one AI with one context — that's use.

And one thread runs through all of it: at no level do we play cosplay. Nobody is "acting as a senior architect," no agent is cast as a test expert. Role-play solves nothing. What gets cut is work; what gets handed over is a criterion — what counts as right, what you measure it with — not a costume.

Use: put the AI inside one clean loop

If structure can make a bad write impossible, don't lean on a rule to guard it. There's a gradient. Worst is nagging — "remember to do X" — someone forgets eventually. In the middle is blocking it with a mechanism: a hook that kills reading files with sed or editing them with a script; a doc that bans "probably" and "should be," so a test that fails intermittently can't tell me "probably unrelated" — it has to run master and the fix five times each, 2/5 against 5/5, and put the numbers on the table. One level up is making the bad write impossible to express: a fact lives in exactly one place, so there's no second copy to get wrong; a path is never stored as an editable field, always computed live from the tree; in SQL a name only goes through formatting and a value only through a parameter slot, so you can't assemble an injection even if you try. When you can make the error impossible to write, don't stop at blocking it.

Hand over the work as a criterion; let a mechanism judge "done." What I give is the criterion: what counts as right, what you measure it with, which case is a failure. "Done" is written as a standing check verified from outside — the agent doesn't get to say so itself.

done  ⟺  criterion(tests green∧eval passes) checked externally ≠ agent says “ok”\text{done}\iff \text{criterion}(\text{tests green}\wedge\text{eval passes})\ \text{checked externally}\ \neq\ \text{agent says ``ok''}

Verify first, then talk about done. Fixing a bug: first write a red end-to-end test that reproduces it, then fix it to green. No getting around it with a unit test, no adding a retry, no fudging it with a fixed sleep. Once a redeem-code test went red, and it pulled two root causes out of the logs: throttling had swallowed the page refresh, and the message bus's authorization arrived a fraction of a second late. One got a refresh, the other was changed to wait for authorization first — shipped separately.

I don't write long specs; I drop one line at the key moment. You can never write the spec in full — the boundaries only surface halfway through the work. As it's about to wrap up, one line from me — "go look at their conventions first" — sends it back to read their AGENTS.md, and the unit-test style and docs get reworked to match.

Coordinate: split the work into a row of sessions by context, run them in parallel

Why split into several instead of one session grinding start to finish? Context. A session is a context window; cram everything in and it swells, dulls, starts bleeding one thing into another. So I cut the work into blocks that don't depend on each other, one block per session, each with a clean context, all moving at once. Independence is the premise: blocks don't depend on each other, so they run in parallel, and I'm not syncing between them mid-way. This is far faster than doing them one after another — not because the AI got smarter, but because I stopped making them wait on each other, and stopped letting one's context get dirtied by another's business.

The split is two-level. I split first: cut a pile of work into a few independent lines, one per session — that row of tabs on the screen. The hard part isn't the cutting, it's cutting so they're genuinely independent, each able to run to the end on its own. Then the agent splits itself: each session divides its own line further, opening a subagent when it should — it controls that itself. Most often it uses a subagent to protect context — heavy work that would blow up the main window, like pulling a thousand files or reading a few hundred thousand lines of log, gets handed to a subagent, and only the conclusion comes back; the process never enters the main context.

Most of the time they each run their own thing; coordination happens only when two lines actually meet — one session's output goes to another to carry on, one heavy job needs a resource and calls ahead, one gets stuck and goes to another session for its experience. Talk when there's reason to; otherwise a row of sessions all shouting at each other drowns me first.

Once parallelism goes up, the scarce thing isn't compute — it's my attention. So each session has to judge for itself when to come to me: if it can keep going, don't interrupt; if it's stuck, needs a call, or has finished and verified one thing, surface. When messages can't reach, I'm the bus, relaying for them.

output ≈ ∑i=1Nsessioni ,bottleneck=my attention (not compute)\text{output}\ \approx\ \sum_{i=1}^{N}\text{session}_i\,,\qquad \text{bottleneck}=\text{my attention}\ (\text{not compute})

Collaborate: person to person, with an issue board as the decoupling middleware (the top level)

Zoom out one more level: not me and a row of sessions, but me and a real teammate. We each use our own AI, two independent loops, neither watching the other's session. What connects us is an issue board — that's the middleware — and one issue is often where both sides' AI output converges.

A real one. A teammate sent over a Japanese PDF; the body text was all lost. On their side they were also using AI, and did a full reproduction locally: matched the same garbled output line by line, pinned it to a missing parameter in the parse call, and pointed out "there are 700-some characters, so it isn't empty, so OCR never triggered" — plus a fix direction and a regression test. That issue was itself an executable handoff. I said "I'll take it" and handed it to the AI on my side: add the parameter, add a criterion — "too few characters on a page routes to OCR" — add an end-to-end case (he didn't attach the original book, so build a fixture in that shape), red then green, smoke, then back to the issue to write out what was fixed and what isn't covered yet, ship and close only after I nod. Their AI turned a symptom into root-cause-plus-repro; my AI took the issue as the spec and implemented and accepted against it; the issue's comments were where the two sides met. Through the whole thing, neither of us looked at the other's session.

Being the middleware comes with middleware's rules. Messages have to route to the other end: once the AI finished a fix but only pushed main and prod, didn't merge to dev, and the teammate — who only accepts on dev — saw the fix missing; afterward it became a hard rule, merge to dev after committing. What goes on the board is a symptom; the conclusion the AI has to nail down into evidence itself. For an irreversible action, the board has to hold a human gate.

Once the AI thought some parameter on the mail interface could limit the recipient to one, called it four times, and it turned out that interface broadcasts to everyone — a few scheduled launch emails went out early, real people got them, couldn't be recalled. From then on it's fixed: the AI never touches sending, and for anything outward-facing and unrecallable the last press is a human's. And a small rule: when git log has two authors, the AI must not pass the teammate's commit off as mine.

One pit I haven't solved

Writing "done" as a mechanism's judgment — good — but I keep tripping on one thing: the criterion gets written as "everything implemented" without carving out "external preconditions only a human can push." Buying a developer account, a manual click after a desktop release, restarting a machine — the AI can't push these, so that check judges "not done" every round, and it comes back to me again and again with "no change," and even when I say "call it done" it can't clear it.

The more autonomous the tool, the more you have to say out loud which parts are its work and which can only wait on a human. This one I'm still tuning.


Use, Collaborate, Coordinate are three things, and underneath they're the same move repeated at three scales: cut the work into blocks that don't depend on each other, leave an explicit interface, hand it over by criterion, no cosplay anywhere. It's the same at every level — only one press is always left to a human: the one that crosses the interface, lands on someone else, and can't be taken back.

pregúntele a la IA sobre este ensayo·contexto: "use, collaborate, coordinate: how i actually work with ai / 使用、协作、协同——我怎么用 ai"
›