Gregory Mitchell

I have said for years that I started programming in late 2018. That is when I started typing code, and it is wrong by two years. The oldest thing I have ever published is a Scratch project called "My Game," dated December 10, 2016, when I was eight. It predates my oldest repository by four months. The profile it lived on is a 404 now, but the seventeen projects under it are still there.

Read the titles in order and you can watch it happen. The first three are animations. Then they turn into games with actual mechanics - a chase, a launcher, a jumper - two of them shipped on the same day in March 2017, which is the burst habit showing up at eight. Then the pair I cannot get over: in August 2017 I shipped "Maze Run Infinite (Prerealease)," misspelled, and three months later "Clicker Full release." A prerelease and a full release, at nine, in a drag-and-drop editor that has no concept of either. My second account went further and put semantic versions in the titles - "Question Studio V. 1.0.0.2" - four components, at eleven, for a thing you cannot install.

Nobody was watching. Seventeen projects over two years drew about fifty views between them, and my best-performing work of that entire era was a Minecraft trivia quiz that fourteen people opened. I kept versioning them anyway.

The names tracked who I thought I was the whole time. MathyCrafter at seven (from accidentally setting my Minecraft username to an old email password), GamerTeach at nine because I was forever teaching my friends about the games I played, then GamerCoder215 at eleven. Gamer to teacher to coder, in three handles, before anyone had read a line of it.

The text came later, and people assume I was handed it. I was not. My father runs Bright Plum, a Drupal and PHP web shop, and he did not want me going into tech. Not a prohibition and not hostility; he was not going to stop me, and he would provide what I needed. What I got was an environment, not an education - a real codebase, a real client, and a real deployment within arm's reach at an age when most self-taught kids have only tutorials. But the teaching was one framework, in late 2018, and nothing else directly after it.

Across all my repositories my father appears in exactly two, both client work: my aunt's art portfolio, which he stopped wanting to maintain and I have now kept running for seven years, and my grandfather's law practice, which I scaffolded in a single week so he could run it himself. He still edits it.

My first computer was a Mac mini, and its hostname is still sitting in my git history as an author identity. Everything it ever recorded, from September 2019 to April 2020, was work on my aunt's paintings. The first thing my first machine did was catalogue somebody else's art. My early projects sit under the Bright Plum org because I decided they would get more reach there and worked out the transfer myself, which is a twelve-year-old doing distribution strategy with the only brand available to him. Every domain since has been one I bought with my own money: gamercoder215.me, teaminceptus.us for the studio I ran at thirteen, then gmitch215.xyz, .dev, .blog, and .fun.

The gap between 2021 me and 2022 me is the largest single-year leap in the record. In one year I went from a kid pasting getters to a developer running open-source projects like an adult, and my commit count went up fivefold. Three things happened at once.

I learned real build engineering. My Maven plugins migrated to multi-module Gradle Kotlin DSL, and Novaconomy grew a 25-version NMS abstraction layer: reflection-based adapters for every Minecraft server release from 1.8 to 1.20. Minecraft's internals are obfuscated and change every version; abstracting across 25 of them is the kind of thing that defeats professional plugin developers.

Then I shipped my best work. MobChip, an Entity AI Library for SpigotMC, wraps Minecraft's native mob-AI internals behind a clean, fully documented public API across 17 versioned adapters. It has 35 test files, CI, a Discord community, and a real Maven repository other developers depended on. At 88 stars it is still my most successful project by a wide margin, and after I stopped maintaining it another developer took it over, which is about the highest compliment an open-source library can get.

Then came the Big 4: Novaconomy, StarCosmetics, PlasmaEnchants, and BattleCards, alongside MobChip the library. By the end of the year a fourteen-year-old was maintaining multiple published libraries, with tests, CI, and versioned releases, that real strangers used. That is not a normal hobby. It is an apprenticeship completing itself.

2024 opened with the most advanced thing I ever built in Minecraft, then pivoted hard toward range. SocketMC pairs a server plugin with a client mod over a socket protocol, bridging the two halves of Minecraft development that normally cannot talk to each other. It was the technical capstone of my Minecraft years, and a direct ancestor of edgeport: both are fundamentally about making two machines talk over a socket.

Then I proved multi-language fluency in one artifact. benchmarks is a harness that compiles and runs the same algorithms across C, C++, Go, Java, JavaScript, Kotlin, Kotlin/Native, PHP, Ruby, Rust, and Zig, times them, and plots the results. You cannot fake that; it requires writing correct, idiomatic, comparably-optimized code in ten languages at once.

I also founded Calculus Games, an indie studio, and designed LevelZ, a human-readable file format for game levels backed with parsers in six languages, an IntelliJ plugin, a VSCode extension, and a CLI. That is more completeness than most formats get from an entire company. By the end of the year I had shipped libraries in three package ecosystems and written production code in ten languages. I was sixteen.

Three storylines converge in 2025, and this is the year the mission gets discovered and decided. The first is cmdfx, a game engine for the terminal written from scratch in C, begun in January 2025. CMake build, sanitizer harnesses, a hand-rolled assertion library, Doxygen docs, a Homebrew formula, and installers for Windows, macOS, and Linux.

It came sideways from kasciffy, my ASCII-art engine in Kotlin Multiplatform: I needed an excuse to get back into C. This is a demo of it from that January, a clip of an arcade hoop followed by the same scene redrawn as a brightness ramp of plain characters.

I used to call cmdfx my clean control sample. It is not, and I would rather correct that than keep the better story. My editor's own stored chat history puts conversational AI in this project from April 2025 - the first session is me asking why my mutex was interleaving printf output - so 298 of its 465 commits predate any assistance and the rest had it available. The real control sample is bigger anyway and does not need cmdfx to prop it up: 6,850 commits predate my first chat prompt entirely, including every line of the Minecraft years, and 9,683 predate any agentic tool. Three instruments gave three different answers for when I started using AI, I checked the most convenient one last, and the number moved by thousands of commits.

The second is a job. That summer, at sixteen, I taught Java to seventh through ninth graders in downtown Chicago, an hour from home, writing my own curriculum and delivering the lessons myself. The nine-year-old who called himself GamerTeach grew up and actually taught, and it is not a coincidence that this is the same person who wants to study psychology.

The third is The Earth App. In May 2025 I founded the org and began the most ambitious thing I had attempted: a social platform to fight loneliness and the mental-health crisis, built as a five-language microservices architecture. The backend started as a hand-written TypeScript service on Hono and was simply too slow paired with CollegeDB, the sharding router I had pulled out of it. Facing a re-platform, I took my father's recommendation and went to Drupal. That is the only piece of technical advice from him anywhere in this story, accepted on its merits after a measured failure, and it is the seed that eventually grew into Drupflare. I submitted the app to the 2025 Congressional App Challenge in Illinois' 2nd District, and won.

This is where it crystallizes. I am easily drained, and more than anything I want to feel included; in 2025 I decided to point my one real superpower at the thing that hurts. From here on the code has a purpose that is not about code.

On August 9 I started a feasibility spike in a scratch directory to answer one question: can Drupal 11 run on Cloudflare Workers? It shipped as v1.0.0 on September 13, and the organization now holds thirteen repositories and 1,997 of my commits. Drupal 11, with PHP 8.5 compiled to WebAssembly, executing inside a Durable Object, using that object's own SQLite as the database. No VPS, no container, no origin server.

What makes it a real result instead of a stunt is the wall I hit on day two. workerd forbids WebAssembly codegen at request time but permits it during module evaluation, and every published php-wasm build in existence is a dynamic-linking build whose linker synthesizes trampolines at runtime. So extensions can never load, so Drupal's required dom, xml, SimpleXML, mbstring and gd are simply unavailable. A statically linked interpreter was not an optimization; it was a precondition. So I built one, and that is phasm.

Then I made it fit, and two sessions of compression engineering became history overnight. The free plan allowed a 3,145,728-byte compressed worker, so the interpreter travelled as a zstd frame inflated at module scope. On September 4 Cloudflare deleted that limit, replacing it with 64 MiB uncompressed. The correct response is not to mourn the work: any refusal whose reason was bundle size needs re-scoring, not re-refusing. A cached page costs 1 ms of Durable Object CPU, a full uncached render 34 ms against 9.47 ms for native PHP, and cold boot is 1,398 ms.

Most of the repositories stand on their own, including durabledb, which exists only because Durable Object SQLite's real limits are undocumented: 100 bound parameters where local PDO allows 32,766, a 50-byte ceiling on a LIKE pattern, and lossy integer reads above 2^53. Each broke something real before it got written down.

The roadmap argues against its own speed table, and that is the part I care about most: "drupflare has to become more than a faster host, because as a faster host it is not worth building. A 1.21x re-render does not justify a runtime." What justifies it is one question - how much continuously provisioned hardware this makes unnecessary. I measured it on my own bare-metal machine through the processor's energy counter, and the first result cuts against the obvious pitch: PHP in wasm costs the same energy per request as native PHP-FPM, to within 13%. The saving is not in the interpreter. Small-site hosting is bound by memory rather than CPU, so a box packing a thousand sites spends its whole year idle while a Worker draws power only while a request runs, and my page store expires on an edit where a CDN expires on a clock. At twenty million views a month that is 186,371 renders a day against about 25.

The measurements were all on my own sites, so v1.0.3, on October 2, pointed the runtime at other people's software. I pinned 27 production Drupal codebases by commit and drove each through a 13-row capability lane. Fifteen pass all 13 on a local runtime, GovCMS, Thunder, farmOS, Islandora and my own mantle2 among them, and farmOS, GovCMS and Thunder pass on a deployed Worker too, though Thunder's result does not reproduce on every deploy. The pass found 104 defects: 46 in the product, 39 in the lane and its probes, 16 in the native install harness and 3 upstream. Fourteen of the product defects appeared only once deployed. The same release made migration a product - drangler preview copies a live site over read-only SSH, converting MySQL, MariaDB or PostgreSQL and carrying its files, code and configuration - and I bought drupflare.com and drupflare.app.

On October 7 I reopened my own rule that v1.0.3 was the last patch release. v1.0.4 is a proof release, and the roadmap writes its pass conditions before any run: a drangler preview of The Earth App's production server, run twice with no manual steps; an owner patching a deployed site in one click, where a deliberately broken update has to roll back; and an energy experiment that must be published before a "25% less energy per request" sentence is allowed for any class of site. The next day an experiment with the Workers Cache lost. A purge reported success while leaving an old copy in 6 of 26 rounds, and a Durable Object, which is where saves happen, cannot purge at all. It ran on two throwaway free-plan workers, the account read zero Workers afterward, and it cost $0. That closes a mechanism. The goal - answering a public request before the application runs - stays open.

It turned out not to be a project at all. It was a technique, and within three weeks I had applied it twice more. bytebox is Java on Cloudflare Workers: apply a Gradle plugin to a Java workspace and it compiles into a Worker through TeaVM, feeding cartridge, the wasm-interpreter host I had already extracted from Drupflare. tinyimg points the same instinct at images: workerd has no Canvas API, so I wrote freestanding C compiled to a single wasm32 module that decodes, transforms and re-encodes inside the Worker's own CPU budget, at $0.05 per million transformations against Cloudflare Images' $500. Then burrow removed the last requirement. Everything up to it got past the codegen wall by knowing its code at deploy time; burrow runs a guest module that arrives with the request, by not compiling it - an interpreter ships in the bundle and the program becomes data. workforce and bastion made it operable: a fleet library for deployed Workers, and a hardened single-binary environment that runs the whole stack on your own hardware, because workerd by itself "is not a hardened multi-tenant sandbox, and its own repository says so."

On September 19 I published my first paper, sole-authored, on the method underneath all of this: Retargeting Managed Runtimes to Serverless WebAssembly, on figshare and Zenodo under CC BY 4.0 with the artifact pinned to a specific commit. It is published and citable, not yet refereed; I am seeking an arXiv endorsement, and the Journal of Open Source Software asked for six months of public history first, so that resubmission waits until February 2027. Its least comfortable result is the one I like best: a correctly translated regular expression, semantically identical, cost 14 ms on a real JVM and 11,010 ms on the host engine. Semantic agreement is not operational equivalence.

Drupal is the one thing I was actually taught: late 2018, in my father's shop, and nothing else directly after it. It came back at seventeen as his single recommendation, when my TypeScript backend proved too slow. Then at eighteen I took that one tool and did something with it that nobody in that shop asked for or advised on. Every architectural decision here is mine - my father has no commit anywhere in the Drupflare organization, and none in The Earth App. What I was given was one framework and one suggestion.

Drupflare's savings were measured on small, mostly idle sites. The obvious next question is whether they survive on machines that are busy, and I put it to myself in those words: "is this a strong product or a fever dream? and if it is the latter, what prevents it from being the former?" Then I bounded it so it could actually be answered. No Containers, no partial serverless; "the testable primitive is one traditional cloudflare worker."

gmux is a real Linux kernel - not a syscall shim over another kernel - running inside a single Worker deployment, each machine a Durable Object, on the free plan. A day and a half after the first experiment it was public and reproducible: a kernel boots to a BusyBox shell in a 476 ms median, fork works from unmodified C programs, dlopen works, a 1 GiB pipeline finishes exactly across five free-plan events, and a whole booted machine checkpoints mid-job, survives a forced eviction, and restores exactly. Unchanged x86-64 binaries - BusyBox, coreutils, bash, sqlite3, curl - match native Linux on 117 of 117 transcript lines through my translator.

The design was decided by a deployment, not a theory. The ceiling on a running machine turned out to be task count, not CPU: the kernel fork gives every task its own instance of about 2.7 MiB, boot alone creates 48, and the machine died silently after roughly ten more processes while still reporting the event as ok. The kernel has five mutable globals, so now every task runs on one instance and I swap those five words at each context switch. Between October 2 and 4 the work moved from single experiments to batches. One run lasted 12.3 hours under a Sonnet coordinator and four Sonnet lanes with my own session idle, and spent $251.43 of a $337.50 limit that I wrote down beforehand. It produced the first inbound connection into a machine: an unmodified BusyBox httpd serving behind the site, with response bodies equal to native Linux in 6 of 6 cases.

I keep three claims apart, and I am strict about it, because this is exactly where a demo gets mistaken for a result: compatibility (same observable output), resource equivalence (comparable CPU, memory and energy), and negative optimization (work that no longer happens and nothing notices). A shell prompt is none of the three. Booting is none of the three. Eliminated is also not the same as moved - Linux's TCP stack disappearing because Cloudflare terminated the connection lowers my CPU, but the network processing still happened, so it does not count. My own sensitivity table prints the rows where gmux loses: on a host already running at 50% with nothing eliminated, it costs 10% more. And the v1 bar has grown instead of narrowing: twenty-eight named workloads, from compilers and databases to Kafka and 70-billion-parameter models, each held to a speed ratio of at most 1.0 against native Linux on every run. The translated x86-64 path ran CPU-bound programs 99 to 331 times slower than native in the September table, and one hand-picked block has since reached 5. That is the distance, measured instead of guessed.

In October I started Drift, which takes the question every developer asks of a failing build - why does it pass here and fail there - and makes it a tool. drift capture records an environment as a hashed capsule, drift diagnose ranks what differs between a passing run and a failing one, and drift verify re-derives every count and verdict from the archived case alone. It is Kotlin Multiplatform, like kasciffy, with 88.4% of its lines in common code. Its second product is a portability atlas of 38 small programs recorded on 13 Kotlin targets, of which 23 print different output on at least one. I published the weak result next to the strong ones: on the 41 development scenarios with a known cause, the right cause ranks first in 19 where random order expects 15.2 (P = 0.034), top-3 is not significant (P = 0.37), and the ranking weights are set by hand.

What all of it proves is one claim, tested repeatedly: a serverless platform is a general-purpose computer that nobody has finished writing the runtimes for.