What you deliver

In every cycle you make a personal project for your chosen topic. This page describes what that project must contain, where you deliver it, and what you do each week. The project is also called your artefact.

Choose a type of project

Your project is one of two types:

An explainer: an application that explains the topic you are studying to someone else.
A personal project: an application in which you try to use the technology or the topic you are studying.

The type can differ per student in the same learning group.

What the product must be

Your product consists of two parts:

An interactive application.
Documentation on how the application came to be, including the iterations you went through.

The application must be interactive

Whether you make an explainer or a personal project, the application must be interactive, and the end user must be able to see and understand how it works.

A polished interface is not enough

This applies to every student, AI Engineer and Creative Technologist alike. Your application must contain a working technical AI system or make actual AI behaviour interactively experienceable. It must use, integrate, compare, manipulate or test a real model, dataset, AI API or actual inference process.

Show a variation

As a Creative Technologist, your application must make at least one intentional variation visible, for example a difference in:

training data or labels
model or model setting
prompt or system prompt
interface or interaction pattern
threshold, feedback or degree of human control
context of use or target user group

You should be able to explain what working system behaviour your application demonstrates, what variation or boundary you explored, and what this makes visible for a user, team or client. Everyone thinks about this in the first brainstorm, so treat it as a good habit for AI Engineers as well.

Where you deliver your code

Commit your code to the learning group repository.
Front-end code: pure front-end code can be published to GitLab Pages.
Back-end code: back-end code must run in a Docker configuration.

Applications should preferably be browser-based, so they can be opened, demonstrated, tested and discussed easily.

Working with coding agents

Using coding agents is allowed and encouraged. As an AI Engineer, you must be able to explain your back-end code.

What you do every week

Every week you do two things:

Implement a significant increment of your work, in multiple commits.
Test your work and write down what you learned. Does it explain what it needs to explain? Do other people understand what is going on and how it works? Bring your findings to the next learning group meeting.

Log the feedback you get in the meeting in Portflow, as described in Logging feedback in Portflow.

What you do as a group

Towards the end of the cycle, the learning group documents how all the individual projects fit together. This is a shared deliverable of the whole group, next to the individual projects. It also helps you prepare for presenting your work.

Checklist

Use this checklist to keep track of everything that is expected of you in a cycle.

At the start of the cycle

I confirmed my topic in the first week, after coordinating with the other groups in my class and checking with my coach.
Creative Technologists: my group formulated a shared research question.

Your project

My project is an explainer or a personal project for my chosen topic.
My application is interactive, and an end user can see and understand how it works.
My application contains a working technical AI system or makes actual AI behaviour interactively experienceable, and is more than a polished interface.
Creative Technologists: my application makes at least one intentional variation visible.
I documented how the application came to be, including the iterations.
AI Engineers: I can explain my back-end code, also if a coding agent helped me write it.

Your code

My code is committed to the learning group repository.
Pure front-end code is published to GitLab Pages.
Back-end code runs in a Docker configuration.

Every week

I implemented a significant increment of my work, in multiple commits.
I tested my work: does it explain what it needs to explain, and do others understand what is going on and how it works?
I came to the learning group meeting with my current work or a concrete technical test, and I brought my findings.
I gave useful feedback on the work of the other students in my group, and rotated partners as planned.
I logged the feedback I received and my next-iteration agreement in Portflow.
I used the feedback to improve my work.

As a group, towards the end of the cycle

We documented how all the individual projects fit together.

At the end of the cycle

I presented my working project and what I learned.
In the second cycle, I repeat all of this with a new topic and a new project.