You’ve probably been there. You start a side project on a weekend. You build the core logic by hand, line by line, feeling every bit of the satisfaction that comes from making something work. And then… it sits there. On your local machine. Unshared. Unfinished. Because the last mile — deployment, build configuration, browser compatibility — is where passion goes to die.
The hardest part of software isn’t writing the code. It’s shipping the code.
Recently, a developer shared a remake of Battle City — the classic 1985 NES tank game — written in Go and playable in the browser. They built most of it by hand to learn gamedev. But when it came to wiring up a WASM build for browser deployment, they turned to an LLM. And then they caught themselves playing their own game for way too long.
That’s the story. But underneath it is something far more interesting than another retro game remake.
Most developers right now are obsessing over using LLMs to generate core logic — to write the algorithms, design the systems, architect the solutions. They want AI to do the creative part. The hard part. The part that makes them feel like real engineers.
But this project reveals a different truth. The LLM wasn’t used to write the game. It was used to solve the boring, fiddly, soul-crushing integration problem of getting Go code compiled to WASM and running in a browser. The unglamorous last mile.
The real value of LLMs in software development isn’t in replacing your creativity. It’s in eliminating the friction that kills your creativity.
Think about how many projects you’ve abandoned not because the core idea was flawed, but because configuring the build pipeline, wrestling with dependencies, or debugging deployment issues drained your momentum. The 8-bit game logic is simple. It’s deterministic. It’s fun to write. But making it browser-playable? That’s where modern toolchains rear their ugly head — Go, WASM, browser APIs, asset loading. Each one a potential rabbit hole.
By offloading that friction to an LLM, the developer did something remarkable: they actually finished. They shipped. They shared. And then they played their own creation — which, if you’ve ever built a game, you know is the ultimate validation that you made something real.
We keep framing LLMs as replacements for human creativity. But maybe the better frame is this: LLMs are the ultimate unblocker. They handle the integration work that no one wants to do but everyone needs done. They bridge the gap between ‘it works on my machine’ and ‘anyone can play it in their browser.’
The developers who win in the AI era won’t be the ones who let AI write everything. They’ll be the ones who let AI handle everything that stands between them and shipping.
So the next time you start a side project, don’t ask the LLM to write your core logic. Ask it to kill your excuses. Ask it to solve the last mile. Ask it to make the unshippable shippable.
Because a game that exists only on your laptop isn’t a game. It’s a regret.
FAQ
Q: Isn't using an LLM for build configuration just laziness?
A: No — it's triage. Build config and deployment integration are high-friction, low-creativity tasks. If an LLM can handle them, you save your mental energy for the work that actually matters: the core logic, the design, the experience.
Q: What does this mean for developers practically?
A: Stop treating LLMs as code generators for your core problem. Start treating them as deployment accelerators. The bottleneck in software isn't writing code anymore — it's finishing and shipping. LLMs close that gap.
Q: Won't LLMs eventually just write everything, including the core logic?
A: Maybe. But right now, the highest-leverage use of LLMs isn't creative coding — it's integration work. The developer who hand-wrote a game and then used an LLM to ship it understood something most people miss: creativity is human. Friction elimination is where AI shines.