Teaching Machine Learning in 5 Hours: AI Workshop Methodology and Curriculum

The Constraint: Working ML Knowledge in a Single Session

Teaching machine learning in five hours to people with no prior background is primarily a curriculum design problem, not a teaching talent problem. The question is: what is the minimum viable ML knowledge that lets someone evaluate whether a system is trustworthy, identify where it might fail, and make informed decisions about deploying it?

At Alcalá Mobile 2024, Maedcore ran a five-hour workshop with that objective. This post documents the curriculum decisions and the reasoning behind them.

Why This Sequence and Not Another

The four-block structure — fundamentals → architecture → data → project — was not arbitrary. Each block creates the mental model that the next one requires:

• You cannot reason about neural network architecture without first understanding that ML is pattern-matching from data, not explicit rule-writing.
• You cannot understand why data quality matters without first having a model of how a network learns from it.
• You cannot build a working application without having handled real data.

Running the project block before the data block — which feels intuitive because “doing” motivates people — produces participants who can follow steps but cannot diagnose failures. The sequence produces practitioners who can adapt.

Five hours was chosen because it maps to a single intensive day without accommodation requirements — important for an event-based format. It is also the minimum duration that allows a hands-on project block long enough to encounter and resolve a real problem.

Block 1: ML Fundamentals — Grounding in Familiar Systems

The first block establishes what machine learning actually is: a method for building systems that learn mappings from input to output by example, rather than by explicit programmer-specified rules.

Framing this for a practitioner audience means starting with systems they already trust: spam filters that improve over time, fraud detection that adapts to new attack patterns, recommendation engines that change with listening history. These are not curiosities — they are infrastructure that runs at scale with economic consequences when they fail.

The conceptual work in Block 1 is teaching the distinction between training (learning from historical examples) and inference (applying the learned function to new data). Most ML misconceptions in non-technical organisations come from conflating these two phases — assuming that a model trained on last year’s data is still making optimal decisions on this year’s inputs.

Block 2: Neural Networks — Architecture Without the Mathematics

Artificial neural networks are the dominant architecture in modern AI. A practitioner who cannot form a mental model of what a neural network does will systematically misunderstand AI system behaviour.

The approach Maedcore uses: treat the network as a learned function approximator and explain it through the structure, not the calculus. Input layer receives data. Hidden layers learn intermediate representations — edges before shapes, shapes before objects, components before categories. Output layer produces the prediction.

The critical conceptual point is backpropagation as iterative error correction: the network makes a prediction, measures how wrong it was, and adjusts connection weights in the direction that reduces error. Repeated across thousands of examples, this produces a network that has internalised the patterns in the training data.

No matrix algebra required to understand this. The visual — a multi-layer graph with weights that shift based on error feedback — carries the intuition that matters for practitioners: more data with accurate labels makes better models; data with systematic errors makes confidently wrong models.

Block 3: Data Processing — Where Most ML Projects Actually Fail

This block is the one most consistently underestimated by organisations evaluating AI projects. The model architecture matters far less than the quality of the data it trains on.

Three concepts covered in depth:

Data cleaning — handling missing values, removing duplicates, correcting label errors. A network trained on corrupted labels learns to replicate the corruption. Organisations with messy CRM data, incomplete sensor logs, or inconsistently labelled historical records cannot expect a model to compensate for those deficiencies.

Normalisation — scaling input features so that no single feature dominates gradient descent by virtue of its numerical range rather than its predictive value. A network that receives temperature in Kelvin (270–300 range) alongside a binary flag (0 or 1) will treat the temperature as vastly more important by default. Normalisation corrects this.

Train/test split — the discipline of withholding a portion of data from training and using it only for evaluation. This is the mechanism that prevents overfitting — a model that has memorised its training data but cannot generalise. The split is not a technical formality; it is how you know whether your model has actually learned something.

The key takeaway: data preparation is typically 60–80% of the work in a real ML project, and the models with the best measured performance are almost always built on the cleanest, most carefully validated datasets.

Block 4: Building Your First Model

The final block is hands-on. Each participant built a working ML application — a classification model trained on a real dataset, with data preprocessing, model training, evaluation against the test set, and a visible prediction output.

Project-based learning for technical concepts works because it forces the learner to encounter the failure modes, not just read about them. Participants who saw their model perform poorly on the test set despite high training accuracy immediately understood overfitting in a way that a lecture explanation does not produce.

Several participants chose to personalise their application to a domain relevant to their work — a pattern classifier, a churn predictor, a basic anomaly detector. The result was a participant cohort that left the session with a working artifact and a concrete sense of what a production ML system would require beyond it.

What Curriculum Coherence Signals About AI Capability

A team that can teach machine learning coherently to a non-technical audience has, by necessity, internalised the subject well enough to extract and sequence its core ideas. Pedagogy at this level requires that you understand not just the mechanisms, but which mechanisms matter and why, and which complexity can be safely deferred.

The same judgement applies in applied AI work: knowing which model architecture is appropriate for a given dataset and objective, where data quality will make or break the project, and how to evaluate whether a deployed model is behaving as intended.

If you are evaluating AI implementation for a technical project — custom model training, AI integration, or applied machine learning in an industrial or product context — contact Maedcore or see our AI and software work.