Software stack is an abstraction made for humans. AI can skip it

An AI agent wrote HarvestChain, a complete 3D turn-based strategy game, in 10,578 lines of WebAssembly text across 681 functions, shipping in 40 KB compressed with zero image files, frameworks, game engines or runtime dependencies, according to the experiment's public GitHub repository. The agent's output was verified by 705 automated tests (571 unit and 134 browser tests) plus build rules banning floating-point math and enforcing a hard size budget, replacing human code review and type checking. The author argues the game still depends on a 3.4 KB JavaScript loader, has thinner accessibility than an ordinary web page, and is hard for people to read, making the approach suited to edge and small-device code rather than a bank's core ledger.

Experiment · AI and software engineering Your tech stack is an abstraction made for humans. AI can skip it.In 26 hours, an AI agent wrote 10,578 lines of WebAssembly and shipped a complete 3D strategy game in 40 KB. The median mobile page weighs 2,164 KB. The code is ten thousand lines of stack machine instructions, so 705 tests do the checking instead of people. One small JavaScript loader is the only thing the game could not do without. Here is what held up, what it gave up, and which of the tools you use every day should be worried. In short - What the stack is for. Languages, frameworks, bundlers and engines exist to cover human limits: readable code, shared conventions, forgiving memory. An AI agent has none of those limits, so many of those layers have nothing left to do. - Where the safety went. Types and code review used to catch mistakes. In HarvestChain, 705 automated tests and build rules that fail the build do it, including a ban on floating point maths and a hard size budget. - What it cost. It still needs a 3.4 KB JavaScript loader, its accessibility is thinner than an ordinary web page, and its code is hard for people to read. - Who should try it. Code at the edge or on small devices, anything where size or start time decides the outcome, and anything that must reproduce exactly. Not a bank's core ledger. 40 KB The whole game over the wire, compressed: one WebAssembly module, one small HTML loader and one service worker for offline play. 10,578 Lines of WebAssembly text in 681 functions, written by the agent. No Rust, no C, no compiler from a friendlier language. 0 Image files, font files, frameworks, game engines or runtime dependencies. 705 Automated tests: 571 unit tests and 134 browser tests. They, not the code, are where a human checks the work. Every abstraction in software is a kindness to a person, and a tech stack is those kindnesses piled up. We write in high level languages because nobody can hold a stack machine in their head. We use frameworks so a team of fifty shares one set of conventions. We add bundlers and transpilers to tidy up after the frameworks, engines so nobody has to write a rasteriser, and garbage collectors because people forget to free memory. Each of those layers is a good decision. Each also costs something: bytes to download, time before the first frame, a dependency tree to keep current, and a gap between what the author wrote and what the machine actually runs. For forty years the trade was obviously worth it, because the author was always a person. That assumption is weakening. A growing share of code is now written by agents that do not get tired, do not need conventions to coordinate with colleagues, and are not bothered by stack machines. So I asked the question again, concretely: if the author is not human, which layers are still paying rent? A quick definition, since the rest depends on it. WebAssembly is the compact instruction format that browsers run alongside JavaScript. Its text format is the readable spelling of those instructions. Writing in it is as close to the machine as a web developer can get. The full source, design spec and rulings are public on GitHub https://github.com/vithushanms/HarvestChain . Start with the README https://github.com/vithushanms/HarvestChain readme . If you read only one part, make it III. It covers where the safety went once the layers were gone, and it applies to your code whether or not you ever touch WebAssembly. The experiment Can an AI agent build a complete game in raw WebAssembly? Yes. The test case is HarvestChain, a turn based strategy game about a farm supply chain. You plant five crops, each with its own seasons. You process them into goods worth more: the mill makes flour, the bakery bread, the cannery sauce, the press juice and the cellar ages juice into wine. You sell at a farm stand or truck the goods to town and the city, chasing contracts against deadlines while weather, spoilage, loans and falling prices push back. A run lasts three in game years. It plays on a phone in portrait and on a laptop from the same build, and it works offline. The rule was simple and deliberately extreme. Everything is written by an AI agent, Claude Code, directly in WebAssembly text format. There is no higher level language compiled down to it. The simulation, an isometric 3D renderer, the interface toolkit, input handling, saving, a replay viewer and a QR code encoder all live in one module. The project began as a written design spec and a set of phased implementation plans. The agent then worked through them in 91 commits, from 02:24 on 26 October to 04:02 the next morning. That is elapsed time, not a measure of effort, but it is a useful sense of scale. The result How small and fast is a game with no framework? The most visible result is size. The entire game, including its 3D renderer, its fonts and every building and crop, is 40 KB over the wire. The median mobile web page in 2025 weighed 2,164 KB, and spent 646 KB of that on JavaScript alone. Speed follows from the same absence. With nothing to parse, link or set up, the first frame appears about 23 milliseconds after navigation starts. Ending a day, which runs weather, growth, processing, spoilage, trucks, contracts, prices and loan interest, takes a median of 5 microseconds. Redrawing the full 3D scene takes under half a millisecond. These were measured on a laptop against a local server, so they are a best case rather than a field result, but the order of magnitude is the point. There is also nothing to maintain underneath. The deliverable is three static files. There is no framework to fall behind, no package tree to patch and no server. The only tools involved, an assembler and an optimiser, are build time dependencies pinned to exact versions. Figure 4 HarvestChain by the numbers Every figure in this article about the game, in one place. | Measure | Value | |---|---| | Total transfer size, compressed | 40,049 bytes 40 KB | | WebAssembly module, compressed | 36 KB, no imports | | JavaScript loader | 3.4 KB, no game logic | | Source | 10,578 lines of WebAssembly text, 681 functions | | First frame after navigation | About 23 ms | | Ending a game day | 5 microseconds, median | | Redrawing the full 3D scene | Under 0.5 ms | | Automated tests | 705 571 unit, 134 browser | | Build history | 91 commits in about 26 hours | Measured 26 October 2026 on an Apple M3 Pro with Node 24 and Chromium. Timings are best case, from browser tests against a local server. The shift If AI writes the code, where do the guardrails go? This is the part I think matters most, and it is not about games. Languages and frameworks do more than make code pleasant to write. They catch mistakes. A type system refuses whole categories of error before anything runs. WebAssembly text catches almost nothing: it will happily let you write a number into the wrong part of memory. Remove the human friendly layers and you also remove most of the safety they provided. So the safety had to go somewhere else. In HarvestChain it lives in the build and the tests, as rules the agent cannot argue with: - A size budget that fails the build. If the module grows past 40 KB compressed, nothing ships. - A ban on floating point maths. The build fails if the word for a decimal number appears anywhere in the source. Money is whole dollars; multipliers are basis points. - One source of randomness. Every random number comes from one generator, at a fixed list of call sites. The build fails if drawing code touches the simulation's generator. - Pinned outcomes. A bot plays 240 days on fixed seeds and the final state is pinned to a hash. Fourteen farm scenes and 58 interface states are pinned pixel for pixel at two screen sizes. - Purity checks. Drawing the screen may never change the game. Every state is rendered fresh and after other states, and the pixels must match. - Independent verification. Every QR code the game draws is decoded back by a separate, third party decoder. The effect is that the human's job changes shape. The material a person needs to understand is the spec, the plans and the tests. The code itself becomes something you check by its behaviour rather than by reading it line by line. One detail stood out. Where the spec was silent or contradicted itself, the agent did not guess quietly. It wrote down a ruling, why it made it, and what it would cost if the ruling were wrong. That log is the most useful governance document in the project, and it is the pattern I would want from any agent working on anything that matters. When the agent writes the code, the spec and the tests become the source code that humans own. The bonus Why can anyone replay a whole run from a share code? Because the game is deterministic. The strict rules bought something beyond size. The game uses only whole number maths and draws random numbers in a fixed order, so the same starting seed and the same sequence of player inputs produce byte identical results on every device. A phone in Colombo and a laptop in North Carolina will agree to the last bit. That turns a whole three year run into a short share code. Paste it, and anyone can watch the run replay, scrub through it day by day, or take over and play on from any point they choose. Short runs fit in a QR code the game draws itself. Floating point maths and garbage collection make that guarantee hard to keep across devices. Removing them made it nearly free. The same property matters well beyond games: anywhere a result needs to be reproduced exactly and proven later, a simulation, a model run, an audit trail, determinism is a feature worth designing for from the first line. Limits What did this experiment not prove? An honest account needs the misses too. - It is not pure WebAssembly. A 3.4 KB JavaScript loader is still needed, because WebAssembly cannot reach the screen, storage or clipboard on its own. It holds no game logic, but it exists. - Accessibility is thinner. A canvas game cannot lean on the browser's built in accessibility the way an ordinary web page can. HarvestChain announces every action to screen readers and offers large text, but there is no full text version of the interface, and the pixel font is upper case only. - The code is hard for people to read. Ten thousand lines of stack machine instructions are not something most engineers can maintain by hand. Choosing this approach is a bet that capable agents remain available. For a small game, that is a reasonable bet. For a bank's core ledger, it is not one I would make today. - It is one experiment. One project, one agent, one person directing it. It shows what is possible, not what is typical. Implications Which software layers still matter when AI writes the code? The ones that help someone verify the work. The layers we inherited were priced for human authors. When agents write more of the code, the value of each layer depends on a different question: does it help someone check the work, or does it mainly make the work pleasant to write? Layers that help verification gain value: types, contracts, tests, budgets enforced in the build, specs precise enough to check against. Layers that exist mainly for writing comfort lose some of theirs, and their costs in size, speed and maintenance start to look less necessary. Every layer in your stack is a bet that a human will read what it produces. I would not rewrite an enterprise platform this way, and I do not think anyone should. A large shared codebase that many people still read every day needs the human layers. But there are clear places to try it now: code that runs at the edge or on small devices, anything where payload size or start time decides the outcome, and components where exact reproducibility is a requirement rather than a nicety. For technology leaders, the durable skill is the one that sat at the start of this project: writing a precise spec and the checks that hold an agent to it. In HarvestChain, the most important file is not a WebAssembly file at all. The same shift shows up in hiring. For what it is doing to the labour market, see Are tech workers cooked? https://vithushansylvester.com/writing/the-real-impact-of-ai-on-tech-jobs , which follows seven years of data on AI and tech jobs. So can an AI skip your tech stack? For a small, self contained game, it just did. For most teams today, not wholesale. But the question it raises, layer by layer, is the right one to start asking. The software stack was built for us. For a growing share of the code, we are no longer the only authors. It is worth asking, layer by layer, who each one is still for. Data and sources Sizes, test counts and timings come from the HarvestChain repository and the game's own stats overlay, measured on 26 October 2026 on an Apple M3 Pro with Node 24 and Chromium. First frame times are from browser tests against a local server. Line and function counts are of the source files at the time of writing. Page weight figures are HTTP Archive medians for mobile pages in its 2025 crawl. Written on 27 October 2026, the day after the game was finished. Every figure about HarvestChain can be reproduced from its repository with npm test and npm run size-report . Short answers Questions this article answers - What is a tech stack, and can AI skip it? - A tech stack is the pile of languages, frameworks, bundlers and engines between your code and the machine. Those layers are abstractions made for human limits: readability, shared conventions, forgiving memory. An AI agent does not share those limits. Claude Code built a complete game directly in WebAssembly without them, in 40 KB. It is one experiment, and the safety the layers gave had to move into tests and build rules. - Can an AI agent write WebAssembly directly? - Yes. Claude Code wrote a complete game, HarvestChain, directly in WebAssembly text format: 10,578 lines in 681 functions covering the simulation, an isometric 3D renderer, the interface, saving, replays and a QR code encoder. No higher level language was compiled down to it. - How small can a complete web game be? - HarvestChain is 40 KB over the wire, compressed: one WebAssembly module, one small HTML loader and one service worker. The median mobile web page in 2025 weighed 2,164 KB, with 646 KB of JavaScript. The comparison is not like for like, but it shows what the usual layers cost. - Do programming languages and frameworks still matter if AI writes the code? - They matter for checking, less for writing. Types, contracts, tests, build time budgets and precise specs gain value because they let a person verify the work. Layers that mainly make code pleasant for humans to write lose some of theirs. - How do you trust code that people do not read line by line? - By moving the guardrails into the build and the tests. HarvestChain fails the build on a size budget, bans floating point maths, allows one source of randomness, pins a 240 day bot run to a hash, pins 14 farm scenes and 58 interface states pixel for pixel, and decodes every QR code with a third party decoder. 705 automated tests back this up. - Why does the same game run identically on every device? - The game uses only whole number maths and draws random numbers in a fixed order. The same seed and the same player inputs therefore produce byte identical results everywhere, which is why a whole three year run fits in a short share code that anyone can replay. - What did the experiment not prove? - It still needs a 3.4 KB JavaScript loader because WebAssembly cannot reach the screen, storage or clipboard on its own, accessibility is thinner than on an ordinary web page, the code is hard for people to read, and it is one project with one agent. - Should companies build software this way? - Not for large shared codebases that many people read every day. It is worth trying for code that runs at the edge or on small devices, where payload size or start time decides the outcome, and where exact reproducibility is a requirement.