Learning to write a prompt for ChatGPT was not enough
The module aimed to help people in non-technical roles understand where AI could fit into their work. That required more than a tour of tools: participants needed to see how models respond, where they fail and what information is needed for a useful result.
We designed the days as a continuous pathway. Early experiments with models led into comparing tools; document work prepared participants to design solutions. Each step built on what they had already encountered.
One fictional company to connect the exercises
Caffè Brevia was the fictional company used throughout the module. Participants returned to the same context across activities instead of starting over with a new example each time.
Teaching materials also let us introduce conflicting information and examine how it was handled. The aim was not to get an answer that sounded convincing at first glance, but to learn to check it against the available sources. No confidential customer documents were used.
From model limitations to a final project
The four days covered different problems through explanations, demonstrations and practical work.
| Day | Topic | Classroom work |
|---|---|---|
| 1 | Understanding generative AI | Examples of incorrect answers, model limitations and exercises using Caffè Brevia. |
| 2 | Tools and ecosystem | Tool comparison, a multi-tool exercise and a quiz. |
| 3 | RAG and knowledge bases | How to retrieve answers from documents and check them against their sources. |
| 4 | From processes to projects | A project canvas, chatbot prototypes and ideas linked to participants’ work. |
Working with documents also means spotting contradictions
For the knowledge-base module, we prepared a collection of Caffè Brevia documents and reference answers to compare with the system’s responses. This made visible a problem that demonstrations often conceal: a system can phrase an answer well while using information incorrectly.
The topic was RAG: retrieving information from documents for a model to use in its answer. In class, participants explored how source quality, retrieval and answer verification fit together. The exercise was revisited in a shorter form on the final day, adapted to the time available and the group’s questions.
What participants built in class
On the final day, groups built chatbot prototypes with Claude Code. The project canvas helped each participant outline an initial project linked to one of their work processes; some presented their idea to the group.
These were teaching prototypes and early proposals, not applications deployed in companies. The observed outcome was a shift from trying a tool to defining a specific use, a problem to address and a project to explore further.
This case covers a single cohort of seven participants. No formal pre- and post-module learning assessment or subsequent workplace-impact measurement was conducted.
What we carry into future programmes
A shared case makes it easier to discuss errors: everyone works with the same documents and can compare the reasoning, not just the final answer. Participants then connect the work to their own processes, with concrete examples to build on.
Company training can build on this approach while adapting its duration, depth and topics. The Uninform module described here was a specific part of a master’s programme; it is separate from our modular programme for executives, whose complete format is 52 hours.