Generative AI has not gone down well in the games industry. Hallucinated textures, AI voice acting, music generated by a model - players and developers have pushed back hard against all of it, and I couldn't agree more. The tools were sold as a way of accelerating production. But there is always a catch, and this one is paid for in creativity and, more to the point, in people's jobs.
However, in the eyes of many, LLM-generated code seems to have been given a pass. The backlash that met generated audio and art never really arrived for code. Originally I thought this was odd, since the technology being used is largely the same. My belief is that it comes down to the perceived creative impact. A player never directly sees the code, they only feel the impact of it if something is wrong.
The problem with that argument is that agent-generated code only announces itself through software that is slow, broken or unpleasant to use. The issue here is that the quality of software in 2026 is at an all-time low; we're living in a time when agent-generated code has the best disguise it could hope for. I genuinely don't believe I'd be able to tell the difference from the shipped product alone!
I kept both agent-generated code and generative AI in the same bucket for a long time. Then I started using them, and it took me a good while to work out where I had been a little strict in my categorisation.
Trained on the bell curve
An agent is trained on the code that exists, and most of the code that exists is mediocre. That is not an insult aimed at anyone in particular, it is simply what the middle of the distribution looks like. The consequence is that agents trend toward the middle by construction. The code you end up with is alright. It's fine - unremarkable.
In Rust, I've constantly seen agents struggle to put together a decent allocation strategy. Agents tend to frequently reach for Vec and String, resulting in a large number of allocations with widely varying lifetimes. No temporary allocator, no arenas, no pre-allocated chunks or buckets. Sadly, this is exactly what you would expect, because there is a great deal of Rust on GitHub that does precisely this.
Something you have to learn very early on is that context is king. Agentic coding is all about context - revealing the right information at the right time for the task at hand. Get that right and the output lands remarkably close to what you were after. Get it wrong and you are better off scrapping the code and starting again with a fresh context and a fresh set of prompts. You will still need to constantly review the output and push additional steering prompts, but this is a skill that you can get better at. Once an agent has the relevant context for a project or task, prompting becomes easier and the agent becomes much more productive.
There is also the matter of the monetary cost. At the time of writing the entry-level plan does not feel like enough, and neither does the top plan - I have spent months on the latter still rationing my usage and trimming context to stay inside the limits, and the agents are slow at peak times regardless. The core problem here is the inability to have a decent number of agents running at the same time without hitting usage limits quickly.
So that is the bad news, and none of it has gone away. What I did not expect is that none of this stopped agents being useful. While they can give you large productivity improvements for certain tasks, the more interesting element I've found is that they are excellent at removing friction. Sometimes all it takes to get a project off the ground is to overcome the initial friction hurdle - and mediocre code is always to be expected when exploring potential avenues at the start of a project.
My guess is that the significance of skill atrophy will end up inversely proportional to each individual's passion for the craft.
The tools that would never have existed
I was running multiple agents in Windows Terminal, a separate window with two tabs for every worktree, and once there were a few of them going at once it became impossible to keep track of what was actually happening. I could not tell at a glance which agent was working, which was blocked waiting on me, and which had quietly finished several minutes ago. I ended up building my own multi-terminal agent manager.
It has become the centre of many of my workflows. It is a terminal that treats agents as a first-class part of the environment - no more constantly clicking on various terminal windows. A sidebar tracks the state of every agent in the session, along with the tools they lean on - cargo, rustc, dotnet, cl, git - so I can see what is running at any given moment. It is always interesting to see quite how many cl processes get invoked when compiling a multi-million-line codebase!
Oxide is not interesting because it is any good. It is interesting because it exists at all, and I think that is where this is really heading.
Everyone is going to end up with their own tools. My colleagues all have their own agentic setups, tuned to how they work. Many managers are building themselves tooling for meetings, planning and scheduling, and for sharing context with other managers - asking agents to put together interactive websites to get ideas across.
All of these tools are built for a market of one. They are tuned to a single person's workflow and contain only the precise set of features required. In a world without agents, it is very likely that most - if not all - of them simply wouldn't exist.
This is where mediocre code isn't really relevant. These are not production applications and were never trying to be - they only have to work for the one use case they were built for. Mediocre code that runs and solves a problem only you have is worth considerably more than the excellent tool that nobody ever wrote. It doesn't matter whether you understand every line of a personal tool, as long as it makes a real difference to how you work.
What actually changes
The wider question is what an agent does to the work day to day. The productivity claims being thrown around are, in my experience, nonsense - so let me be honest about what I have actually seen.
Comparing end-to-end completion times, agents improve some tasks a great deal, some a little, and some not at all - a few even come out slower. Estimation in software engineering is notoriously unreliable at the best of times, and it is worse here, because you can't compare agentic and non-agentic work on the same task without corrupting the comparison. What I have is experience rather than instrumentation. I do feel faster when using agents, but nowhere near what I have seen claimed, and nowhere near what a lot of people seem to be hoping for.
One of the best cases for agents is running work in parallel through feedback loops. Explain what you want, then get out of the way - while the agent works you can continue with something else. The rest of the benefit comes from what I mentioned earlier: the removal of friction. Picking up an unfamiliar API or library used to carry a fixed cost before any real work could start, and that cost is now much lower. The same is true of tired evenings: there is a shortcut to getting started where previously the required effort would have meant not starting. Something gets built that otherwise would not have been.
The tasks that come out slower are just as predictable, once you have been caught by a few of them: anything with a large web of tendrils running through the codebase, where the relationships between systems are subtle and must all be held in mind. Replacing something wide-reaching is the clearest example I have - a logging framework. Building the replacement in isolation is not the hard part and agents can greatly assist. It is the integration step that falls apart, because the agent cannot hold the shape of the whole thing at once, and I end up spending longer steering it away from confident and plausible mistakes than I would have spent doing the work myself.
What worries me
My single largest concern is skill atrophy, the slow and steady hollowing of a skill I've been honing my entire career.
It is very easy to get lazy. Handing a problem to an agent requires significantly less effort - it is a prompt away. The other option is to push through the friction, and once you've built up a prompting habit it can be genuinely difficult to reverse - especially when the pressure to give in is coming from every direction at once. There is a very strong push in web development circles at the moment, with sentiments along the lines of "you'd be stupid to continue to manually code". The trouble is that if you stop writing code, you stop maintaining the skill - and that can only result in gradual decay.
So I guard against atrophy deliberately. I still write code by hand every day and I still review it by hand, and I keep chasing knowledge that I could quite easily have asked an agent to hand me pre-digested. My guess is that the significance of skill atrophy will end up inversely proportional to each individual's passion for the craft.
The other core worry is the impact on newcomers to the industry. A junior entering the games industry today is walking into constant layoffs and general industry instability, and now into a reshaping of the expected day-to-day work of an engineer. How does agentic coding affect somebody who has never had the chance to build the skills required for the job? What does it do to their learning, and to their progression? I genuinely do not know what to suggest right now - but I am concerned, and you should be too.
Just another tool
So where does all of that leave me? Tentatively, and with a list of caveats, but overall in favour of agents.
They are here to stay in one form or another, and most of the industry is already building their workflows around them. That was going to be true regardless of my opinions. At some point I stopped thinking about them in the same way as generative AI and started thinking about them like any other tool, and that is when I started asking: What are they good at? What are they bad at? How do I get the most out of them?
That is a comfortable position to land on. Agents are useful in places, useless in others, expensive, and in constant need of supervision. But they earn their place the same way static analysis or a linter does, and no more than that.
Just another tool. Which is not a small thing to say about something I was ready to write off completely.