The work around the code, taught through repetition.

The curriculum is structured around the skills students usually only learn after their first real engineering role.

What the simulation trains

Students know concepts but have rarely forked a repo, branched, resolved conflicts, or opened reviewed pull requests.

Every feature ships through branches, pull requests, review, and a shared evolving codebase.

Most academic work is solo or ad-hoc, with little exposure to standups, reviews, or team agreements.

Participants work in squads of three inside two product teams with shared rituals and review etiquette.

Assignments are usually well-specified; real engineering starts with ambiguity.

Feature requests are deliberately vague, so squads must write specs and defend scope.

AI makes code output easier, but judgment about what should exist is still scarce.

Squads build competing solutions, and the strongest pull request becomes the product baseline.

Students rarely see correctness under load, profiling, or traffic spikes.

Synthetic B2C traffic exposes bottlenecks and turns performance into a visible engineering problem.

Threat models often remain theoretical and disconnected from a running product.

Simulated attacks force detection, response, hardening, and post-incident learning.

Vague feature request

Squad writes spec

Branch and build

Open pull request

Review and judge

Best PR merges

Week 1

Tooling, Git workflow, squad formation, codebase orientation, and rules of engagement.

Weeks 2-4

Gentle feature cycles, spec writing, reviews, and baseline production habits.

Weeks 5-8

Tighter cycles, cross-squad integration, early traffic simulations, and first hardening work.

Weeks 9-11

Sustained load, attack simulations, performance fixes, and product feature-complete discipline.

Week 12

A real B2C product goes live with paid acquisition, monitoring, feedback, and retrospective.