Two Chairs, One Terminal: How a Human and an AI Actually Collaborate
There's a lot written about "using AI" as an oracle: you ask, it answers, you leave. That's not what I want out of these tools, and it's not what actually happens in my day-to-day. What happens is closer to two people sharing a workbench. One of us knows the machine's ground truth; the other knows an unreasonable amount about how systems work. Neither of us knows the whole problem at the start, and each of us is carrying gaps the other can fill.
The examples below are deliberately summaries — hints, not transcripts. The point isn't the commands; it's the pattern: every one of these started as a problem only half-understood by either party, and ended as a result plus two people slightly less ignorant than when they began.
The shape of the work
The conversation itself is the method. Turns are short and load-bearing: I paste what the machine actually said, the assistant answers with a hypothesis and a next step, I run it, and the result reshapes the hypothesis. My contribution is evidence and context no amount of book knowledge can substitute for; its contribution is the map — the semantics, the prior art, the distinction between an authentication problem and a permissions problem. Each of us is occasionally wrong, and the wrongness gets replaced rather than defended. That last part matters more than any single fix: a collaborator that can't be wrong can't be useful.
Three recent examples, one section each.
The share that only failed sometimes
An SMB share from my NAS mounted on my Macs via a Finder login item — but only sometimes. On failure I'd get a warning at login, dismiss it, and connect manually by the same method, every time. My instinct was a timing race: the connect was firing before the network was ready, and System Settings offers no way to say "wait first."
Brought to the workbench, the reframe was immediate: if you can't add a delay, add a condition. We replaced the login item with a small script that waits until the NAS actually answers, then mounts using the keychain for credentials, with the system's job scheduler retrying quietly if the network isn't up yet. Getting there filled gaps in both directions — the keychain mechanics and a misread error message (privilege, not authentication) on my side; macOS-specific mount behavior on its side — and along the way a debug dump of my own shell environment exposed a live password into the chat, which we caught, rotated, and turned into a better habit.
Result: the share now mounts at every login, including after a cold restart, which was the case that used to fail. Small problem, real result, and both of us left knowing things we didn't walk in with.
Research leading to a purchase decision
When the M5 Macs first appeared, I dismissed them without ceremony — I didn't need one, and launch-day noise wasn't going to change that. Then Apple introduced the MacBook Neo at a startlingly low price, and I noticed myself doing something less honorable: reaching for a reason to buy one. The wanting came first; the justification was going to have to be found somewhere.
It arrived sideways, out of completely unrelated work. Forking Mate-Engine-Mac-X to build the familiar's LAN bridge surfaced a practical constraint: GPT-SoVITS installed on the same computer is a problem for low-resource Macs like the Neo. To me that read as another reason to buy — a machine whose limits give it a specific job in the setup. But I know what wanting a toy looks like on me, so I brought the whole tangle to the workbench and asked for a less irrational decision.
The discussion did what it does. We separated the attraction (the price) from the use-case, confirmed the testing angle was irrelevant — generations one through five being one architecture — and put the fork-work constraint in its proper place as a design consideration rather than a guilt-trip. Even the money got the same treatment: a lease-versus-buy comparison, the Apple Upgrade Program's annual-upgrade model against plain Apple Card financing, so the decision covered not just whether to buy but how — on terms that match how long a machine with this particular job actually stays useful. The output was what the impulse alone could never have produced: solid, rational reasons to proceed. Technically, I haven't bought it yet. But the decision is no longer reaching for justification; it can stand on its own.
Shipping nothing can be the answer
The idea felt obviously right: a panic button — automation that turns "something is wrong, act now" into one decisive action. What followed was less a build than an exploration of what it would actually take: designing the tools and workflows, building them, containerizing the daemon so it could serve other people too, and then exercising the whole thing to see how it held up.
The exercises surfaced a trade-off the design had never confronted. Packaging the container for other users meant generalizing it — and the generalized version left behind exactly the personal automation, the keys and hooks that lived outside the container, that would have made it genuinely automatic for me. The more we built it for everyone, the more it became, for me, basically the manual workflow with extra steps. Scope creep — caught by walking the workflow rather than by reading the code.
So the viability discussion had evidence to stand on: how the tools actually behaved in the exercises, gauged against what we already do today. The determination was that the manual checklist is the real workflow — the automation is parked, built and unshipped, with the reasoning written down for the day we revisit it. Green tests proved it worked. The discussion proved it shouldn't run. Shipping nothing, done deliberately, was the resolution.
Why the banter matters
Notice what none of these episodes required: long messages. The banter isn't decoration; rapid, terse turn-taking is the debugging method, because each turn carries exactly one new fact. And the praise flows both directions — "good catch" gets said by me and to me, because the evidence and the map take turns being the thing that cracks the problem. That reciprocity is what makes it collaboration instead of consultation: neither party is only the question-asker, and neither is only the answer.
What came out of it
A share that mounts every time. A purchase impulse turned into a decision that can stand on its own — not yet executed, but now rational. A bad idea caught before it could do harm. And a small pile of transferable knowledge — some of it technical, some of it habits — that neither of us held in full before we started. That's the bar I'd hold "AI collaboration" to: not answers, but resolutions, with both parties slightly less ignorant at the end than at the start. Preferably over something as unglamorous as an SMB mount. The unglamorous ones are where the method gets proven.