A few weeks ago I ended the fifth post in this series with an open call. My argument up to that point had been you can’t teach everything AI can do, because the list is unbounded and constantly changing, but you also can’t wait for people to discover capabilities on their own, because the interface actively prevents it. What you can do is engineer collisions: put people in a situation where their existing expertise runs into an unexpected capability, and let the conceptual shift just happen.

So, I asked readers to send me the weird, awkward, slightly broken things they’d done with AI, and the responses came in through the blog, through email, and through a long comment thread on a LinkedIn post.

In a later post, I’ll share detailed examples from the responses. In this post though I’m going to go in the opposite direction, abstracting a few principles from the practical examples.

Patterns in the responses

The submissions skewed heavily towards people using AI as something other than a text generator, which backs up the premise of the whole series: once someone’s mental model shifts, they stop describing AI as a chatbot and start describing it as a general tool for getting things done on a computer.

When I sorted the responses, they fell into a handful of recurring patterns rather than scattering across a hundred unrelated tricks. These are similar to the mental model shifts I wrote about in the second post.

Did You Know AI Can Do… That?

These are, of course, generalisations. After the patterns I’ll come back to some of the (significant) barriers that get in the way of these observations.

1. AI is a computer interface

The largest cluster treats AI as an interface to other software rather than a “thing you talk to”. People built Chrome extensions for tasks as small as copying a set of browser tabs into a list, and as involved as analysing the quality of particular kinds of website. One person built a foreign exchange trading bot, another a fully-fledged system that tracked business operations and produced dashboards. There were people using AI for file conversions across multiple formats, and for writing papers in scientific languages like LaTeX. The underlying logic in every case is one I mentioned in the second post:

Anything that happens on a computer happens through code, AI can write and run code, so AI is not a chatbot, it is a computer interface.

2. AI builds tools

A second cluster, and the one where educators in particular were doing genuinely great work, is people having AI build working tools on demand rather than just write text. Someone generated a drag-and-drop quadrant activity that aggregates a whole class’s responses and flags where they disagree, ready to prioritise discussion; someone else built a maths tool that walks a student through the order of operations and explains each step; another made a space-themed game for practising ratios from a single plain-language prompt. Interactive simulations can be generated in minutes, then refined, and dropped straight into an LMS as standalone HTML. For all of these “vibe coding” projects, there was a sense of building simple tools, or what Morten Rand-Hendricksen calls “Bespoke Just-In-Time Throwaway Software”.

You no longer have to find niche software that does what you want: you describe the thing you need and the AI builds it, to your specification, for free, in the time it takes to explain it.

3. AI requires iteration

A third cluster, smaller but still interesting, treats AI as an iterative partner rather than an oracle. My favourite example came from someone whose partner uses AI to improve her baking: rather than asking for a recipe, she gives it the specific conditions of her kitchen, bakes, photographs the cracked or collapsed result, and sends the photo back to ask what went wrong. Other examples demonstrated that the process of iteration also allowed the AI model to suggest ways of solving the problem the user wouldn’t have identified themselves, such as recommending open source software the user was unaware of (more on that later). I have “iteration” as the final step of The Practical AI Process for good reason – AI is often better in a back-and-forth conversation.

Iterating over results not only improves the outcomes, but often leads to new ways of solving the problem you wouldn’t have thought of in the first place.

4. AI is connected

The fourth cluster is where AI is connected to other applications and services, and it is here that the access question becomes particularly problematic. One person submitted a process that produces a full daily briefing every weekday morning by reading their calendar, searching their drive for files related to each meeting, and writing a summary with prep items and open questions. Someone else runs automated daily version-tracking across their whole machine and has AI write a weekly progress report from the file differences. Another has trained a model to act as an intern PA, managing a calendar, navigating a foreign institution’s fee portal, and assembling multi-leg rail journeys across Europe with the hotels to match. This is so-called “agentic-AI” sitting inside someone’s existing tools and acting on their behalf, but it typically requires access to more capable, more expensive AI models.

Agentic AI is the most sophisticated and perhaps the most useful, but it is currently out of reach for many users

5. AI doesn’t have to use AI

There was also a thread I hadn’t given much thought to in the earlier posts, which is AI as a route to non-AI tools. More than one person described setting out to build something, only to have AI surface an existing open-source tool that already did the job better than they could have managed. That is worth folding into the mental model directly: one of the most useful things AI does is help you discover the free and open software that has existed all along, which is a usefully deflationary point in a field full of inflated claims. It also aligns with the idea of using AI to create your own tools: Whenever I find something that works with an LLM, I now try to replicate it as closely as possible in old-fashioned code.

AI is not necessarily the answer to the problem: it might point the way to “traditional” software, or build a tool which replaces itself in the process.

6. AI requires expertise

The final pattern is one I’ve observed many times: AI requires expertise to use it well. Almost every example that came in demonstrated technical and domain expertise, sometimes overtly, as with people who clearly understood programming languages and the logic of code, and sometimes so subtly the contributor didn’t seem to notice it, reaching for domain-specific vocabulary without registering it as expertise at all.

I’ve written before about domain, technical, and situated expertise, and even that third aspect, the lived experience and contextual knowledge of situated expertise, is now coming into play. With almost four years since the release of ChatGPT, the people who have been experimenting since day one appear to have a qualitatively different understanding of “what AI is” than non-users; habits and ways of thinking have developed alongside the technology itself. That sounds like common sense, but it’s worth emphasising, because LLMs are genuinely weird, and a lot of what makes someone good with them is learned on the job.

The only way to use AI well is to bring existing expertise to it: from your domain, from your understanding of the technology, and from your lived experience.

The gap is widening

Look again at the connected, scheduled, agentic examples, and at the people running command-line tools and enterprise accounts with scheduled tasks and live integrations. These are not, for the most part, teachers on the “free” tier of MS Copilot bundled into a school’s existing licence. They are people with Claude Max subscriptions, with Claude Code, with OpenAI Codex, with the time and the permission and the hardware to experiment. The collection is not a neutral sample of what educators do with AI; it is a sample of what the best-resourced and most technically confident educators do with AI, and the distance between that and what a teacher on a locked-down school device can do is the accessibility gap I wrote about in the third post.

IYKYK Part 3: Who Gets to Know?

The examples are genuinely useful, but they describe a frontier that most educators currently have no way to reach.

One of the biggest questions we need to answer in professional learning is: how do we continue to raise the ceiling when most people still only have access to the basic “search engine style chatbots” that have been around since 2022?

Where next

What the responses have provided is not a list of generic AI activities or prompts, but a set of patterns that are hopefully stable enough to turn into useful PD. In the next post I’ll take each of these patterns alongside the broader framework, and move from the principle, to worked example, to something a school can actually run as professional learning. After that, the whole series will become an open-access handbook for “raising the ceiling” and shifting our mental models about what AI is and what it can do.

I called the series “if you know, you know” because of the many barriers I was seeing to understanding this weird, complex, problematic, and occasionally even useful technology. Thank you to everyone who has shared examples and helped bring some clarity to what we can “know” about AI.