Part 11 of an ongoing series on vibe coding in EdTech.

I’ve been getting more requests for tools lately. Some come from districts and some from teams I work alongside, and most of them come with good intentions and a real problem behind them. That makes sense. Now that a working tool can come together in an afternoon, people bring ideas that would have been dropped a few years ago because nobody had time to build them. I’ve spent a good part of this series encouraging exactly that, so I’m partly responsible for the line at my door.

Take a dashboard as an example. Say a team wants one view that shows where things stand across their work, so the people making decisions can see it without chasing anyone down. Someone has probably already been trying to piece it together by hand, and the request is to make that easier. My first instinct with a request like that is to start sketching, because I like building things and because I can usually see how it would work before the conversation is over.

That instinct is what I’ve been trying to check lately. For a long time, my reflex when I noticed a repeated task was to ask whether I could automate it, and the answer was almost always yes. I’m less sure now that it’s the right first question. Some of what a dashboard promises to show is easier to learn by asking people, and the asking does things the dashboard can’t, like letting someone explain what a number leaves out. A new screen also doesn’t change how a decision gets made. If people were deciding by judgment before the dashboard, they’ll likely keep deciding by judgment after it, now with one more thing to keep updated.

So I’ve been trying to push back more, starting with myself, and to ask whether something needs a tool before I ask how to build it. I’ve been reading Ivan Illich to help me think it through.

What changed when building got cheap?

Until recently, the hard part of a custom tool was building it. A request like that dashboard would have needed a developer or weeks of someone’s evenings, and most ideas never got past that point. It was a crude filter, but it did some work, since only the requests someone cared about enough to fund or sit with ever got built.

AI-assisted coding has mostly removed that filter. I’ve spent ten parts of this series arguing that’s a good thing, and I still think it is. But the cost that went away was the cost of building. The cost of deciding whether to build, and of living with the result afterward, didn’t go anywhere. Part 3 was about what happens when that decision gets skipped partway through a build and the scope keeps growing. Part 9 was about handing a step back to a person so a tool could stay small. This one goes a step earlier, to the moment a request arrives, before anyone opens an editor.

What does Illich mean by a tool?

Illich was a priest and social critic, best known for Deschooling Society, and he wrote Tools for Conviviality in 1973 out of seminars at the center he helped found in Cuernavaca, Mexico. He was writing about medicine, schools, highways, and housing, not district software, so applying him here is my borrowing. A fair amount of it carries over, though, partly because his definition of a tool is much wider than mine usually is.

For Illich, a tool is any “rationally designed” device, “be they artifacts or rules, codes or operators.” He counts institutions and procedures alongside hammers and power plants, and he says outright that “school curricula or marriage laws are no less purposely shaped social devices than road networks.” I made a similar argument in Thought Technology, that the frameworks and metaphors we think with are tools that carry arguments of their own. If that’s true, then a weekly check-in, a shared doc, and a phone call are tools too. The question a request raises is not simply whether to use a tool. Instead, it’s which tool, and who it works for.

Illich’s answer to that is the distinction the whole book turns on. Some tools he calls convivial: tools that people can pick up and use for their own purposes, as often or as seldom as they like. Others he calls manipulative or industrial, tools that set the terms for the people using them. He puts the difference most simply when he says that “people need new tools to work with rather than tools that ‘work’ for them.” He also describes what happens when a tool grows past the point where it helps. Beyond a certain scale, he writes, an enterprise “first frustrates the end for which it was originally designed.” Most of the tools I build will never get big enough to threaten anything, but I’ve built a few that frustrated their own purpose, where keeping the tool running took more time than the task it replaced.

What would the dashboard actually do?

Back to the dashboard. Its job is to put information in front of the people who make decisions. Illich has a sentence that I keep coming back to here: we “confuse data for potential decision with decision itself.” A dashboard holds data for a potential decision. The decision still happens somewhere else, usually in a conversation, and usually based on things the dashboard can’t hold, like what someone said in a hallway or what a person’s week actually looked like.

He goes further than that. “Overconfidence in ‘better decision-making,’” he writes, “first hampers people’s ability to decide for themselves and then undermines their belief that they can decide.” I don’t think one dashboard does that to a team. A series of them could, though, if every question about how the work is going gets routed to a screen instead of to the people doing the work. A dashboard about work can also drift into being a dashboard about people without anyone intending it, and that’s a different tool with different stakes.

The alternative Illich points to is surprisingly plain. His main example of a convivial institution is the telephone, because it “lets anybody say what he wants to the person of his choice” and nobody upstream gets to define what’s said. That’s the tool a team already has when it wants to know where things stand. Calling someone, or stopping by, or setting aside fifteen minutes of a standing meeting, isn’t the absence of a tool. It’s an older one, and one that lets the person on the other end explain the number instead of being reduced to it. It also passes a test Illich sets for convivial tools, which is that “their existence does not impose any obligation to use them.” Nobody has to keep a phone call updated.

Why does “better” keep winning?

If the conversation already works, it’s fair to ask why requests like this keep coming. Part of the answer is that people are stretched, and a tool promises to give some time back. I take that seriously. Another part is something Illich describes in his chapter on obsolescence, where “the ‘better’ replaces the ‘good’ as the fundamental normative concept.” A process that is good enough gets replaced because a better one can be imagined. He adds that “the commitment to the better at any cost makes the good impossible at all costs,” which is stronger than I’d put it, but I recognize the pattern.

What’s changed is that the better version can now be built before anyone has asked whether the good version was failing. When building took weeks, that question got asked by default. Now it has to be asked on purpose, and I’m usually the person in the room who can either ask it or skip it.

Who decides what a tool means?

This is the uncomfortable part for me. Illich writes that industrial tools “allow their designers to determine the meaning and expectations of others.” It’s easy to read that as a line about vendors, and I usually have. But when I build a tool for a team, I’m the designer. I decide which fields exist, what counts as done, and what the dashboard treats as normal, even if I do it with good intentions and an open config tab. In Part 10, I wrote about a district whose changes to a tool I built still had to go through me. That’s a small version of the same thing.

It’s also awkward to write a piece about not building when building tools for districts is part of my job. I don’t think the answer is to stop. Illich is clear about that too, warning against “falling into the equally damaging rejection of all machines as if they were works of the devil.” But the more I build, the more I think the most useful thing I can bring to a request is the question of whether it needs me at all.

What do I ask now?

I’ve started keeping a short set of questions for when a request comes in. They aren’t a checklist, and Illich would object if they were, since he insists his own criteria are to be read as guidelines, “not as a set of prescriptions which can be mechanically applied.” They’re more of a habit I’m trying to build:

1) What decision is this supposed to support, and who makes that decision now?

2) What does the team already have, like a shared doc, a standing meeting, or data that’s already collected, that does part of this?

3) Would people still be free to ignore it, or would it become one more thing they have to keep updated?

4) Who will maintain it, and who gets to change it?

5) If we ran the manual version on purpose for a month, what would we learn about the work?

The last one is the question I’ve found most useful. Doing something by hand, deliberately, tends to show what the work actually involves, and sometimes it shows that the problem was never the tracking.

Who carries the manual version?

None of this means the manual version is free. Illich makes that point himself, in a passage that’s easy to skip. “Industrial societies remain viable,” he writes, “precisely because women are there to perform those daily tasks which resist industrialization.” The work that doesn’t fit a tool still has to be done by someone, and it tends to land on the people whose work is already least visible. In a school or an agency, that’s often the coordinator or the support staff member who just handles it. Choosing a conversation over a dashboard is also choosing who has those conversations, and how much of their week they take up.

So I don’t think the answer is to stop building, or to send every request back with a note to just talk to each other. What I’m trying to do is keep the question of whether open a little longer before the question of how takes over, and to be honest about who carries the work either way. I’m not always good at it yet, since I still reach for the sketch first.

If you’ve been on either side of a request like this, asking for a tool or being asked to build one, I’d like to hear how it went and whether the tool ended up being the answer. You can reach me at licht.education@gmail.com, and there are more tools, articles, and resources at bradylicht.com.