DAY 35 · ANTHROPOLOGY OF TECHNOLOGY AND AI

Anthropology Looks at Technology and AI

The most counterintuitive line in this issue: what a technology finally becomes is largely down to the people who use it — and the people who use it are never one person, but a crowd watching each other.

2026-09-28 · BigCat
A hundred years ago American farmers drove cars home to the farm, jacked up the rear end, took off one wheel and ran a belt from the hub to a saw and a washing machine. The manufacturers ended up redesigning the car to match.

When was the last time a piece of software changed something you do?

Maybe you deleted an emoji before sending a message because it looked careless; maybe you rewrote a headline halfway through into something blunter, because the blunt version was seen by more people last time. Nobody told you to. You could not say who made the rule.

There are two ready-made stories about technology and people. One says technology drives society: get a new machine and people have to become whatever it requires. The other says technology is only a tool, and everything depends on how people use it. The research below says neither is enough — machines and the people who use them are made together, and that "together" has observable steps.

// 01

Farmers jacked up the back of the car to drive a saw, and the makers redesigned the car to match

Rural America in the early twentieth century. When cars first reached the farms, the use the manufacturers had in mind was transport. Farmers had other ideas: jack up the rear end, take off one rear wheel, bolt a pulley to the hub, run a belt, and you could drive a saw, a water pump, a washing machine. What they had bought, as they saw it, was not a car but an engine that could drive itself out to the field.

Ronald Kline and Trevor Pinch went back through this history in 1996. Makers at first treated these uses as misuse; but once enough people were doing it, parts dealers began selling conversion kits and the manufacturers adjusted their designs and their advertising to suit. The people who use a technology have a hand in what it becomes — not by persuading the designers, but by using it that way, in numbers.

The thing has a name: interpretive flexibility. The same object is not the same object to different groups, because the problem each wants solved is different. Pinch and Bijker's 1984 bicycle case puts it more clearly: the nineteenth-century high-wheeler was sporting equipment to one set of young men, coming off it included; to other people it was a dangerous thing they could not get onto at all. The argument of the day was not "which machine is better" but "which problem is the machine for". The pneumatic tyre was at first thought ugly, a needless attachment, until bicycles fitted with it won races and it was redescribed as "the way to go faster", at which point the argument closed. They call that settling closure: not everyone has been persuaded; the framing has simply stopped being challenged.

One object (the early car) Town buyers: how to go faster, look right Farmers: an engine that drives to the field Roads and insurers: who carries a crash Closure one use written into design and regulation
The argument is never about whether the machine is good; it is about which problem the machine is for. Closure is that question being shut — afterwards, whoever proposes another use carries the burden of proof.

The opposing view deserves its strongest form. Langdon Winner argued in 1980 that a system which must be guarded for the long term, with layered authorization and catastrophic failure costs, pushes whoever runs it towards centralization and strictness, whatever kind of organization those people would have preferred. The defensible position is in between: uses are fought over, but not everything is open to the fight. Evidence strength should be stated too: this line of work is historical case reconstruction, not repeatable experiment, and the criticism it most often draws is that which groups count as "relevant" is drawn by the researcher after the fact, which makes it easy to end up with a story that happens to hang together.

// 02

You cannot interview a recommender system, but you can watch a roomful of people live with one

The old way to do fieldwork is to move in. But what if the thing you want to study is a recommender system? It does not talk, it has no village square, and even with the code in hand you cannot read off why it gave you that song yesterday.

Nick Seaver's answer was to move in with the people who make one, spending years among developers of music recommendation and publishing a book on it in 2022. The first conclusion is deflating: the "algorithm" is not a thing — it is models, metrics, quarterly targets, rules left by an engineer who has since left, plus a roomful of people's guesses about what listeners want, and nobody holds the whole picture. The second matters more: these developers increasingly described what they did as keeping people around, so metrics for dwell time and return visits floated up and became the measure of good work. He reaches for the metaphor of the trap: not a claim that these people are up to no good, but the observation that once "holding on to people" becomes a number you can read daily, every small choice quietly lines up with it.

Does the same set of metrics produce the same behaviour somewhere else? Angèle Christin spent four years in the field, interviewing more than a hundred journalists in web newsrooms in New York and in Paris. The dashboards on the two sides were much alike; what they meant was not. In one, a live traffic screen sat in the office and clicks were tied to evaluation and to whether the next commission came; in the other, everyone said in public that they paid no attention to such things, and privately checked all day. Her conclusion: an algorithm is not a machine that grinds every place into the same shape; behaviour grows towards whichever evaluation system it lands in and whoever's authority it is enlisted to support. This is comparative ethnography — two countries, one industry — so generalize with care; but it does rule out the simple story in which technology arrives and homogenizes.

The user side is the same. In a 2015 study of forty people, more than six in ten did not know their feed was being filtered at all; the posts they never saw were attributed to something else — that person probably doesn't want much to do with me. People build their own accounts of systems they cannot see, which researchers call folk theories.

So the ethnography of algorithms is really the study of relations: who maintains the thing, who is evaluated by it, who works around it. Which carries a hard methodological conclusion — ask a user "what do you think of these recommendations" and what you get back is a folk theory. To see what it changed, watch what people do, not what they say about it.

// 03

Automation rarely takes a whole job; it takes a few of the actions in the middle, and the rest gets rearranged

In the 1980s Shoshana Zuboff watched this happen in an American pulp mill. The older workers had judged with their bodies — a handful of pulp squeezed, sniffed, sometimes chewed, and they knew whether the batch was right. After computer control came in they were shown into an air-conditioned room with a row of numbers on a screen, and some would slip back down to the floor to put a hand on the equipment, because they did not trust the screen. She named the process informating: the machine does not merely take the actions over, it turns the whole process into information that can be watched, stored and compared. So what changes is not only who does the work but whose judgement counts — the old hand's accuracy, the kind he cannot give reasons for, does not exist in the form of numbers, so in the new setup it has no place. This is the same sort of thing as the locally grown feel for a situation in the issue on seeing like a state.

In 1983 the cognitive psychologist Lisanne Bainbridge wrote a very short paper called "Ironies of Automation". The irony: automation takes the easy part first, and what it leaves the human being is precisely the two hardest things — watching a system that almost never fails for hours on end, and taking over in the few minutes when it does. But a person watching something that does not fail will drift, and unexercised skills go stale; by the moment the takeover is required, that person is in their worst condition.

What gets missed more often is the work that grows. Benjamin Shestakofsky published a study in 2017 based on nineteen months of participant observation inside a software company: rather than reducing the demand for people, the software generated two new kinds of work — one standing in for the software, with humans matching by hand what the algorithm could not, and one helping users live with the software, explaining the awkward decisions it made. In 2019 Mary Gray and Siddharth Suri named a large adjacent territory ghost work: labelling, reviewing, correcting, paid by the piece, with output that looks as though a machine made it. What these jobs have in common is not that they are hard; it is that they are not on the org chart.

Macro numbers need care. A much-cited 2013 estimate put about 47% of US employment at high risk of automation; a 2016 OECD working paper recomputed it by decomposing jobs into tasks and found an average of about 9% across twenty-one countries. The difference is not arithmetic but units: the first asks whether a whole occupation can be replaced, the second asks which tasks within it can. Which unit is right depends on whether a job comes apart — and what the section on the farmers and their jacked-up cars describes is precisely that this, too, is fought over.

That lets "AI and the meaning of work" land somewhere more concrete: meaning is not only about whether there is work to do, but about which part of what you do is counted as skill. When judgement moves into the system, the most valuable stretch of craft may neither disappear nor be acknowledged — it becomes the backstop: you have to be there when it fails, and the rest of the time it does not appear in the job description or the review. That is something you can check: what the new job descriptions say, which rows are on the evaluation sheet, whose name turns up in the post-mortem.

🎒 Scenes · BigCat

🌀 Crossing over · Connections beyond the field

Questions to sit with

If uses are fought out by users, how much weight is left in "the designer's intent"?
Those farm uses could feed back into the design because the designers could not stop them — once the car was sold it was out of reach. For a system that can be changed at any moment and whose uses are all visible from the back end, that premise is much weaker.
In an ethnography of algorithms, who exactly are the "people" being studied?
Developers, users, and the people filling gaps by hand behind the scenes. The trouble is that these three groups rarely meet, and each sees only one face of the system. Fieldwork's old method assumes the villagers run into each other, which does not hold here.
When a machine takes a task over, have the people who used to do it lost a skill?
At least two readings. One is rustiness: the actions are still there, just less practised. The other is that "what counts as skill" has been redefined — the pulp mill's unarticulated accuracy stopped being an asset after digitization. The first can be practised back; the second cannot. To tell them apart, watch which one pay and evaluation follow.

Further reading