The person who knows the problem can now build the tool

In the early 2000s I taught languages, and my pupils needed more practice with vocabulary and verb endings than lessons allowed. So I built them a tool. I learnt enough HTML to make it in Dreamweaver, then published it to a web host over FTP, a phrase that meant little to most teachers then and means little to most now.

I was very much the exception, and it had nothing to do with being a better teacher than my colleagues. I happened to have a rare combination: I understood the learning problem, and I had picked up enough technical knowledge to build an answer to it. Very few teachers in the country could do both back then. The people who knew the problem best almost never got to build the tool.

So schools did what most still do. They went to the marketplace and bought the nearest thing: a quiz platform here, a homework app there, a tool that worked well for the English department but got ignored by the scientists. Over the years these get bolted together into an approximation of what teachers needed in the first place. The result is familiar. Tools that don't talk to each other, pupil data spread across a dozen suppliers, logins nobody can keep track of and renewals that always seem to arrive after your budget submission. And the critical decisions about all of it tend to sit with people who are under pressure to cut budgets, or, more often than not, who are expert in technology rather than in teaching.

That has changed. AI assistants now do the technical work, really quite amazingly well. A teacher can describe a classroom problem in plain English, try what comes back, say what to change and repeat until it works in a lesson. The tool I spent weeks building twenty-odd years ago can now be made in an afternoon by a teacher who has never heard of FTP.

The person who knows the problem can now build the tool.

The reasonable worry

Not everyone will greet this as good news. Some colleagues think building tools is too difficult. Others fear a flood of AI slop, with hundreds of half-finished tools made in an afternoon and forgotten by the end of term. Most worry about what happens to pupils' data once a tool is online.

The first worry has largely gone. The other two deserve to be taken seriously, though both are less new than they sound. People have always been wary of what they don't yet understand, and almost every new technology in schools has had its moral panic. The fear of slop is fair, and I come back to it below. The worry about data is older still. Schools have handed pupil data to a dozen suppliers for years, and not all of them kept it safe. What AI adds is speed. In a report published on 30 October, Google's threat intelligence researchers described criminal groups using AI agents to carry out attacks with little human help. The agents rely on ordinary weaknesses, such as a leaked password, a key left in a piece of code or a database that gives away more than it should, and they find them far faster than a person could. A tool built in an afternoon and put online with real pupil data inside it is exactly what they are looking for.

A cautious head could reasonably conclude that the safest course is to ban it and stick to approved products.

Have a go, within guardrails

I think that would be a mistake. The risk is real, but it is manageable, and the guardrails that manage it are simple. They are what make it safe to start.

On my Lab page I describe the route I follow:

1. The problem. Something small that wastes time or leaves pupils stuck every week.
2. The expert. The person who teaches it leads, because they know what a good answer looks like and where pupils go wrong.
3. The tool. Describe it, try it and refine it until it works in a real lesson.
4. The guardrails. Agree with leaders what pupil data never goes in, who approves a tool and how safeguarding duties are met.
5. Sharing it. Test it with one class, keep what works, then hand it to the department.

The guardrails themselves are mostly common sense. Start with tools that store no personal information at all. Build and test with made-up data. Never paste pupil information, passwords or keys into an AI assistant or into the tool. Your own accounts are fine for trying ideas out with made-up data. Before a tool holds anything about real pupils or staff, it goes through the school's data protection impact assessment with your data protection lead. I have set these out in a one-page checklist for staff, drawing on UK data protection law and the Department for Education's guidance, so a school can adopt it as it stands.

What this looks like

My own tools began this way. Whyzo started from a problem I met in every classroom: a pupil can get the right answer for the wrong reason. It asks pupils to explain their thinking, reads every reason and tells the teacher what the class believes. Bearing started from years of running value-added analysis as a deputy head, and from seeing how easily numbers can be misused. You can read more about these tools and others on the Lab page.

Smaller tools are just as useful, and quicker to make. A vocabulary drill built around this week's words. A practice tool for the exact equations a Year 9 class keeps getting wrong. A checklist that walks pupils through planning a history essay. Others take work off teachers' desks: a tracker that brings a class's marks into one view, a marking assistant that checks answers against the mark scheme, a helper that drafts report comments from a teacher's own notes. Those hold pupil data, so they are the ones that go through the data protection check first. Teachers up and down the country are building things like these right now.

The new patchwork

There is a catch, though. Left alone, this creates a new patchwork. A hundred teachers building a hundred tools on a hundred personal accounts is its own kind of mess: nobody knows what exists, what data each tool holds or who looks after it when the teacher who built it moves on.

The difference is in cost and commitment. The old patchwork was made of contracts. Each tool came with a yearly licence, paid for whether it was used or not, and hard to walk away from. The new tools cost nothing extra. They pop up to solve a specific problem. If they don't work, nothing is lost. If they do, they stay, and that is the moment to bring them in: into one approved place, onto a simple list, with a named person who looks after them.

So coherence becomes a light leadership job. Leaders don't need to decide in advance what teachers may build. Their part is to agree the guardrails, keep the list and make sure good tools outlive the person who made them.

Where to start

Pick one small problem from your own teaching this week: something that eats ten minutes of every lesson, trips up the same pupils every time or consumes a free period. Describe it to an AI assistant, build something and test it with made-up data. Show it to a colleague before it goes near a class.

If you would like your department or leadership team to do this together, my Build what your teachers need twilight takes you from a classroom problem to a first tool in an hour, with the guardrails agreed as you go.

The exception becomes the norm

Twenty-odd years ago, I was an exception: a teacher who could build the tool his pupils needed. That is changing quickly. More and more teachers can build, and are building. It will bring schools new challenges, and the guardrails are how they meet them. It will also solve problems that no product was ever going to solve, because the person who understood the problem never used to be the one building the answer. Pupils are starting to build their own tools too, but that is a story for another day.

A note on interests: I built Whyzo, which this article mentions. It is my own product.