There is a small, stubborn result buried in learning-science literature that architecture schools have never fully digested: people acquire a programming language faster when the feedback loop is a consequence rather than a grade. MIT’s Media Lab built most of Scratch on that premise, and the constructionist line running back to Seymour Papert’s work on Logo in the late 1960s says the same thing — a learner who is debugging a turtle that walked into a wall is engaged in a different cognitive act than a learner who is being marked wrong. Papert called the broken program “a chance to learn something”. That is the frontier anchor for today’s piece, and the line into your desk is shorter than it looks.

Because the thing that finally taught a lot of working architects to write real TypeScript was not a course. It was a game about hacking.

The Tool: Bitburner — the open-source repo at bitburner-official/bitburner-src — is, in its own README’s words, “a programming-based incremental game that revolves around hacking and cyberpunk themes”. The README names exactly three ways to run it: the release build at bitburner-official.github.io, the development build at bitburner-official.github.io/bitburner-src, and a Steam install — with the honest warning that the release-build location “may change in the near future”. It also names exactly two kinds of documentation, and the second is the reason this is worth an architect’s afternoon: the in-game Documentation tab, which the README calls the best place for up-to-date information, and the NS API reference, which is “generated from the TypeScript definitions”. You are not writing toy code in a fake language. You are writing real TypeScript against a real typed API, in an editor with real autocomplete, and the game refuses to run your script if you got the types wrong. The project is community-built and community-maintained — CONTRIBUTING has a whole “As A Documenter” section, it explicitly welcomes people whose first contribution is fixing a typo, contributors retain full copyright on what they write with a formal Contributor’s License Agreement still to be drawn up, and anyone wanting to work as a collaborator is pointed at #suggestions or #development on the project Discord. That governance detail is not filler. It is why the thing still exists.

The mechanism is old and good. An incremental game gives you a loop that pays out in minutes; a typed API gives you a compiler that argues with you; the combination gives a beginner the two things a Tuesday-evening tutorial never does — stakes and immediate correction. Five years ago this would have been a curiosity. It is a serious teaching instrument now because the ecosystem underneath it matured: TypeScript’s language server is good enough that hover-documentation and type errors arrive before you run anything, which means the game is quietly running the same feedback loop as a professional IDE.

←TODAY: An open-source browser game ships a fully typed TypeScript API and generates its own docs from the .d.ts definitions. →3012: In Zurich-3012 the office’s scripting literacy is infrastructure, like drainage — invisible until the day it is missing. Fulcrum: The cheapest way to teach a studio to read a typed API is to give them a system where being wrong has consequences and nobody is watching.

Setup

Setup: You can simply play it in the browser. But the repo is where you learn something, because the same Node toolchain that builds the game is the one your office will use for every future web-facing script.

# Node 20 or newer
git clone https://github.com/bitburner-official/bitburner-src.git
cd bitburner-src
npm install
npm run start:dev
# open the URL printed in the terminal (Vite dev server)
# in-game: open the Terminal tab, then type:
#   nano hello.js
# paste the script from First steps, Ctrl+B to save, then:
#   run hello.js

First steps

First steps:

1. Write one script that does one thing. In the in-game nano editor, create hello.js with export async function main(ns) { ns.tprint(ns.getHostname()); }. Run it. You have now executed a typed entry point with an injected namespace object — the same dependency-injection shape you will meet in every modern plugin API you ever touch.
2. Break it on purpose. Call ns.tprint() with no argument, or misspell the method. Read the error. The NS API docs are generated from the .d.ts files, so the error text and the documentation are the same artifact — this is the first time many people see that types are the documentation.
3. Write a loop with a cost. Scripts consume simulated RAM proportional to which NS functions you call. Add a second function call and watch your RAM budget change. This is the lesson: every API call has a price, and a good script is one that does the job within a budget. Sound familiar to anyone who has watched a Grasshopper definition take four minutes to recompute?
4. Move to the real editor. Point VS Code at the repo, install the NS type definitions, and write your scripts outside the game. Now you have autocomplete, and the loop closes.

The trade-off, stated plainly: an incremental game is engineered to consume time, and it will consume more of yours than a tutorial would. That is a property of the genre, not a flaw in this project — and the same property is what keeps people writing code past the point where a course would have lost them. Decide which of those two facts matters more to you before you install it.

Atelier: A twelve-person studio in Zürich that runs Rhino and Grasshopper and has exactly one person who “does the scripts” is carrying a single point of failure, and everybody in the room knows it. The classic fix — book a course, lose two billable days, watch the knowledge evaporate by autumn — is expensive and unreliable. Your Monday move: pick the two people in the office who have said “I’d like to learn to code” and never had a route in, and give them Bitburner plus one protected hour a week. Not as a perk. As the pre-course — the thing that makes a real Grasshopper 2 or C# training land, because by the time they arrive they already know what a typed API, a function signature and a runtime error are. PAZ Academy has been teaching and implementing Grasshopper 2 since the Alpha, and the students who arrive already able to read a type signature get roughly twice as far in the same two days.

Hack: Read a typed API’s shape from the type definitions instead of hunting through prose docs. Bitburner generates its NS documentation straight from TypeScript, so NetscriptDefinitions.d.ts is the manual — and the same trick works on any npm package on your machine. Three lines of shell pull every function signature out of a definition file:

find . -name "NetscriptDefinitions.d.ts"     # it ships inside the repo
grep -nE "^\s{2,}[a-zA-Z_]+\(" "$(find . -name NetscriptDefinitions.d.ts | head -1)" | head -40
npx tsc --noEmit --strict yourscript.ts      # the compiler answers before the runtime does

That last line is the whole discipline in one command: let the type checker tell you you are wrong while the file is still open, not while the site is waiting. Architects already work this way with structural pre-dimensioning. The habit transfers.

There is a second reason to learn this in a sandbox, and it is not a comfortable one. Just this month, heise online reported that researchers at LastPass found a new infostealer variant distributed through repositories dressed up to look legitimate on GitHub — malware wearing the costume of an open-source project. The defence is not paranoia about open source; it is fluency. A person who has read a few hundred lines of someone else’s JavaScript can tell the difference between a build script and an exfiltration script. A person who has never read any cannot. In an office where every second plugin arrives as a zip from a forum, that literacy is a security control, and it is cheaper than any tool you could buy to replace it.

The long view from where I sit: the stacks that survived were the ones whose files a stranger could still open and still read. Bitburner’s README hands you the whole build, the whole API, the contribution terms, and the note that contributors keep their own copyright — that is what a repairable system looks like, written down. PAZ’s own openBIM concept panel makes the same argument with IfcOpenShell: an IFC4 file is plain text you can open in Notepad, walk with twenty lines of Python, and gate in CI — read Pset_WallCommon.FireRating on every IfcWall, raise SystemExit on the misses, and a bad model never reaches the engineer. That is the buildingSMART Validation Service pattern in miniature, an IDS-style requirement checking itself. Same principle, different domain. Readable beats convenient, every decade, without exception.

Learn-it:

• bitburner-official/bitburner-src — the source repo; start with CONTRIBUTING and its “As A Documenter” section if you want to give something back.
• Bitburner (release build) — play it in the browser; the README notes this URL may move.
• Development build — what the current main branch actually does.
• In-game Documentation tab — per the README, the most up-to-date source; the NS API reference is generated from the TypeScript definitions.
• PAZ note: pair it with the openBIM Hack panel — IfcOpenShell walking an IFC4 file for Pset_WallCommon.FireRating is the same skill applied to your own building data.

Install it on the office machine that already runs Rhino, give two colleagues an hour a week, and check in October whether anyone has stopped asking the scripts person to fix their file.