Building the UWE Teaching and Learning Tools Matrix with AI: lessons from an accidental vibe coder

Starting with the problem

The Tools Matrix began with a relatively simple challenge: helping colleagues navigate UWE’s increasingly complex digital teaching ecosystem. Academic staff regularly face questions such as: Which tool should I use? What is this tool actually good for? When should I choose one tool over another? How do different tools support activities such as content delivery, engagement, assessment, feedback, collaboration or reflection?

My first instinct was to improve an infographic that a colleague had created with the help of AI. I experimented with AI-generated diagrams and infographics using ChatGPT and Microsoft Copilot. The results often looked convincing at first glance but quickly fell apart under scrutiny, with inaccurate labels, invented relationships and nonsensical layouts. AI could generate something that looked like an educational diagram without necessarily understanding the relationships it was attempting to represent.

The more I explored the idea, however, the more obvious it became that a static visual, made with or without AI, was the wrong solution. Most tools support multiple teaching purposes, and the boundaries between those purposes are often blurred. There were simply too many relationships and nuances to represent clearly in a single image; every attempt to simplify the picture seemed to leave something important out.

Once I stopped trying to create a better graphic and started thinking about an interactive resource, the path forward became much clearer.

From graphic to interactive resource

The decision to build an interactive resource naturally led me towards HTML. It is accessible, sustainable, relatively easy to maintain and works in any modern browser. I already had a foundation in web development and design, but the interface I had in mind was considerably more sophisticated than anything I could have developed on my own.

AI made that level of development much more achievable.

The approach is sometimes described as vibe coding: a conversational form of software development in which AI generates much of the code. I had only heard the term used disparagingly before, so I was initially a little sceptical about applying it to what I was doing. It does broadly describe my process, although the reality was less about simply asking AI to build something and more about an extended cycle of design, testing and refinement.

The workflow quickly settled into a cycle of describing a feature or problem, asking AI to propose a solution, implementing it, testing the result and refining the approach. Sometimes AI generated substantial sections of code; at other times it suggested smaller changes or alternative approaches.

I would inspect the code, test the result locally in a browser and upload revised versions to the Digital Learning staging server. If something did not work as expected, I could describe precisely what I was seeing, sometimes provide screenshots and ask AI to diagnose the problem. Its suggestions could solve an issue immediately, offer a useful alternative or lead me in the wrong direction.

As the Matrix developed, the project expanded beyond the interface itself. I built the main HTML application, a separate data file containing the matrix content and, eventually, a dedicated editor for maintaining and updating that content. The editor was also developed with AI assistance.

Separating the content from the interface made the resource easier to maintain and meant that changes to the matrix data could be made without altering the underlying application. What had begun as an attempt to create an interactive resource had gradually become a small system for creating, managing and presenting it.

The more I worked this way, the more the nature of my role shifted. I was not simply producing the resource; I was increasingly making decisions about what should be produced and whether the results were good enough.

Setting standards and knowing what good looks like

One of the most important aspects of the process was defining clear standards for AI to work towards and against which its outputs could be judged. It was not enough for something to work technically. The Matrix needed to be accessible, responsive, easy to use and focused on the needs of its intended users.

Accessibility was a recurring consideration. I regularly asked AI to review code against web accessibility standards (such as WCAG), identify potential issues, improve keyboard navigation, check colour contrast and consider how the interface might behave at different screen sizes and levels of magnification. These requests were useful, but they were never a substitute for testing. AI could identify potential problems, but it could also confidently assure me that something met accessibility requirements when closer inspection suggested otherwise.

The same applied to usability. AI could generate an elegant-looking interface, but visual sophistication was not the main objective. I repeatedly had to ask whether a feature made the Matrix easier to understand and use, whether it introduced unnecessary complexity and whether the same outcome could be achieved more simply.

The experience made clear to me something I had not fully appreciated at the start of the project. Although my existing knowledge of HTML, CSS and web development was useful, coding ability was not the most important expertise I brought to the process. More important was knowing what a good end-user experience looks, feels and behaves like.

This involved understanding accessibility and responsive design, but also less technical considerations: whether an interface is intuitive, whether information is easy to scan, whether language is clear and concise, whether features have a genuine purpose and whether the resource remains focused on the problem it was created to solve.

AI could generate an impressive amount of functionality very quickly. I could ask it to add filters, animations, panels, tooltips or alternative navigation patterns and it would generally oblige. The harder question was whether any of those additions were necessary. In many cases, the best decision was not to add something at all.

The same principle applied to the content. AI could produce plausible descriptions and recommendations, but plausibility was not enough. I needed to consider whether the information was accurate, useful to UWE staff and consistent with the purpose of the Matrix.

A useful question became:

Does this actually help solve the original problem?

The process therefore became less about asking Can AI do this? and more about asking Should this be done, and does it make the resource better? This distinction became important throughout the project: AI could help produce something, but deciding whether it was good, useful and appropriate required a different kind of expertise.

Using AI to challenge the pedagogy

The same process applied to the pedagogical content. Once the technical framework was largely in place, my use of AI shifted increasingly towards drafting and testing the summaries, guidance, examples and links that populate the Matrix.

This was where my own knowledge of the tools and experience of seeing them used in teaching became particularly important, because I could judge AI’s suggestions against what I knew about their actual use.

AI could make a plausible assessment of whether a particular tool supported a teaching purpose, but its interpretation was often based on a broad or generic understanding of the technology and its potential use. I could challenge those assessments based on how the tools actually work and how they are used in practice.

For example, AI might initially rate a tool highly suitable for content delivery because it allows staff to create and upload content. But the ability to create content is not the same as the ability to structure and deliver it effectively. I could challenge that assessment by considering how well the tool supports content structuring and organisation, how easily learners can access and navigate the material, whether it supports different media appropriately, and whether learners can easily find and revisit content.

Similarly, a tool might appear highly suitable for feedback because it can display automated responses, but that raises further questions. Is the feedback specific? Is it timely? Can learners use it to improve? Does the tool support dialogue, or simply tell learners whether they were right or wrong? The issue was similar to the technical decisions I was making elsewhere in the project: AI could generate a plausible answer, but I needed to decide whether the answer reflected what actually mattered.

These conversations often led to more useful distinctions within the teaching purposes themselves. Correcting AI’s assessment of a tool based on my own experience could expose an assumption that needed examining. It could also prompt more precise questions about what meaningful feedback, active engagement or collaboration actually involve.

In that sense, AI was useful not because it always gave the right answer, but because its responses gave me something to question. Through repeated cycles of drafting, challenging and refining, I developed clearer distinctions between the different teaching purposes and a more consistent framework for evaluating tools. The process also reinforced the importance of expertise: knowing the tools, understanding the educational context and being able to recognise when an apparently plausible answer was not actually good enough.

What I learned

The Matrix would not have been developed in the same way without AI. The speed with which I could experiment with ideas, prototype interfaces, generate code and refine content made a more ambitious project possible.

But the experience also reinforced the value of expertise beyond the ability to produce something. As AI became better at generating code, content and possible solutions, the more important question became how to judge those outputs.

My technical knowledge was useful, but it was only part of the expertise I needed. I needed enough understanding of web development to describe problems, interpret suggestions and recognise when a proposed solution was likely to cause difficulties. But more important was understanding the needs of the intended users, recognising good and poor user experience, applying accessibility standards, understanding the educational context and knowing how the tools work in practice.

AI could generate possibilities. My role was to define the problem, establish the standards, test the results and decide what was worth keeping.

As AI makes the technical act of producing things easier, the value of expertise increasingly lies in judging what should be produced — and whether the result is genuinely useful, accessible and fit for purpose.