Term project
Build working software from scratch on a topic of your choice, using a coding agent in development and checking the work it produces. Choose a core scenario whose expected behaviour you can explain and test. The project develops your specification, workflow, verification, evaluation and security skills (LO2, LO3, LO5–LO8).
Work alone or with one other student. A two-person project has a correspondingly larger scope. Both members receive the same marks for the four milestones; each student takes and is marked on a separate defense. The milestones total 20 marks, and the individual defense is a separate 15 marks.
Four milestones
Deadlines are Sunday at 23:59 in the due week. Use the linked templates as the body of your submission; link existing evidence rather than copying it into a second report.
| Milestone | Due | Marks | What to submit |
|---|---|---|---|
| Proposal | Week 2 | 2 | What you will build, who it is for, the core scenario, and the agent's role in development. |
| Technical specification | Week 4 | 4 | Requirements, key decisions with rejected alternatives, interfaces and data models, test strategy, and what is out of scope. |
| Alpha and task backlog | Week 7 | 6 | A minimal path that runs end to end, the repository instruction file, one hook gate, and the remaining task backlog. |
| Final | Week 12 | 8 | Working software, tests and their mutation result, one evaluation script, security-scan dispositions, and a README. |
For each milestone, identify the submitted revision, link its artifacts and verification results, and explain any missing result or known limitation. Include one AI-use note for the work and reuse its ID as you carry the project forward. Submit through the published course submission channel and milestone assignment links.
What engineering evidence means
An interface and a collection of features alone earn no milestone marks. The evidence must show what the software should do, how you constrained the agent, and how you checked whether the result was earned. Build this evidence as the project develops:
- Specification: turn each requirement into an observable acceptance case, with normal, boundary and failure inputs. Explain why you chose a design and rejected an alternative; update the specification when new evidence changes the decision.
- Instruction file and hook gate: give the agent the repository's conventions and verification commands. Demonstrate a bad change the gate blocks and a valid change it permits; disabling the gate does not establish correctness.
- Tests and mutation result: preserve a regression that fails before a repair and passes after it. Record the mutation configuration, what was tested, and surviving faults; inspect a survivor and strengthen the test or explain the result's limit.
- Evaluation script: fix its inputs, expected outcomes and denominator. Show a correct candidate and a deliberately wrong candidate so you can demonstrate that the check detects failure, rather than merely producing a favourable result.
- Security-scan disposition: identify the scanned revision and scope. For each finding, record your reproduction or other evidence, the repair or reason it does not apply, and the rerun result. An unexplained clean summary is insufficient evidence.
- README: provide reproducible setup, run and verification commands and the known limitations. Check those instructions against the final revision.
Keep generated changes small enough to inspect. Before accepting one, compare it against the specification, run the relevant checks, and explain what could still go wrong. Results must identify the revision and command that produced them; a predicted result or an unexecuted command is not a passing check.
Expo and individual defense
The expo takes place in week 13 before the defenses and counts towards participation. Demonstrate the submitted software and the evidence supporting your main claims.
Each student then has a fifteen-minute defense without devices. The examiner changes one thing or plants one fault in your own code; you locate it, explain it, and decide what to do. Shared milestone marks do not replace your individual explanation. The syllabus defines the project and defense rules.
The four open-source contributions are a separate work stream.