Turning intelligence into work

In 1882, a ship’s captain nearly froze to death in the tropics.

The Dunedin was carrying frozen meat from New Zealand to Britain. In the tropics, cold air wasn’t circulating properly through the hold. The cargo was at risk.

Captain John Whitson crawled into the refrigerated chamber and cut openings to improve the airflow. He became so cold that the crew had to haul him out and revive him. The ship reached London with almost all its cargo intact.¹

Refrigeration made the voyage possible. Delivering the meat required people who understood the machinery, the cargo, and what to do when the system failed. Building a trade meant being able to repeat the journey.

Putting AI into an organization exposes a similar gap between what the technology can do and what people can depend on. Cheaper execution makes more work possible. How an organization directs, checks, and takes responsibility for that work determines how much it can actually take on.²

By late 2025, I couldn’t remember the last time I’d written a non-trivial line of code by hand. I was still engineering every day.

The work had moved. I was holding the system in context, describing what should happen, working through plans with agents, reviewing changes, and catching the edge cases they missed. The path from an idea to something I could test had shortened. Implementation took up less of the work; deciding what to build and knowing whether it worked took up more.

I expect versions of the same shift in other professions, with different limits and different consequences when the work is wrong.³

The prospect of cheaper custom work is what excites me most. Specificity has been expensive: analysis for this decision, a tool for this team, research into this particular exception. As that cost falls, some problems become worth the effort of solving.⁴

Imagine a finance team that wants to understand why a small category of expenses keeps exceeding its budget. An agent could gather the records, compare them, and flag exceptions, making the investigation cheap enough to do regularly. The amount at stake may never have justified a dedicated tool.

The team still has to decide which records the agent can access, what counts as an exception, and who can act on the findings. The reviewer needs to check even a plausible explanation against the underlying transactions. Someone has to own the decision that follows.

A firm is not a prompt window. Its work sits inside relationships and commitments. Generating a report is one part of answering a question for someone who will rely on it. This is what predictions about the end of knowledge work can leave out: the context that makes the work useful and the responsibility for what happens after it’s delivered.

A human-agent organization puts humans close to intent and accountability.⁵ Agents can help frame the question, propose alternatives, and check results as well as execute. The division of tasks can change as their capabilities improve. People still have to choose what to delegate, what evidence is sufficient, and who answers when the result affects someone else.

Building in healthcare has made me attentive to those decisions. Software has to fit into regulation, institutional complexity, and workflows that affect real patients. Better reasoning inside a model doesn’t settle who is entitled to see information or authorized to act on it. The system has to enforce those boundaries.⁶

In the expense example, an agent could assemble a small application that brings the relevant transactions, supporting records, and proposed explanations into one review screen. The reviewer could inspect an exception and route it to the person responsible, using the company’s existing access controls and approval process.

I expect more software to fit the task this way, without requiring the team to move all its work into a new application. As the questions change, the interface can change with them.

The underlying systems still have to maintain accurate records, enforce permissions, and carry out approved actions reliably. Existing software can supply the tools these applications use. I expect durable value to remain in services that handle institutional complexity and carry work through to completion, even as their interfaces become easier to replace.

Product taste still matters. Someone has to decide which details deserve attention, which defaults make sense, and how a person stays oriented as the system does more for them. A custom interface that hides the evidence or makes every exception look equally urgent makes review harder.

And the reviewer needs enough expertise to evaluate what they see. Someone clicking “approve” on work they cannot judge is a fragile foundation for an organization.

The production work being compressed has also been how people learn. Junior colleagues gain judgment by doing work, getting it wrong, and having someone more experienced help them see why. If agents take over more of that path, organizations will have to develop the expertise they still depend on for review and direction.⁷

I don’t have a finished answer to that. Giving people context earlier and having them examine failures may help. Teams will have to find out whether those practices develop judgment as effectively as doing the work did. Better models won’t relieve organizations of the responsibility to develop the expertise they demand.

The organization needs to learn from that work too. A correction that stays in one person’s chat history leaves everyone else to discover the same problem for themselves. It needs a way into the team’s tools, standards, or review practices. Permissions, shared context, and feedback are part of how an organization builds the capacity to take on more work.

The whole workflow has to improve. Faster generation is useful only if the time isn’t lost again in checking, rework, or a handoff no one owns. The standard should be whether someone gets a better result, with a level of effort and risk they can accept.

After the Dunedin reached London, building a trade required marketing and insurance arrangements alongside the machinery and ships. The Dunedin itself completed nine more successful voyages.⁸

An organization using AI has to choose which new problems to take on, assign responsibility, and build practices that let it deliver again. What it learns should improve the next attempt: better tools, clearer expectations, or people better equipped to judge the work.

Whitson helped bring one cargo safely to London. The larger possibility was a trade people could build their livelihoods around. A new capability changes what people can attempt. Making it dependable changes what they can plan on.

Tohu Whenua, “The first frozen meat shipment from Totara Estate”. Account of Whitson’s intervention and the cargo’s arrival in London. ↩
Technology and organization have to develop together. Erik Brynjolfsson and Lorin M. Hitt, “Beyond Computation: Information Technology, Organizational Transformation and Business Performance”, Journal of Economic Perspectives, 2000, draw on case studies and firm-level evidence showing that organizational investments strongly influence the value of IT. This earlier research supports the importance of organizational change; it does not establish which AI operating model will succeed. ↩
The productivity evidence is mixed. Zheyuan Cui and colleagues, “The Effects of Generative AI on High-Skilled Work”, 2025, report more completed tasks when pooling three developer experiments, though individual experiments were noisy. Eleanor W. Dillon and colleagues, “Shifting Work Patterns with Generative AI”, 2025, revised November 2025, find time savings on email but no detectable change in task quantity or composition in a six-month experiment across 66 firms. Joel Becker and colleagues, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 2025, find that 16 experienced developers took longer with AI on tasks in familiar repositories. These studies cover particular tools, tasks, and periods. My engineering experience is not a universal productivity estimate. ↩
David H. Autor, “Why Are There Still So Many Jobs? The History and Future of Workplace Automation”, Journal of Economic Perspectives, 2015, explains how automation can replace tasks while also complementing labor and expanding output and demand. That gives a basis for expecting some previously uneconomical work to become worthwhile. It does not guarantee that new demand offsets displacement for every occupation, or that people affected by the transition benefit equally. ↩
This framing draws on Dan Shipper’s “After Automation”, Every, May 2026, which credits Kieran Klaassen with the “human sandwich”: people framing work and judging results around agent execution. The argument here allows agents to participate in framing and checking too; human responsibility need not imply a fixed sequence or exclusive ownership of particular cognitive tasks. ↩
NIST’s Artificial Intelligence Risk Management Framework 1.0, 2023, calls for defined responsibilities, training, and policies for human-AI configurations and oversight, particularly under GOVERN 2 and GOVERN 3.2. It is a voluntary framework for managing risk, not evidence that adding an approval step guarantees correctness or that every AI action requires human review. ↩
Lisanne Bainbridge’s “Ironies of Automation”, Automatica, 1983, describes systems that leave people responsible for difficult interventions while reducing the practice through which their skills are maintained. She also asks whether later generations of operators will acquire the expertise of those who learned through manual work. Her subject is industrial automation; the connection to apprenticeship in AI-assisted knowledge work is an application of that concern, not a measured finding about today’s junior professionals. ↩
New Zealand Ministry for Culture and Heritage, “First frozen meat shipment leaves New Zealand”. Covers the marketing and insurance arrangements supporting the trade and the Dunedin’s nine subsequent successful voyages. ↩

Footnotes