For the entire history of engineering, we designed organizations around code being expensive. Code is becoming cheap, and the org chart hasn’t caught up yet.

Most of the conversation is still about productivity: faster coding, more output, fewer bottlenecks.

The far more interesting question is how much more of the product one engineer can responsibly own, and what this means for teams, architecture, and management.

I explored what that might look like here: medium.com/@jengas/ai-is-…

I wanted to see just how far I could push what I could build in under two hours on a Saturday.

So, naturally, I made a 3rd-person sci-fi shooter.

I started with a shooter physics prototype I'd already built, and turned it into EDEN//ZERO. Biomechanical enemies, assault rifles, ma swords, motion-captured animation, and a ridiculous amount of visual polish for a Saturday morning.

All running in a browser.

It's still a prototype. There are plenty of rough edges, and making something playable is a very different problem from making a great game.

But here's what I find fascinating.

I've spent most of my career building products alongside incredibly talented engineers, artists, designers, and other specialists. I know how much work and coordination goes into bringing something like this together.

Now a single engineer can get surprisingly far in just a few hours.

And this isn't just about games.

We're watching the economics of software engineering and creative production change in real time. I'm still wrapping my head around just how far this goes.

Anyway, here's what happened when I spent a couple of hours having fun on Saturday morning.

It's also available on @spawn - spawn.co/@g3d/eden-zero

You can play it on @BitmagicAI - bitmagic.ai/play/eden-zero/

Have you ever gotten your hands on a chainsaw?

If you have, you realize two things almost immediately: they are ridiculously powerful, and they are absurdly dangerous.

A chainsaw can turn an afternoon of miserable manual labor into twenty minutes of work.

It can also take off a hand because somebody picked one up without knowing what the hell they were doing.

Nobody looks at the second outcome and concludes that chainsaws don’t work.

They conclude that perhaps handing an extremely powerful tool to someone with no training, no plan, and no idea what success looks like was a bad idea.

Which brings me to AI.

I keep reading stories about companies adopting AI, getting bad results, and concluding that AI creates more work.

Then you read what actually happened.

No training. No clear problem. No baseline. No quality bar. No owner. No way to measure whether the thing worked.

They gave people access to an extremely powerful new tool and hoped productivity would happen.

Then they were surprised by the mess.

AI has a learning curve.

AI adoption requires engineering discipline.

You need to know what you're trying to improve, what good looks like, and how you'll measure it.

Otherwise you're not evaluating the technology.

You're handing out chainsaws and blaming the tool when somebody gets hurt.

I spend a ridiculous amount of time working with CLIs these days. Claude Code, Codex, Grok Build, and a growing collection of AI engineering tools.

And I got to thinking: if this is where some of the most sophisticated engineering in the world is happening, why are we still e it's 1985?

So I built a voice shell.

I wanted something I could use from my phone while sitting on the couch, with full, direct access to my actual development environment. Not another chat interface for a coding agent, but the real thing. My code, my projects, my shell, and whatever agents I happen to have working.

And I wanted to be able to talk to it.

Remember all those wonderfully obscure Linux commands, with their sophisticated combinations of flags, pipes, and arguments? Now imagine typing them on a phone keyboard.

No thanks.

I integrated Gemini Live, so now I can just ask what's happening, inspect files, check Git status, direct my coding agents, and approve commands using my voice. I can switch between speaking, typing, and touch controls whenever I want.

And because I apparently can't leave well enough alone, I built a custom WebGPU rendering engine for the whole thing.

Characters materialize from thousands of particles. Deleted text dissolves into glowing embers. Terminal output glides and rearranges itself as the screen changes. There's GPU compute, particle simulation, HDR, bloom, and a 3D particle orb that reacts to our voices.

All of this is running on top of a real terminal, with proper ANSI support, interactive applications, persistent sessions, and reconnect synchronization.

But here's where it gets interesting: I own the entire interface.

If I want to integrate another agent, add a tool, or completely change how I interact with my engineering environment, I can just build it. At this point, adding a new capability is often literally a prompt away.

That opens up some pretty fascinating possibilities.

We're already using AI to build extraordinarily sophisticated software. Why shouldn't we do this with the tools we use to build it?

And if the result happens to be powerful, gorgeous, and lets me get some engineering done while sitting on the couch?

Even better.

At Fireworks Forge in SF today, watching Jensen Huang and Lin Qiao dig into the future of specialized intelligence. Jensen's ability to connect the technology, the economics, and where this is all heading is simply extraordinary. The guy really is in a league of his own.

H3 Max vs Pika Flex vs Pike Flex (INT8)

spent ~10 upgrading my browser-based shooter. @tripoai generated the character & weapons, NVIDIA MotionBricks handles the animation, and the whole thing runs locally in the browser at 60 FPS

at the Google #WebAI summit today

@X @grok is x glitching?

A couple of days ago, I was wondering whether NVIDIA's MotionBricks could run directly in a web browser.

Well, that worked.

I now have a 3rd-person shooter with a 200-million-parameter AI model generating the character's animations in real time. Entirely in the browser.

No I calls. No per-player inference bill.

The 380 MB model runs locally using WebGPU, generating the next 1–2 seconds of character motion in about 45 milliseconds on my Macbook.

Walking, sprinting, strafing, crouching, turning, aiming a rifle. All driven by generative motion, integrated with an actual physics engine.

And because I wanted to see what the model was doing, I added a holographic visualization that shows the character's predicted movements, poses, and footsteps before they happen.

But here's the part that really blows my mind.

I gave Opus 5.5 in Claude Code an existing 3D prototype and asked it to build this experiment.

It ported NVIDIA's Python inference runtime to TypeScript, retargeted the 77-joint animation skeleton onto a SWAT operator, integrated physics and collision handling, built a shooting range with destructible objects, and wrote tests validating the generated motion against the original model.

The whole thing took about 46 minutes.

And it's running at 60 FPS.

There's still plenty to improve, and I haven't finished testing normal browser controls or other devices. This is an experiment, not a finished game.

But think about where this is going.

We've spent decades building game animation systems around pre-authored movements, transitions, and increasingly elaborate state machines.

Now we're getting to the point where games can generate the motion they need, as they need it, directly on the player's hardware.

And AI agents are making it possible to experiment with ideas like this in less time than it used to take to set up the project.

Game development is getting pretty wild.

AI is changing engineering faster than engineering organizations are changing themselves. And some of the ones investing most heavily in it are about to get blindsided.

I've been building software and leading engineering teams for quite a while. And some of the things I'm seeing happen right now would have sounded ridiculous to me even a year ago.

I'm watching engineers build and ship things that would previously have taken months to deliver. AI agents aren't just helping write code anymore. They're implementing entire systems, running tests, finding and fixing bugs, and working autonomously for hours at a time.

And I'm seeing this happen in real production engineering, building products that real people actually use.

But here's where things get interesting.

I'm also seeing organizations investing enormous amounts of money in AI while continuing to operate under assumptions about engineering that are rapidly becoming obsolete.

We've spent decades building engineering organizations around specialized roles, dividing responsibilities across teams, and managing all the coordination required to get things shipped.

But AI is changing the scope of what engineers can take responsibility for. People can own much larger parts of a problem, work across disciplines, and carry ideas all the way from concept to production.

That has enormous implications for how we organize teams, distribute responsibility, and decide what to build.

Yet many organizations are still planning projects, building teams, allocating budgets, and estimating delivery timelines based on an increasingly outdated understanding of what it takes to build software.

And often, they don't seem to realize just how much has changed.

Of course, making software cheaper to produce doesn't magically solve all the hard problems in engineering. Quality, reliability, scale, and good judgment still matter enormously.

But when the underlying economics of building software change this drastically, and the scope of engineering responsibility changes along with them, pretty much everything built around those assumptions deserves to be reconsidered.

You can't just bolt AI onto the engineering organization you built five years ago and expect to remain competitive.

And I suspect the real wake-up call isn't going to come from another frontier model release.

It's going to come from competitors who have already figured this out.

Apparently, launching a new frontier AI model, corporate website, and flagship product wasn't enough.

We had to ship a video game too.

Meet Reboot, our new game where you get to play a Hollywood executive and decide what entertainment gets greenlit.

Think you have better unning Hollywood?

Here's your chance to prove it.

ubiquity-game.chronicle.studio

Huge props to the @Chronicle_tech team for putting this together. I love working with people who find an excuse to turn just about anything into a game.

It's never been easier to do something impressive with AI. Getting it to actually work inside a real company? That's another story.

I was chatting with a few other executives during a16z Tech Week in SF, and almost every conversation eventually came around to AI. Not just the technology itself, but how we transform our organizations, our products, and the way we operate.

And one thing has become really, really obvious: this is ridiculously hard.

Working with AI can feel like magic. Type in an idea and out comes an essay, an image, a video, or hell, even a video game you can play.

But that experience tends to overshadow just how steep the learning curve actually is. Especially when you're trying to build real products, for real customers, inside real businesses.

I keep seeing companies wrestling with the same problems I was struggling with a couple of years ago.

It's incredibly tempting to start with the technology. Build something impressive, show everyone what it can do, and then figure out how to get people to use it.

I've learned the hard way that taking the opposite approach works a whole lot better.

Start with the people doing the work. Find a real bottleneck, understand the economics, and put someone who deeply understands AI alongside the people who actually understand the problem.

Those people know what good looks like. They understand the nuances of the work, which mistakes actually matter, and what separates a genuinely useful result from something that just looks impressive.

That's how you build meaningful evaluations. Turn their expertise into a way to measure quality, then get something into production and test it against reality.

For example, an AI model predicting what an audience will respond to is interesting. Actually publishing content, measuring the response, and finding out whether the model was right? That's where things get useful.

Cost, reliability, quality, actual business outcomes. Measure the hell out of it, learn from the results, and keep improving.

Otherwise, how do you even know whether your AI is doing a good job?

Then, and this is the really important part, make yourself unnecessary.

Give the team ownership. Help them develop the skills, tools, and judgment to keep improving what you've built together. Take what's reusable, apply it to the next problem, and repeat.

The goal here isn't to build AI capabilities. It's to build an organization that knows how to use them.

This little experiment is starting to get a bit out of hand.

Last week I showed three AI models running entirely inside a web browser, letting me command an RTS game with my voice.

No cloud inference, no API calls.

Over the weekend, I turned my local GPU cluster loose on the A gauntlet of coding agents worked through the remaining systems and features, building out what was still missing.

Now it's starting to look like a real game.

Sure, I'm using AI to build the game, and AI is running inside the game. But this isn't just about development speed. The economics of building and operating games have changed, wildly.

Of course, none of that matters if the game isn't fun.

Challenge accepted.

2013 was the last time I hand-optimized assembly

now I know I'll never have to do it again

life is good

I have three generative AI models running inside a web browser. On my phone. Not a web page calling AI APIs.

The actual models are running on the page inside the browser.

I replaced Gemini Live in my RTS game prototype with an entirely on-device AI Commander.

One model listens fine-tuned 350M parameter model understands my orders. A third speaks back. The game's own systems handle the strategy and execution.

I can tell it to build defenses, move units, ask about the battlefield, or change my mind mid-conversation. All without a single inference request going to a server.

It works on my Mac. It works on my Pixel 11. The decisions take roughly half a second, with no measurable impact on the game's frame rate.

But here's where this gets really interesting: in a game built around generative AI, where using the AI is native to the experience, I just eliminated the cost of running that AI for every player.

Normally, the more people play, the more they interact with the AI, the more the inference costs.

Not anymore.

The models ship with the game. Every player brings their own compute. They can interact with the AI as much as they want, and the inference cost stays at zero.

No AI subscriptions. No API keys. No usage limits. No inference bill for me or the player.

And because it's all running in a browser, I can deliver that experience across desktops and phones, anywhere really that has enough compute to run the game, all without building separate native applications.

This fundamentally changes the unit economics of publishing an AI-native game. But I think the implications go a lot further than games.

What happens when generative AI stops being a service you rent, and becomes software you can simply ship?

For the technical folks curious how this works:

Three open-weight models, all running inside the browser:
- Moonshine Small Streaming (166 MB): Speech recognition with voice activity detection, running on WebAssembly.
- LFM2.5-350M (229 MB): Fine-tuned to translate natural language into game commands. Runs through wllama/llama.cpp on the CPU, with grammar-constrained decoding.
- Kokoro-82M (~109 MB): Generates the Commander's spoken responses.

The language model was trained on ~45K examples, augmented with synthetic speech and actual transcription errors. It scored 100% on 160 held-out text commands and 98.8% on speech-to-command tests.

The model doesn't make gameplay decisions. It interprets intent and calls into the game's existing deterministic planning and execution systems, which enforce validation, budgets, and permissions.

my home GPU cluster is burning at max capacity this weekend

My latest video experiment reminded me that there's a lot more to making a good AI video than generating good footage.

I spent some time working with Google Veo this weekend. I was able to dial in the look, but the fight choreography? Terrible.

Rather than burning through a ping to get lucky, I tried to get clever with editing instead.

Turned the same 3 shots into 8 cuts. Better pacing, better timing, remastered sound.

And it worked.

Is it perfect? Not even close. But look at the before & after.

Sometimes making something better isn't about throwing more compute at it. It's about getting more out of what you've already got.

All footage generated with Veo. Editing and production handled by my custom agent and toolchain, powered by Opus 5.5 in Claude Code.