Part 7 of an ongoing series on vibe coding in EdTech.
Nobody asks a vendor what they believe about teaching. Procurement asks about seat cost, data handling, integration with the student information system, and whether the contract renews annually. Those are answerable questions, and none of them reach the thing that will actually shape how the platform feels to work in three years from now, which is the set of assumptions the product team held when they decided what a course is, what an assignment looks like, and which facts about a student a teacher should be able to see. Those assumptions are in the software. They’re rarely in the sales material, and they’re never in the contract.
We don’t ask it of ourselves either. I’ve been in a lot of rooms where a technology decision got made, and I can’t remember one that started with anyone saying plainly what they believed about learning before the options came up. The beliefs were in the room. They were just doing their work quietly, which meant nobody had to defend them and nobody could check them later.
Last June I wrote mine down. The result is a document called Where Design Authority Lives, and as of this month it lives on its own page rather than in the article feed, with a version number and a changelog attached to it. This piece is about why it exists and why it’s versioned, since those turn out to be two different questions.
What did writing it down actually do?
The uncomfortable parts were the useful ones. Writing out how I build things meant admitting that most of my tools run on Google Apps Script, which is to say that I spend a fair amount of energy warning districts about vendor dependency and then hand them something that depends on Google. I have reasons for that tradeoff and I think they’re good ones, but I could hold both positions comfortably right up until I had to put them in consecutive paragraphs. The same thing happened when I got to the section about my own role. If the work I’m describing succeeds, the job I currently hold becomes less necessary, and writing that down is different from believing it in a vague way.
There’s a section near the front about the tribal nations in the region I serve where the most honest thing I could write was that the document can’t carry the weight of that history and that a dissertation is going to have to. Leaving that in was the right call, but it’s the paragraph I’m least settled about.
What all of that points to is the practical case for writing an ethos at all. A commitment that stays unstated is infinitely flexible. It quietly becomes whatever the last decision made it, and because it was never fixed anywhere, there’s no moment where you notice the drift. A commitment on a public page is checkable, by me and by anyone who works with me. That’s uncomfortable in the way that useful things often are.
Why does it have a changelog?
The versioning is the part I want to argue for, because it’s the part that connects back to everything else in this series.
The thing I object to most in vendor relationships isn’t that terms and defaults change. Of course they change. The objection is that they change without anyone having to say so. A setting moves, a default flips, a feature that was included becomes a tier, and the district finds out when a teacher notices something is different. The revision happens, but the record of it doesn’t, which means the arrangement you agreed to and the arrangement you’re living in slowly stop being the same arrangement.
A living document that revises itself quietly is a smaller version of that. If I’m going to keep updating what I believe as the work develops, and I will, then the honest form is dated versions with a note on what changed and why. Somebody who read version 1.0 and comes back in two years should be able to see where I moved rather than having to take my word that I always thought this. It also matters for the doctoral work, where I’ll be citing my own prior position and need it to be a stable thing to cite.
The first entry in the log is the move itself, which changed nothing about the text. That seemed like the right way to start. A changelog whose first line already has to account for an undisclosed revision isn’t much of a changelog.
What it is not
It isn’t a manifesto. The closing line of the document says so directly, and I meant it. A manifesto commits you to a future state and asks other people to sign on. What I’ve written is closer to a working position, which is where I’m standing while the field decides which direction it’s going.
It’s also going to be wrong in places, some of which I already suspect. The section on what I’m pointing toward describes a future where regional groups of educators build and maintain their own tools, and I’ve been careful in the text to say that this is easy to romanticize and harder to actually build. I expect the next few years to press hard on that section in particular, and when it does, the honest move is a new version rather than a quiet edit.
The document is at bradylicht.com/tool-building-ethos. If you have written something like it, or have been thinking about it and have not, I would be interested to hear what yours would say and what you found hard to put down. You can reach me at licht.education@gmail.com.
