← Glossary

Brains in Jars

Dr. Cat Hicks's name for organizations that value software developers purely as disembodied, interchangeable cognition, treating engineers as fungible machine parts while ignoring the social and human context that real problem-solving depends on.

Context

The metaphor comes from Dr. Cat Hicks, psychologist for the humans in tech and author of The Psychology of Software Teams, who discussed it on Episode 40 of the ADI Pod. She started using it to describe an odd pattern she kept running into in organizations and studies. Software engineers are highly valued and constantly in the headlines, yet developers kept telling her they weren’t seen as whole people. The organization cares about their thinking, but “in a very specific way that’s kind of bizarre,” stripped of its humanity. A leader looks at the engineering team and sees fungible parts, “little machine parts or little factory parts.”

Why It Matters

Cat’s sharper point is that brains in jars isn’t only dehumanizing, it’s wrong. It isn’t an accurate model of human cognition or of how innovation happens. The big leaps in a solution space come from social cognition, people building on each other’s solutions. “This brains in jars thing is never what produced really good software actually. We just kind of act like it on the business side.” Shimin’s counterexample was Bell Labs, which ran on collaboration and flat hierarchy, not lone geniuses in basements.

The metaphor sits next to the 10x engineer stereotype, which Dan asked about directly. Cat’s take is that the lone-genius story persists because it does something for individuals: when you’re young and in an unfair circumstance, believing you can grind it out alone is a survival strategy. But its costs are “so much bigger than we like to see,” and the healthier ways of working “win out evolutionarily speaking across groups of people.”

The AI-era version should feel familiar. An org that already sees developers as interchangeable cognition is the one most tempted to see agents as a drop-in replacement for that cognition, and the one least likely to notice the social work (shared mental models, review, mentoring) that the swap quietly deletes.

Example

The way out is changing which stereotypes are active in the room. Dan’s approach on teams is jokes, open vulnerability, and the McCarthy core-protocols check-in ritual: pick at least one of mad, sad, glad, or afraid, with no explanation required. Cat’s read is that nobody actually believes developers aren’t human. Brain-in-a-jar treatment happens when certain stereotypes (“engineers are cold”) get foregrounded. When someone with technical credibility jokes or says “this doesn’t feel great today,” they activate different ones, and signal that none of it negates their credibility as an engineer. In her words, those moments are “actually parts of the problem solving we do.”

Related Episodes