Track · FPS · Learn dev

Learn AI-native software development by building an educational game.

Train as a broadly employable software engineer who happens to build a game, rather than only as a game-engine specialist. The project is an educational first-person experience that teaches terminal, Linux, tmux, Git, testing, deployment, and responsible AI-assisted development. The game is the motivating product; the real objective is learning to design, build, test, secure, deploy, operate, and explain real software.

Last reviewed: 2026-07-22 · reviewed quarterly. Employment and tooling signals change; the recommendations below are revisited on that cadence.

#Purpose

This is a practical route into modern software development for someone who enjoys first-person games but wants career options across the broader technology industry. The central idea is simple: train as a broadly employable engineer who builds a game, not only as a game-engine specialist.

The path stays useful even if the learner never applies to a game studio. Its skills transfer to web development, full-stack development, developer tooling, quality engineering, platform engineering, technical support, cloud operations, solutions engineering, educational technology, and eventually systems programming.

This is a competency-based plan. Suggested timing assumes roughly 10–15 focused hours per week, but a learner should advance when they can demonstrate the exit criteria, not merely when a calendar says a phase is over.

#Executive recommendation

Use the following stack as the default. It is deliberately decisive: the point is to keep moving, not to survey every option.

Why this route

TypeScript is a strong first professional language because it starts with the reach of JavaScript and adds static checking and better tooling. A learner can use the same language for browser interfaces, game logic, servers, command-line tools, tests, automation, and many AI integrations.

GitHub reported that TypeScript became the most-used language on GitHub by contributor count in August 2025. The 2025 Stack Overflow Developer Survey also reported strong continued interest in TypeScript, Bash/Shell, and Rust. These signals do not guarantee a job, but they support a path that combines typed application development with command-line fluency.

The general software market is also substantially broader than the commercial game-studio market. The U.S. Bureau of Labor Statistics projects 15 percent employment growth from 2024 through 2034 for software developers, quality-assurance analysts, and testers. By contrast, GDC's 2026 industry survey reported that 28 percent of game-industry respondents had experienced a layoff during the preceding two years, including 33 percent of U.S. respondents. The lesson is not “do not make games.” It is “make the game demonstrate skills that many kinds of employers can use.”

#What this path is — and is not

#Career positioning

The learner should be able to describe the completed work in language that applies beyond games:

That story can support applications for roles such as: junior software developer; frontend developer; full-stack developer; TypeScript or Node.js developer; QA automation engineer or software development engineer in test; developer-tools engineer; technical support engineer; cloud support associate; junior platform or DevOps engineer; solutions engineer; educational-technology developer; technical content engineer; open-source contributor; and later, Rust or systems-tooling developer.

The project should not be presented only as “a game.” It should be presented as a complete software product with a game-based interface.

#Why TypeScript comes before Rust

Rust is an excellent language for reliable and efficient software, but it combines several difficult ideas at once: ownership, borrowing, lifetimes, explicit error handling, traits, concurrency, and low-level resource control. Those ideas are valuable, but they can slow a new learner who is simultaneously trying to understand programming, Git, Linux, networking, databases, testing, deployment, and product design. TypeScript provides a shorter route to useful, visible results while still teaching type-driven development.

Start with JavaScript fundamentals so the learner understands the runtime language. Move to TypeScript early enough that types become normal rather than an afterthought. Introduce Rust only after the learner can independently:

• Build a working application feature from a written requirement.
• Read compiler and test failures.
• Use Git branches and review diffs.
• Design and call an HTTP API.
• Model data in a relational database.
• Write unit and browser-level tests.
• Diagnose a failing build or deployment.
• Explain asynchronous execution.
• Review AI-generated changes rather than accepting them blindly.

Good first Rust components include a lesson-definition validator CLI, a content-pack compiler, a deterministic command parser, a replay or event-log processor, a local sandbox supervisor, a performance-sensitive simulation module compiled to WebAssembly, and native commands for a Tauri desktop application. Each Rust component should have a clear interface and reason to exist. Do not rewrite working TypeScript in Rust merely to claim that the project uses Rust.

#Where Unity, Unreal, and Godot fit

Unity

Unity remains useful as a secondary learning and prototyping environment — see the parallel Unity FPS week. Previous Unity study transfers into scene composition, collision, physics, animation, lighting, asset workflows, and game-loop reasoning. Use it for small gameplay prototypes, level-design experiments, understanding editor-driven development, comparing component models, short game jams, and exploring roles specifically tied to Unity. Do not allow Unity study to replace the broader engineering work in this plan. A reasonable default is roughly 80 percent of project time on the TypeScript product and 20 percent on optional engine experiments.

Unreal Engine

Unreal is appropriate when a learner later chooses high-end 3D, AAA production, virtual production, advanced rendering, or C++ engine work. It is not the default starting point. Learning Unreal, C++, TypeScript, Rust, Linux, cloud deployment, tmux, Git, and AI workflows simultaneously creates too much context switching. Defer Unreal until the learner has shipped at least one substantial product or has a specific role that requires it.

Godot

Godot is open source, approachable, and a good choice for a learner whose primary objective is conventional game development. For this curriculum, however, browser-first TypeScript development exposes the learner to more of the stack used by ordinary software products: browser APIs, accessibility, HTTP, authentication, databases, observability, deployment, and operations. Godot remains a valid alternative, but it shifts the emphasis from “software engineer building a game-shaped product” toward “game developer building a game.”

#Learning principles

1. Build vertical slices

A vertical slice is a narrow feature that works from the user interaction through the underlying logic and tests. The first slice is not “build the engine.” It is:

Load one small room → Walk to one terminal → Enter pwd
→ Receive deterministic output → Validate the command
→ Unlock one door → Save completion locally → Prove it with a test

That slice teaches more than months of disconnected tutorials.

2. Prefer a simulated shell first

The first release should not execute arbitrary user commands on a server. It should implement a small, deterministic command interpreter over a virtual filesystem. This approach can run entirely in the browser, is inexpensive to host, works offline, is deterministic and easy to test, avoids remote-code-execution risk, gives the learner time to understand security boundaries, can offer clear explanations and hints for supported commands, and reproduces the same lesson on macOS, Windows, Linux, and mobile browsers. Real Linux sandboxes belong in a later phase with strict isolation, quotas, timeouts, and abuse controls.

3. Learn concepts, not command trivia

A terminal curriculum should explain mental models — current working directory; paths and filesystem trees; standard input, output, and error; processes and signals; permissions and ownership; environment variables; streams and pipes; exit codes; shell expansion and quoting; sessions, terminals, shells, and multiplexers; and version-control state and history. Command memorization follows from understanding these models. Groundwork's Command line & Unix and Shell & CLI pages already teach these; link them rather than re-explaining.

4. Require evidence of understanding

A feature is not complete merely because it runs. For every meaningful feature, the learner should be able to explain the requirement, identify the relevant files, describe the data flow, predict likely failure modes, demonstrate the tests, read the final diff, explain any AI-generated code, and state what remains uncertain.

5. Separate learning mode from production mode

A learner sometimes needs to write code without AI, while a production engineer should use effective tools. Use explicit work modes:

The goal is not to avoid AI. The goal is to remain capable of checking it — the same discipline the vibe → agentic path teaches.

6. Keep the stack intentionally small

Do not add a framework because it is popular. Add it because the current problem requires it. Early releases need a browser application, a 3D scene, a terminal component, lesson data, deterministic state, and tests. They do not initially need microservices, Kubernetes, event streaming, multiple databases, complex infrastructure-as-code, multiplayer networking, a plugin marketplace, a custom game engine, a native installer, or a real public shell.

#Target product concept

The working title can remain generic until the project develops its own identity.

Product promise: teach practical development skills through an interactive environment in which commands, code, tests, and debugging actions change the world.

Core loop:

1. Explore a first-person environment.
2. Discover a technical problem.
3. Read contextual documentation and clues.
4. Use a terminal, editor, Git repository, logs, or test runner.
5. Form a hypothesis.
6. Perform an action.
7. Receive realistic feedback.
8. Verify the result.
9. Unlock the next area.
10. Review the concept in a non-game interface.

Example narrative frame: a facility, spacecraft, laboratory, data center, or remote research station has partially failed. Each system corresponds to a real software-development concept. Doors, power systems, communications, and machinery respond to correct technical actions. The narrative should support the curriculum rather than obscure it.

#Curriculum map inside the game

Module 0: Terminal orientation

Concepts: terminal versus shell, prompt anatomy, commands and arguments, help output, keyboard navigation, copy and paste, command history, exit status.

echo   printf   clear   history   man   help   which   type

Outcome: the learner can open a terminal, identify the active shell, run a command, read help, edit a command, and describe what an exit code means.

Module 1: Filesystem navigation

Concepts: root directory, home directory, absolute and relative paths, current working directory, files versus directories, hidden files, safe deletion.

pwd   ls   cd   mkdir   touch   cp   mv   rm   rmdir   file   stat

Game scenario: a door controller has lost its configuration. The player navigates a virtual filesystem, finds a hidden backup, copies it to the expected path, and verifies the result.

Module 2: Reading, searching, and transforming text

Concepts: standard input, standard output, standard error, pipes, redirection, text streams, pattern matching.

cat   less   head   tail   grep   sort   uniq   cut   wc   tee   find

Game scenario: the player analyzes logs from several subsystems, isolates a repeated failure, and sends the relevant identifier to a repair process.

Module 3: Processes and signals

Concepts: process identifiers, foreground and background jobs, signals, long-running commands, resource use, graceful versus forced termination.

ps   pgrep   kill   jobs   bg   fg   top

Game scenario: a runaway process is consuming the station's power budget. The player identifies it, inspects it, sends an appropriate signal, and confirms recovery.

Module 4: Permissions, users, and environment

Concepts: users and groups, read/write/execute permissions, least privilege, environment variables, executable search paths, secrets versus configuration.

id   whoami   chmod   chown   env   export   printenv

Game scenario: a service cannot read its configuration. The player must diagnose the actual permission error instead of applying unsafe global permissions. The game should explicitly teach why chmod 777 is usually not a responsible fix.

Module 5: tmux and persistent terminal work

Concepts: sessions, windows, panes, detach and reattach, long-running processes, remote-work continuity, copy mode. This is where Groundwork's tmux page is the reference — the lesson should use the documented default configuration and clearly label any Groundwork-specific customization.

Exercises: create a named session; split a window into panes; run logs in one pane and a service in another; detach while work continues; reattach and diagnose an event that occurred while disconnected; use copy mode to retrieve an earlier error.

Game scenario: a control room has several systems that must be observed simultaneously. The player creates a tmux workspace and keeps a repair job running while moving between terminals.

Module 6: Git fundamentals

Concepts: working tree, index, commit history, branches, diffs, merge conflicts, restoration versus deletion, remote collaboration. Groundwork's Git page owns this material.

git status   git diff   git add   git commit   git log
git switch   git branch   git restore   git show   git merge

Game scenario: a configuration repository contains an incorrect change. The player inspects the diff, creates a branch, restores the intended behavior, runs checks, commits the repair, and resolves a controlled conflict. Avoid presenting Git as a list of magic commands. Visualize the working tree, index, current commit, branches, and remote state.

Module 7: Programming and debugging

Concepts: variables, functions, conditionals, loops, arrays and objects, modules, errors and stack traces, assertions, test-driven diagnosis, logging versus debugging.

Game scenario: a small TypeScript program controls an in-world device. The player reproduces a bug, reads a failing test, follows the data, fixes the smallest responsible unit, and confirms the result.

Module 8: Web and API fundamentals

Concepts: client and server, HTTP requests and responses, methods and status codes, JSON, validation, authentication versus authorization, browser developer tools, network failures.

Game scenario: a communications system calls an API with malformed data. The player inspects the request, corrects the contract, and handles a deliberate failure path.

Module 9: Databases and data integrity

Concepts: tables, primary and foreign keys, normalization basics, queries, transactions, constraints, migrations, backups, idempotency. See also Groundwork's Data & storage page.

Game scenario: the facility's inventory system contains conflicting records. The player identifies the broken invariant and adds a safe correction rather than manually editing symptoms.

Module 10: CI/CD and production operations

Concepts: automated checks, reproducible builds, artifacts, environments, deployment gates, rollback, logs, metrics, alerts, incident timelines.

Game scenario: a release passes locally but fails in CI. The player compares environments, identifies a hidden assumption, corrects the build, and writes a brief incident note.

Module 11: Responsible AI-assisted development

Concepts: prompt context, bounded tasks, plans and acceptance criteria, hallucinated APIs, stale assumptions, unsafe dependency changes, diff review, test selection, security and privacy, human accountability. This mirrors Groundwork's AI agents & rules discipline.

Game scenario: an AI agent submits a plausible patch that fixes a visible symptom but weakens a security boundary and fails an edge case. The player must inspect the requirements, review the diff, run targeted tests, reject the unsafe portion, and produce a corrected change. The module should reward verification, not prompt cleverness.

#Proposed technical architecture

Stage 1: Browser-only vertical slice

The earliest useful release can run entirely in the browser.

Player input ─┬─→ First-person game ──→ Lesson state machine ─┬─→ World changes, hints, assessment
              └─→ xterm.js terminal ─→ Simulated command parser ─┬─→ Virtual filesystem
                                                                   └─→ Lesson state machine
Lesson state machine ──→ Local saved progress

Components: a TypeScript application; HTML and CSS shell around the game; a Babylon.js scene; an xterm.js terminal interface; a virtual filesystem; a supported-command parser; a lesson state machine; structured lesson definitions; local saved progress; and unit and browser tests. This stage should have no account system, no public command execution, and no mandatory cloud service.

Stage 2: Product backend

Add a backend only after the offline vertical slice is useful.

Browser application ──→ Node.js API ─┬─→ PostgreSQL
                                     ├─→ Versioned lesson content
                                     └─→ Privacy-conscious product telemetry
CI pipeline ──→ Browser application  &  Node.js API

Backend responsibilities: account and session management, saved progress, content-pack versions, instructor or mentor views, anonymous aggregate product metrics, feature flags, and a supportable migration process. The backend should not yet run unrestricted shell commands.

Stage 3: Isolated Linux exercises

Only add real execution after the team has documented and tested the threat model.

Browser ─→ API ─→ Sandbox request queue ─→ Sandbox broker ─→ Short-lived isolated environment
Short-lived isolated environment ─→ Bounded output and result ─→ API ─→ Browser

The sandbox broker must be separate from the public application process. Treat all learner commands and lesson content as untrusted input.

Stage 4: Optional native application

Use Tauri when native distribution adds clear value: offline content packs, local filesystem exercises with explicit consent, local container integration, better keyboard and window integration, managed classroom or lab installations, and reduced dependence on browser limitations. The web application should remain the source of truth for most user interface and lesson logic. Native commands should be small, permission-scoped, and audited.

#Security requirements for real command execution

A public terminal-learning product is an attractive abuse target. The following are minimum design expectations, not optional polish.

Isolation

• Run each exercise in a fresh, short-lived environment.
• Never run learner commands in the API process.
• Never mount application source, deployment credentials, or host home directories.
• Use a non-root user inside the environment.
• Use a read-only base filesystem where practical, providing only lesson-specific writable paths.
• Apply CPU, memory, process-count, disk, output, and wall-clock limits, and kill and destroy the environment at timeout.
• Deny privileged container settings, host networking, access to the container runtime socket, and access to cloud instance metadata.
• Prefer deny-by-default outbound networking; permit only explicitly required destinations for a lesson.
• Regularly rebuild and patch base images.

Application controls

• Authenticate requests where persistent accounts are involved.
• Use short-lived, single-purpose sandbox tokens.
• Rate-limit sandbox creation and enforce concurrent-session limits.
• Cap command and output sizes; normalize and validate lesson identifiers.
• Prevent users from choosing arbitrary images or runtime options.
• Record security-relevant events without collecting command content unnecessarily.
• Keep secrets out of client code, lesson packs, logs, and generated AI context.
• Provide an abuse-reporting and shutdown path before public launch.

Content safety

Lesson authors are also a trust boundary. Validate lesson definitions against a versioned schema; review commands included in official lessons; digitally sign published content packs, or verify their digest through a separately trusted channel (a checksum shipped alongside compromised content authenticates nothing); separate community content from trusted official content; do not allow a lesson file to request arbitrary host capabilities; and require review for new network destinations or native permissions.

AI safety

• Do not send learner secrets, private repository contents, or terminal history to an AI provider by default.
• Make AI data handling visible.
• Allow AI-assisted lessons to operate with synthetic repositories and synthetic secrets.
• Treat model output as untrusted text; validate tool calls and file paths.
• Require human approval for destructive actions.
• Prevent an AI agent from modifying its own policy, tests, or verification rules without review.

#Cross-platform strategy

Browser first

The browser provides the widest low-friction distribution: macOS, Windows, Linux, ChromeOS, many tablets, and managed lab environments. Use WebGL as the broad fallback and enable WebGPU only when supported. Avoid making a high-end GPU a prerequisite for the learning content.

Development systems

Support these developer paths: macOS with native terminal tools and a container runtime; Linux with native terminal tools; Windows with WSL2 for the Linux curriculum; and a remote Linux development environment when local hardware is constrained. Groundwork may optimize the macOS path, but the public curriculum and product should not imply that macOS is required.

Performance budgets

Treat these as product targets to validate, not assumptions: a low-quality preset that avoids expensive post-processing; keyboard-only operation for all required learning actions; playable operation on integrated graphics; a small initial download with later content loaded on demand; a 30 frames-per-second floor on the documented minimum target; a 60 frames-per-second goal on contemporary integrated hardware; and a non-3D lesson interface for devices or users that cannot use the first-person mode. Measure performance on actual lower-end hardware, not solely the developer's newest laptop.

#Accessibility requirements

A learning product cannot claim broad accessibility if the curriculum is trapped inside a motion-heavy 3D interface. Provide a complete non-3D lesson mode; full keyboard navigation; remappable controls; adjustable mouse sensitivity; field-of-view settings; head-bob and camera-shake toggles; reduced-motion mode; pause at any time; captions and transcripts; high-contrast interface options; color-independent status indicators; scalable text; screen-reader-compatible lesson instructions and assessments; clear focus indicators; error messages that explain how to recover; generous or disabled time limits outside explicitly timed challenges; and input alternatives for users who cannot use standard first-person controls.

#Suggested repository evolution

Start simple. Split the repository only when boundaries become real.

terminal-learning-game/
├── docs/
│   ├── product-brief.md
│   ├── architecture.md
│   └── learning-objectives.md
├── public/
├── src/
│   ├── game/
│   ├── lessons/
│   ├── simulated-shell/
│   ├── terminal/
│   └── ui/
├── tests/
├── package.json
├── tsconfig.json
└── README.md

terminal-learning-platform/
├── apps/
│   ├── web/
│   ├── api/
│   └── desktop/
├── packages/
│   ├── lesson-schema/
│   ├── lesson-engine/
│   ├── simulated-shell/
│   ├── shared/
│   ├── test-fixtures/
│   └── ui/
├── sandbox/
│   ├── broker/
│   ├── images/
│   └── policies/
├── docs/
│   ├── architecture/
│   ├── decisions/
│   ├── learning/
│   ├── operations/
│   └── security/
├── infra/
└── tools/

Do not create the larger structure on day one. Promote code into packages when at least two real consumers or a strong security boundary justify the separation.

#Twelve-month competency roadmap

The timing below is illustrative. A learner with prior programming experience may move faster; a complete beginner may need longer. Advance on the exit criteria, not the calendar.

Phase 0: Environment and learning habits · 1–2 weeks

Objectives: set up a reproducible development environment; learn how to ask for help with useful evidence; understand files, processes, commands, and exit codes at a basic level; establish a work log and a Git repository.

Work: install and verify the terminal, shell, Git, tmux, editor, Node.js, and package manager; learn the purpose of each tool rather than copying a dotfiles setup blindly; create a small repository with a README; practice creating, editing, comparing, and committing; keep a daily learning log in Markdown; learn to capture command output and error messages safely.

Deliverable: an “environment verification” repository with setup notes, a simple command-line script, at least five intentional commits, a troubleshooting note for one real problem, and no secrets or machine-specific personal data.

Exit criteria: the learner can open a terminal; explain the shell/terminal distinction; navigate to the repository; start and reattach to a tmux session; run the project; read a failed command's exit status; create a branch and commit a change; and explain every direct project dependency and the purpose of the major transitive toolchain pieces.

AI rule: AI may explain errors, but the learner must type and understand the commands. No agent-generated repository setup.

Phase 1: JavaScript and web foundations · 4–6 weeks

Objectives: learn fundamental programming constructs; understand browser structure and events; build small interactive pages without a large framework.

Topics: values and types; variables and scope; functions; arrays and objects; conditionals and loops; modules; errors; DOM; events; forms; semantic HTML; basic CSS; browser developer tools; network and console panels; accessibility fundamentals.

Projects: command-history visualizer; virtual directory tree; text-based “escape room”; small quiz that saves progress locally; log-search exercise. Deliverable: a browser-based text adventure in which typed commands update a virtual filesystem.

Exit criteria: the learner can write a function from a small requirement; trace data through several function calls; explain event handling; diagnose an error with browser tools; write and run unit tests; build a semantic form without copying a component library; and explain why an implementation is accessible or inaccessible.

AI rule: use manual mode for at least one small feature each week. AI-generated code must be reviewed statement by statement.

Phase 2: TypeScript and maintainable application design · 4–6 weeks

Objectives: make types part of normal development; learn to model domain state; separate user interface, game state, and command interpretation.

Topics: type inference; interfaces and type aliases; union types; generics; narrowing; discriminated unions; runtime validation versus compile-time types; pure functions; state machines; dependency boundaries; error modeling.

Project work: refactor the text adventure into a typed virtual filesystem, a typed command result model, a lesson state machine, versioned lesson data, and unit tests for commands and lesson transitions.

Exit criteria: the learner can explain why TypeScript cannot validate untrusted runtime data by itself; represent command success and failure without ambiguous nullable values; add a command without editing unrelated modules; write tests for edge cases; read and respond to compiler diagnostics; and explain the public interface of each major module.

AI rule: AI may propose types, but the learner must identify which invariants are enforced at compile time and which require runtime checks.

Phase 3: First playable 3D vertical slice · 6–8 weeks

Objectives: learn a 3D engine without losing sight of application architecture; integrate the terminal, lesson engine, and game world; ship a complete browser experience.

Scope: one room, one terminal, one objective, one door. The learner must walk to the terminal, activate it, run pwd, ls, cd, and cat, find a code or repair instruction, complete the objective, unlock the exit, view a concept review, and retain completion after a page reload.

Engineering work: scene lifecycle; camera and input; collision; interactable objects; terminal overlay; mode switching between game and terminal; lesson events; save-state versioning; loading and error states; low-quality graphics preset; non-3D fallback; automated browser test for the critical path.

Exit criteria: a new user can complete the lesson without developer assistance; it runs on at least macOS, Windows, and Linux browsers; keyboard-only completion is possible; progress survives reload; the command engine remains deterministic; the main path has an automated browser test; a performance profile has been recorded on lower-end hardware; and the learner can explain the scene, state, terminal, and lesson boundaries.

AI rule: an agent may implement one bounded issue at a time. Every agent issue must include acceptance criteria and a verification command.

Phase 4: Git, tmux, and debugging content pack · 6–8 weeks

Objectives: expand the product without changing its core architecture; learn content authoring and schema evolution; teach tools the learner now uses in real development.

Work: add filesystem, pipes, process, tmux, Git, and debugging modules; create a lesson schema and validation command; add fixtures for lesson scenarios; add deterministic replay for failed sessions; create author documentation; add hints that become progressively more specific; add assessments that test transfer, not memorized command sequences.

Exit criteria: at least six small lessons share one engine; a malformed lesson fails validation before deployment; lessons can be tested without loading the 3D scene; the learner can author a lesson from a written objective; Git visualizations correctly distinguish working tree, index, commit, and branch state; and tmux material works with the documented default configuration and clearly labels any Groundwork-specific customization.

AI rule: use AI to critique lesson clarity, generate test cases, and identify ambiguity. Do not use AI as the authority for command semantics; verify against primary documentation.

Phase 5: Backend, accounts, and PostgreSQL · 6–8 weeks

Objectives: learn HTTP, APIs, authentication, databases, migrations, and deployment; preserve offline or anonymous use where practical.

Work: add a Node.js API; add PostgreSQL; add account creation or an external identity provider; store progress and content versions; define an authorization model; add request validation; add database constraints; add migrations; add structured logs; add API and integration tests; add a data-export and account-deletion path.

Exit criteria: the learner can explain authentication versus authorization; invalid input is rejected at the API boundary; database constraints protect important invariants; migrations work against a fresh database and an existing test database; logs do not contain credentials or sensitive tokens; anonymous use still works for the first lesson unless product requirements explicitly reject it; and the learner can restore a local database from a documented backup.

AI rule: AI may draft migrations, but the learner must review data-loss risk, rollback strategy, constraints, and transaction boundaries.

Phase 6: CI, delivery, observability, and operations · 4–6 weeks

Objectives: treat deployment and operation as part of software development; learn to diagnose environment differences.

Work: add CI for formatting, linting, type checking, unit tests, integration tests, browser tests, and build; cache dependencies carefully; pin toolchains and dependencies; add dependency updates with controlled grouping; add preview deployments if affordable and maintainable; add health checks; add error reporting; add performance measurements; write an operations runbook; practice a failed deployment and rollback; write one blameless incident review.

Exit criteria: a clean checkout can build from documented commands; CI and local required checks agree; a deliberately introduced failure is caught by the expected gate; the learner can identify whether a failure is code, configuration, dependency, network, or environment related; a rollback or recovery procedure has been exercised; and the product exposes enough signals to diagnose a failed user request without exposing private data.

AI rule: AI may help inspect logs and may drive bounded preview or non-production deployments under policy, but promoting to production stays an explicit, accountable human decision with post-deployment verification. The learner remains responsible.

Phase 7: Real isolated Linux labs · 8–10 weeks

Objectives: learn security boundaries, queues, resource controls, and untrusted execution; replace selected simulated exercises with real Linux environments.

Work: write a threat model; define which lessons actually require real execution; build a sandbox broker separate from the API; use purpose-built images; apply resource and network policies; add timeouts and cleanup; add abuse controls; add security tests; perform an internal review before any public exposure; keep simulated lessons as the default fallback.

Exit criteria: no public request can directly select runtime images, mounts, privileges, or host paths; every sandbox is short-lived and attributable to a bounded session; network access is denied unless a lesson explicitly requires it; resource-exhaustion tests pass; cleanup works after success, failure, timeout, and process crash; the learner can explain the trust boundaries and residual risks; and a reviewer other than the implementation agent has examined the design.

AI rule: do not delegate security approval to AI. AI can propose threats and tests; a human must validate the model and controls.

Phase 8: Rust and Tauri extension · 6–8 weeks

Objectives: learn Rust through a bounded production need; package the proven web application as an optional native app.

Candidate first project: a Rust lesson-pack validator that reads versioned lesson files, validates their schema and semantic invariants, produces deterministic diagnostics, can run locally and in CI, has property-based or table-driven tests, and exposes a stable command-line interface. Then integrate selected native features with Tauri.

Exit criteria: Rust is used for a clearly documented reason; the TypeScript/Rust boundary is small and tested; errors are handled without panics in normal user-input paths; the learner can explain ownership and borrowing in the component; native permissions are minimal; the web version remains functional; and install, update, and uninstall behavior is documented for supported platforms.

AI rule: the learner should manually implement core Rust exercises before relying on agent-generated Rust. Compiler success is not evidence that ownership decisions are understood.

Phase 9: Public beta and employment package · 6–8 weeks

Objectives: turn the repository into credible public evidence; practice issue triage, maintenance, and technical communication; prepare for general software roles, not only game jobs.

Work: run a small public beta; add contribution guidelines, a code of conduct, and issue templates; label good first issues honestly; publish architecture and security summaries; record a short product demonstration; write a case study; create a resume project section; practice explaining tradeoffs in interviews; contribute at least one meaningful fix or documentation improvement to an external open-source project.

Exit criteria: the public project includes clear setup instructions, screenshots or a demonstration, an architecture diagram, automated checks, a test strategy, an accessibility statement, a security model, a roadmap, known limitations, decision records, issues with useful context, a stable demonstration deployment or reproducible local demo, and no leaked credentials, personal data, or copied proprietary assets.

#AI-native engineering workflow

AI-native development should mean that AI is integrated into a disciplined engineering system. It should not mean the learner accepts whatever an agent produces. This is the same discipline as the vibe → agentic path and the agent rules.

Standard issue loop

1. Define the problem. Write the user impact, observed behavior, expected behavior, constraints, and non-goals.
2. Collect evidence. Reproduce the problem. Capture logs, tests, screenshots, or command output.
3. Design the smallest responsible change. Identify boundaries, risks, and verification.
4. Create an isolated branch or worktree. Keep unrelated work out of the diff.
5. Ask AI for a plan before implementation when the task is nontrivial. Compare the plan to the actual repository.
6. Allow bounded implementation. Give the agent explicit files, constraints, and acceptance criteria when possible.
7. Review the diff before trusting test results. Look for deleted checks, weakened types, ignored errors, new dependencies, scope creep, and silent behavior changes.
8. Run focused verification. Run tests closest to the change first.
9. Run repository-required gates. Formatting, lint, types, tests, builds, security checks, and generated-file checks as applicable.
10. Exercise the behavior manually. Automated tests can verify the wrong requirement.
11. Document the decision. Update the issue, commit, or decision record with important tradeoffs.
12. Commit intentionally. The final history should explain the change rather than expose agent chatter.

Mandatory learner questions before merging an AI-assisted change

• What problem does this solve?
• Which requirement proves the change is correct?
• What files changed, and why?
• What could still fail?
• What test would fail if this implementation regressed?
• Did the change weaken any validation, permission, or security boundary?
• Did it introduce or upgrade a dependency?
• Can I explain the code without asking the agent?
• Did I inspect generated files and lockfile changes?
• Is the final diff limited to the intended scope?

Common AI failure patterns to teach

Calling APIs that do not exist; using documentation from the wrong version; replacing a precise error with a broad catch; silencing a type error instead of fixing the model; deleting a failing test; mocking the behavior that should be tested; adding a dependency for a small standard-library task; forgetting platform differences; applying an unsafe shell command; logging secrets; changing configuration globally to solve a local problem; implementing a plausible feature that was not requested; fixing the visible symptom while preserving the underlying race or invariant violation; and declaring completion without running the required checks.

#Testing strategy

Do not attempt to test every 3D movement with brittle pixel-level assertions. Keep important game state testable outside the renderer.

#Documentation the project should maintain

Documentation should be updated in the same change that changes the behavior or contract.

#Portfolio evidence and hiring preparation

Repository evidence

A strong repository shows small, coherent commits; issues that explain why work is needed; pull requests with verification; tests that cover important behavior; decision records for meaningful tradeoffs; a readable architecture; a security model; dependency discipline; reproducible setup; and honest known limitations.

Case-study outline

1. Problem and intended learner
2. Why a first-person learning environment
3. Why browser-first TypeScript
4. Why the first shell was simulated
5. Architecture evolution
6. Accessibility decisions
7. Testing strategy
8. AI-assisted workflow and safeguards
9. Most difficult failure
10. Security model for real execution
11. Performance work
12. What would change with more users
13. What the learner personally implemented and learned

Interview stories

Prepare stories about diagnosing a bug that AI initially misidentified; simplifying an overengineered design; resolving a Git mistake without losing work; finding a local-versus-CI environment difference; improving accessibility after observing a user; adding a database invariant; handling a failed migration; rejecting an unsafe sandbox approach; measuring and improving a slow interaction; and receiving and acting on code-review feedback.

Resume bullets

Use measured facts only; adapt these once the metrics exist:

• Built a TypeScript and Babylon.js learning application that teaches terminal and Git concepts through an interactive first-person environment.
• Designed a deterministic simulated shell and virtual filesystem with automated lesson validation and test coverage.
• Implemented a Node.js and PostgreSQL progress service with runtime validation, migrations, and authorization checks.
• Added CI gates for types, tests, browser journeys, builds, and dependency integrity.
• Documented a deny-by-default security design for short-lived Linux exercise environments.
• Packaged the web application with Tauri and added a bounded Rust validation tool.

#Mentor and educator guidance

Weekly cadence

1. Learner demonstrates the current build.
2. Learner explains one technical concept without AI.
3. Mentor reviews one diff.
4. Mentor asks the learner to predict a failure.
5. Learner reproduces and diagnoses one failure.
6. Together they select the smallest next vertical slice.
7. Learner writes the issue and acceptance criteria.

Questions mentors should ask

What did you expect to happen? What evidence shows what actually happened? Which layer owns this behavior? What is the smallest experiment that separates the possible causes? What would make this test pass for the wrong reason? Which input is untrusted? What happens on Windows, macOS, and Linux? What did the AI assume? Which part can you explain without looking at the code? What would you remove if the project had to become simpler?

What mentors should avoid

Taking over the keyboard for long periods; replacing the learner's project with the mentor's preferred architecture; requiring advanced infrastructure before a useful vertical slice; grading progress by hours or lines of code; allowing AI to conceal missing fundamentals; treating compiler success as understanding; treating a polished demo as proof of maintainability; and fixing every problem before the learner can investigate it.

Assessment rubric

Evaluate each milestone across five dimensions:

A learner does not need to be perfect in every dimension before applying for jobs. The portfolio should show a consistent upward trajectory and several examples at the capable or job-ready level.

#Cost-control strategy

The project should be inexpensive while it is proving value. Track spend deliberately — the Know your AI budget page applies directly to the AI-assisted parts of this work.

Do not subsidize unrestricted public compute.

#Open-source and content licensing

Before publishing: choose an explicit code license; choose a content license separately if appropriate; record licenses for models, textures, sounds, fonts, and icons; avoid copying proprietary game assets or course content; prefer original, permissively licensed, or public-domain assets; preserve required attribution; document whether community lesson packs may be redistributed; and add a process for reporting copyright or trademark concerns. The project should not imply endorsement by terminal, engine, operating-system, or AI-tool vendors.

#Product metrics

#Definition of done for the first public milestone

The first milestone is complete when: one lesson can be completed from start to finish; the lesson teaches a real terminal mental model; the terminal is simulated and deterministic; the first-person mode and non-3D mode reach the same learning outcome; keyboard-only use works; progress can be saved locally; the critical path has an automated browser test; the project builds from a clean checkout; setup documentation has been tested by another person; no secret or private data is committed; assets have known licenses; known limitations are documented; and the learner can explain every major component. Anything beyond that is optional for the first public release.

#Primary resources

Use primary documentation as the default source for technical behavior.

Languages and web development

• TypeScript
• TypeScript Handbook
• MDN Learn Web Development
• MDN JavaScript Guide
• Node.js learning resources

Terminal, tmux, and Git

• tmux project wiki
• tmux getting started
• Pro Git book
• Git reference

Recommended product stack

• Babylon.js
• Babylon.js Playground
• xterm.js
• Docker documentation
• Tauri 2
• Rust
• Learn Rust

Market and workflow context

• GitHub Octoverse 2025: TypeScript becomes the most-used language on GitHub
• 2025 Stack Overflow Developer Survey: Technology
• 2025 Stack Overflow Developer Survey: AI
• U.S. Bureau of Labor Statistics: Software Developers, QA Analysts, and Testers
• GDC 2026 State of the Game Industry summary

#Final recommendation

Build the learner's career foundation around TypeScript, the terminal, Linux concepts, Git, testing, databases, deployment, and responsible AI-assisted engineering. Use a browser-based first-person educational product to make that work motivating and visible. Keep Unity available for creative prototypes. Defer Unreal until a specific specialization requires it. Introduce Rust after the learner has shipped a complete TypeScript product, and use it for a bounded component with a real reason to exist.

The resulting developer should not be limited to saying, “I know a game engine.” The goal is to be able to say: