What participants say about the work.

A backend developer at a fintech company was being asked to evaluate architecture decisions in ML systems. She could follow the high-level descriptions but would stall on anything involving equations or architecture diagrams.

Completed the four-week paper-reading course. Each week the cohort read a different paper and reproduced one figure from it. Week three — reproducing an attention heatmap — required debugging a small Python script that had drifted from the paper's claims.

After the course, she was able to read a paper's architecture section against its equations and flag where claims did not match the code. The one-page summary format is now part of how she documents internal research reviews for her team.

A product squad of five engineers had been shipping features on a hosted model for eight months. Prompts lived in a shared document that had no history and no ownership. Regressions were noticed by users before engineers.

The team enrolled as a cohort in the prompt engineering course. Sessions covered context budgeting, schema validation, failure taxonomies and prompt versioning. The written reviews at the end of the programme covered their actual product prompts, not exercises.

Prompts moved into a dedicated repository with changelogs and review policies. The regression harness template from the course is part of their CI pipeline. The team reported fewer production surprises in the three months following the programme, which they attributed to the structured regression approach rather than to any single technique.

An experienced platform engineer wanted to move into AI work as his primary focus. He had solid Python but no background in numerical methods, transformers, or production ML systems. He was uncertain whether he was ready for the programme and said so in the pre-enrolment conversation.

Enrolled in the six-month programme after the technical conversation. The programme covered numerical foundations, then models from scratch, the transformer architecture read line by line, retrieval systems, agents, evaluation and serving. His capstone was a document retrieval system with a monitoring layer. The two-week unsupported run surfaced a latency problem he had not caught earlier.

Completed the programme. The retrieval system became part of his professional portfolio. The capstone review identified two design decisions that would have caused scaling problems in production — both were fixed during the programme, not after. He reported that the one-to-one office hours were the single most useful component of the twenty-four weeks.