The Coworker Metaphor Isn't a Blueprint

Last September, I argued that AI works best as an amplifier, not a collaborator. Eight months and a handful more shipped apps later, I still believe that.

What I didn't expect was how much the metaphor would turn out to matter.

I'm currently following an executive program on AI and technology strategy at Norwegian School of Economics (NHH). This April six of us — plus eight to twelve AI agents distributed across our roles — had one day to build a company from scratch. Problem statement, customer interviews, working prototype, investor pitch were all delegated to our AI agents. The course's governing metaphor was to use AI as coworkers. Professor Alexander Lundervold, who runs the program, recently titled a podcast episode Når KI blir mer enn et verktøy — when AI becomes more than a tool. In other words, that positioning was deliberate.

The argument I made last September pushes against that positioning somewhat. Not as a rejection of Lundervold's framing — it is a serious framing from a serious place — but from a different angle. When AI is treated as a coworker, we tend to build dialog systems: chat interfaces, persistent personas, turn-taking rhythms. That pattern correlates with what the METR study measured when sixteen experienced developers came out 19% slower with AI assistance — despite everyone, including themselves, predicting a speedup. Cal Newport called the mechanism cybernetic collaboration. I proposed a different pattern, cybernetic amplification, where AI removes mechanical friction so human attention can stay on higher-order work.

What follows is a close-to-one-year retrospective plus a take-out from the course sprint. The short version: last September's argument still holds, but it got more interesting. The language we use for AI shapes the architecture we build. And sometimes the two drift apart in revealing ways.

The Sprint, in 150 Words

The case handed to us: You are a group of six executives, you have one day, you have to use a custom AI interview tool to establish six different startup-pitches, decide on one, then build a company in seven hours based on the chosen pitch. We identified a problem in Norway's local electricity grids, ran synthetic customer interviews, built a two-sided flexibility-market platform, prototyped a working MVP, and presented a pitch to a VC-panel judging all the concepts. Our team based our approach on moat logic borrowed from Eirik Sjåholm Knudsen's When Easy Becomes Hard with AI.

Five of us took C-suite roles: CEO, CSO, CTO, CCO, CPO. Each had one to three AI agents reporting into them. I took the sixth role, one of six the course had designed into the exercise: CNHRO — Chief Non-Human Resource Officer. HR for the AI team. -How was that supposed to play out?

The title was given. How to fill it was left to whoever sat in it. Other teams had their own CNHRO. None of us ran the role the same way, and — as I realised afterward — not every interpretation scaled.

That's the reason I'm writing this post.

What "Coworker" Promises — and What It Invites

The coworker metaphor does real pedagogical work. It lowers the psychological barrier to adoption; people who are uncomfortable operating a tool are often fine asking a colleague. It invites organizations to think about AI in role terms, which surfaces good questions about responsibility and audit. And it's almost right. Almost.

The problem is what the metaphor implicitly imports. A coworker is a peer. A coworker remembers yesterday's conversation. A coworker absorbs context, pushes back, participates in the back-and-forth of shaping a decision. Build systems around that promise and you get dialog interfaces, persistent personas, continuous conversation as the primary interaction pattern. The exact pattern METR measured.

The problem runs deeper than imprecision. Calling an LLM session a coworker imports peer-relationship properties — memory, interests, accountability, social standing — that the session doesn't possess in any operative way. The metaphor smuggles those properties in at the interface level, and the interface shapes the work.

The uncomfortable finding from the METR study wasn't that AI made the developers slower. It was that it made them slower while feeling faster. The developers themselves predicted a 24% speedup, but in reality the work experienced a 19% slowdown. Afterward, they still believed they had been sped up by 20%. The mechanism isn't hostile — the conversation is pleasant, the experience feels productive, the attention drift is invisible to the person drifting.

That's the failure mode coworker framing invites: that we end up with attention fragmentation as a result of the collaboration. Nothing about it might necesseraicly look broken in the moment. The cost only shows up when you measure outcomes against a control group.

What I Actually Built Inside That Role

And yet. The course spoke coworker. What I built inside CNHRO was something else.

I ran it as a supervisor loop. Every 45 to 60 minutes I made a reconciliation pass: read everything the five C-roles and their agents had produced since the last check, surface contradictions between deliveries, land decisions that unblock parallel work. The other agents didn't negotiate with me. They had no clue they were being supervised. They delivered artifacts; my agent (and me) read the artifacts; we moved on.

The artifact that somewhat helped us land the sprint was a small Python tool my agent built mid-run — roughly 250 lines, rendered as a linked-decision graph in HTML. We called it the decision-web. Instead of landing six contradictions through the six distinct and separate conversations the other C-level executives agents were running, the tool let us see them all at once and land them in a single structured pass. Contradictions became nodes. Dependencies became edges. Decisions became annotations.

Even the course's own AI interview tool — the one that probed our problem statements and later adversarially critiqued our pitches — was designed without memory between sessions. Each pitch had to stand on its own; the critic had no recollection of the last team's pitch or the last version of ours. That design choice implicitly rejects the coworker metaphor. A coworker would remember. This tool deliberately didn't. The architects knew something about what they were building, even as the surrounding language pulled the other direction.

Lundervold as one of the architects of the AI-interviewer seem to make the same distinction. When describing what leaders should think, he reaches for coworker. When he describes solutions being built — like the AI-interviewer or as the case in the podcast, an AI-first strategy process that ran eight hundred stakeholder interviews through a language model — he calls it en forsterker inn i prosessen, an amplifier into the process.

Look past the language and this version of the role is closer to amplification than collaboration. Agents produced parallel mechanical output — briefs, research syntheses, prototype code, pitch visuals — at a volume one person couldn't generate alone. The human held attention on reconciliation, direction, and what to keep. The back-and-forth dance METR measured was structurally avoided, not because anyone argued against it, but because the only way six executives could land one coherent company in seven hours was to batch and reconcile rather than converse.

Here's where I have to be honest about the data point. Under a shared metaphor, groups built wildly different architectures. The language was common across the room; the architecture wasn't. I reached for amplification because it's the pattern I had already built elsewhere — it was the muscle memory I brought with me from a solo run of making stuff and shipping apps. Others, filling the same slot, reached for something else.

So here is the rename worth making explicit: metaphor versus architecture. Metaphor is what we say the system is. Architecture is how the system behaves when real work runs through it. Under one shared metaphor you can get radically different architectures, depending on what patterns the people in the room already know how to build.

I believe that this gap isn't a pedagogical quirk, but a signal.

Why Metaphor Still Wins (Even When Architecture Works Around It)

If architecture is what runs in production, why bother with metaphor at all? Because metaphor wins the next system.

Architecture determines what happens today. Metaphor determines what you reach for tomorrow. The drift is cheap in the moment and expensive in the next build.

An organization that keeps saying "coworker" will, when it builds the next AI-supported process, reach for the coworker shape. Chat interface. Persistent persona. Conversational affordance. Even when the last working system used batch-and-reconcile, the language pulls design back toward dialog. Teams retain what they said they did more than what they actually did. I have watched this happen in my own work, in miniature, when the language I use about a feature starts to shape what the next feature looks like.

This also names the question the sprint left me with. Why did different people in the same CNHRO slot reach for such different architectures? Candidates, in no particular order: the coworker metaphor pulled some toward peer-mode and treating agents as colleagues rather than deliverable-producers; some treated CNHRO as a sixth C-role rather than a supervisor layer, adding horizontal rather than vertical capacity; and some, like me, had a prior pattern to reach for and defaulted to it whether or not it was the right one. The metaphor alone didn't determine the outcome. But it shaped the set of architectures people reached for when the slot was open.

This matters because the failure modes of coworker and amplifier architectures are genuinely different:

• Coworker failure mode: attention fragmentation, hidden productivity loss, experience that feels collaborative while outcomes degrade.
• Amplifier failure mode: higher demands on human higher-order judgment, potential to overload the few people who can actually do that work, harder on-ramp because the supervisor layer has to be built.

The point isn't that one is correct and the other is wrong. The point is that picking the metaphor is picking the failure mode you will get — and the failure mode that will show up in the next project, and the one after.

Cognitive Load Moves Up, Not Out

The point I made most clearly in the original post was that amplification is intensely demanding work. Not the pleasant experience of reduced cognitive load. Something closer to the opposite: when AI handles the SwiftUI syntax, the syntax questions disappear, but what fills the vacuum isn't rest. It's the product-level question that syntax used to buffer you against — what constraint makes this app valuable? That question is harder. It has no correct answer you can look up. It's the kind of question that previously only surfaced once a month, when you sat down to plan. Now it surfaces every twenty minutes, because nothing is in the way.

What the sprint confirmed is that the same mechanic replays at team scale. Agents took on role-execution load — drafting, researching, prototyping, visualizing. Some of us inherited reconciliation-and-direction load. Contradictions that would have stayed latent for a week in a slower project surfaced every forty-five minutes, in a stack, demanding a decision. Not easier. Possibly harder. Solo or team, amplification doesn't reduce cognitive load. It relocates it upward.

This is where the coworker framing becomes actively misleading. Coworkers, in the ordinary sense, offload. Your colleague takes the task, returns it done, and your load goes down. If leaders adopt AI through the coworker metaphor, they will expect relief. What they will actually get is relocation. When the experience reads as demanding rather than relaxing, the default response will be to add more AI — more coworkers — rather than to recognize that load didn't disappear. It moved up a level.

The bottleneck under amplification isn't the AI. It's the human's capacity for higher-order thinking. That capacity isn't automatically present just because lower-order friction is gone. Building it is sometimes the real work.

One honest caveat to the original post. Cybernetic amplification was grounded in solo practice. One person, deep focus, eight App Store apps over a summer. The sprint is a different shape: multi-person, one concept, parallel agent execution on shared artifacts. Both are forms of parallelism, but on different axes. Solo amplification scales concept-breadth. Sprint architecture scales role-coverage. Neither automatically generalizes to the other. If a Norwegian bank tries to apply amplification thinking to AI adoption, the right answer isn't automatically a CNHRO-shaped one. It depends on which axis the actual work runs on.

What the Metaphor Is Good For

I don't want to overstate the critique. Coworker framing isn't useless. It's almost right, and almost right is sometimes the best language can do when a technology is this new and this unevenly distributed across organizations. The metaphor lets leaders talk about AI in role terms, which is often the only vocabulary an organization has for new capacity.

But if metaphor wins the next build, metaphor is a design choice with stakes. That's the shift worth making: not treating language as a label to watch, but choosing it the way you'd choose any other load-bearing decision — knowing what it pulls you toward.

The practical form is simple enough. Name the architecture you want, then pick language that pulls design toward it rather than away. If you want amplifier behaviour tomorrow, don't call it coworker today. If you want dialog-first collaboration, lean into the language that produces it. When metaphor and architecture drift anyway, that's information — not license to tolerate the gap. The move is to close it.

The rename isn't hard. A good distinction names an axis no one drew. Coworker versus tool is a binary that collapses too fast. Metaphor versus architecture is an axis you can actually move along — at different rates, in different directions, with eyes open.

The real question was never "which metaphor is correct?" Both are wrong in the way all metaphors are wrong. The real question is which failure mode your organization can afford — and whether the language you choose will pull your next system toward it or away from it. Pick deliberately.

---

What does an organization look like when it has chosen amplifier language and built amplifier architecture — deliberately, with both aligned? I don't know yet. The year ahead may show. For now I've seen a room where the metaphor was shared and the architecture wasn't, where the pattern that scaled was the one somebody brought with them. That gap — between what we say and what we reach for — is the one I've started watching.

---