Between February and June of 2026 I wrote seven pieces that turned out to be one argument, and I have kept adding to it since. It started as a practical claim: educators and districts can build their own small tools with AI-assisted coding, and they should, because the alternative is renting the same functionality from a vendor who owns the data and sets the price. Each piece after that was a complication of the one before it. Who gets to decide what is automated? What can these tools not do? Where does human judgment have to stay? What does it cost when a well-meaning builder ships something insecure? Who pays for a free tool, and who holds the design authority at the end of all of it?

This page puts the pieces in the order I would read them now, which is not the order they were published. The reading order starts with why, moves to how, and then spends the rest on what the how leaves out. If you only read two, read the first and the last.

The ethos underneath it

The working statement that the whole thread points toward now lives on its own page: Where Design Authority Lives: A Working Ethos. It is a living document with a version number and a changelog, revised as the work develops rather than quietly edited. If you want the position rather than the argument that produced it, start there.

The reading order

1. Vultures, Vibe Coding, and Who Gets to Automate Whom. The why. Mary Doria Russell’s vulture, a freelance analyst who maps a worker’s expertise so a machine can take it over, and the question of who is holding the map when educators build their own tools.
2. DIY EdTech: The Basics of Building Custom Web Apps with AI. The how. A plain walkthrough of getting from a described workflow to a working Google Apps Script tool without learning JavaScript first.
3. What AI-Assisted Coding and GAS Can’t Do. The limits of the how: what the platform constrains, what the model cannot know about your institution, and what nobody should expect a generated tool to decide.
4. Designing for Human Judgement in AI-Powered EdTech. What went wrong with the first version of my own course builder, and the design principle that came out of it: AI in the building, not in the running.
5. The Security Case Against Vibe-Coded EdTech. The hardest complication. A teacher-built tool that handles student data carries risks the builder may not see, and the argument for building has to answer them rather than wave at them.
6. Who Pays for the Free Tool?. The economics. Free is a cost that landed somewhere, and the gift-economy framing I favor for sharing tools has obligations attached that a license alone does not cover.
7. An Ethos With a Changelog. Why a practitioner should write down what they believe about this work, and why the resulting document should be versioned in public rather than revised quietly. It introduces the ethos page linked above.
8. Using Less AI in DIY EdTech. The architecture underneath the ethos. Keyword matching before the model, filtered context instead of whole knowledge bases, local checks for identifying information, and tools that degrade instead of failing when the key expires.
9. Simple Tools That Run Offline, and When to Build Them. One layer further down: a tool with no model and no server at all, built as a single offline HTML file. Why handing the upload step back to a person removed most of the maintenance, when a task fits that shape, and what scattered copies of a file cost in return.

The tools the thread is about

Most of the argument was worked out by building things, and three of them are on this site with setup guides. The FAQ Chatbot is the clearest example of AI in the building rather than the running: it matches on keywords first and only reaches a model when it has to. The Decision Rights Mapper is the ethos piece turned into a worksheet, for mapping who officially holds a technology decision against who actually does. And Behavioral Surveillance Refusal is a browser extension for Canvas that is less a feature than an argument about what a platform should not be allowed to watch.

Where this might go

The thread is not closed, which is why it is numbered as an ongoing series rather than a fixed set. The security piece raised questions about maintenance and handoff that the ethos only gestures at, and the economics piece did not settle what a cooperative owes the districts that adopt a tool it built. I expect to keep writing into those gaps, and the ethos page will pick up whatever the writing settles. If you have built something along these lines, or if the argument breaks somewhere I have not noticed, I would like to hear it. You can reach me at licht.education@gmail.com.