Theo on Why Smarter Models Help More Than Developers

Two years ago I confidently predicted that AI intelligence would plateau and improvements would become marginal. I was wrong. We have moved from occasional autocomplete to asking questions about a codebase, directing edits, and giving an agent a screenshot of a bug to investigate, test and potentially merge.

Then I made a different mistake: I thought we might not need models to get smarter. When Fable 5 arrived, I could barely imagine using all its capability. Opus 5.5 changed my mind—not just because it was faster or better at familiar work, but because greater capability can help people I had not expected.

The surprising illustration was a mashup of Halo and Call of Duty. Seeing people reverse engineer and combine old games helped me realize that smarter models could have effects beyond professional software developers. Those who benefit include technical enthusiasts who do not write code for a living, and eventually the people around them.

The first and most familiar effect is that developers can build better software faster. In my experience, agents let a developer move through a roadmap more quickly and take on work that previously would not have been worth the effort. Experience still matters for getting the most out of these tools.

I built Lawn because I was frustrated with the speed and cost of a video-review service. I say I put together an open-source alternative in a few days, and my team now uses it for video work. I estimate that it reproduces much of the earlier product's functionality while adding features we wanted; that is my assessment, not an independent comparison.

Lawn illustrates how a product that once seemed too expensive to attempt can become viable for a small team. I say a few hundred people use it in their video workflows, and some have forked it. That leads to the next group: technically capable people who know computers well but are not professional programmers.

A technical enthusiast may understand the problem an application should solve without knowing the limits of every framework or tool. They might deploy an application and database in distant regions and wonder why the app is slow. A smarter model can help investigate the system and fill some of those knowledge gaps.

These users can fork tools, write scripts and debug systems beyond their current understanding. A person who can swap a computer component can increasingly ask an agent to help alter software too. Earlier models could help make a small personal app; now users can try changing tools they already depend on.

There is still a difference between a customization that works on one machine and something other people can safely install. Packaging and distributing a change is hard. My framework starts with assistance in an area you already know, then moves to modifying familiar tools, building things you do not fully understand, and finally rebuilding complex existing systems.

For example, I have projects in Rust even though I barely write the language myself. The deepest tier is using these tools to help understand, decompile or rebuild existing software. I find it remarkable that an agent can gain enough context to work in a complex decompiled game, even though nobody necessarily understands the whole codebase.

As models improve, different groups move through those tiers at different times. Early coding autocomplete helped developers but did little to let non-programmers build. Later tools could edit files, allowing technical users to customize their own sites while developers made broader changes across codebases.

With Opus 4.5, I saw technical people build more complete applications, while developers explored games, ports and decompilation. Later models gave developers another substantial jump. I initially worried that the gap between developers and technical non-developers would simply keep growing.

Opus 5.5 changed that view. It did not give me an entirely new category of work I could never assemble with other tools, but having a capable model available in one place and through subscriptions made ambitious work more accessible to technical enthusiasts. I saw people who had never coded or used Blender attempt game-map ports and mashups.

I do not think non-technical users have moved through these tiers as much yet. But a technically inclined friend can now make or adapt useful software for someone else, or share a game modification with people who do not understand its implementation. Benefits can travel beyond the person using the model directly.

My provocative view is that developers are not always as creative as we think. Product managers and designers contribute skills beyond writing code. I am generalizing from experience, not claiming that every developer lacks creativity; the point is that technical training can also make familiar constraints feel inevitable.

People who understand computers but not the established implementation may approach problems differently. I have seen elaborate OBS setups, including one with tens of thousands of scenes used as dynamic layers. A person unfamiliar with the supposed boundaries between systems may attempt combinations an experienced developer would dismiss.

Consider the question, 'Why can't we commit environment files?' It sounds foolish if taken as a request to expose secrets. My intended question is broader: are the current ways we separate and share configuration the only possible design, or have we accepted them because our tools work that way? Asking why a convention exists is not the same as ignoring its security purpose.

Outsiders can ask questions that unsettle established assumptions. I compare this to people adapting music from another culture in unexpected ways. More capable tools may let people with little formal software background try ideas that experienced engineers never thought to ask for.

Some comments on my environment-file example immediately assumed the existing access model had to remain unchanged. My point was to examine that model itself. Creative developers can benefit too: a willingness to explore unfamiliar ideas and ask why a constraint exists matters more than simply rejecting conventions.

Many limitations were practical rather than theoretical. Porting a compiler or reverse engineering a device could take months or years and carry too much risk. If agents lower the cost of trying, more people can investigate ideas that were previously too expensive to test.

I have attempted ambitious projects throughout my career, including a stack, a game engine and networking ideas. Cheaper exploration does not guarantee success. It means being willing to try a bold approach, learn from failure and discard work that does not justify shipping.

Developers are used to a pull request eventually merging, and closing one can feel like wasting someone's effort. I have even merged work because I felt bad rejecting it. When an agent can produce a large change quickly, we need to separate the cost of an experiment from a decision to accept it.

I speculate that a developer and a technical hobbyist may feel differently about a rejected PR because they bring different expectations. That is not a rule about individuals. My practical lesson is to ask what the work is for, whether it actually helps, and whether it should be thrown away without treating failure as a personal defeat.

My TypeScript-in-Rust experiment is an example of an idea I initially thought AI could not complete. I report that it became functional in under 20 hours, works in WebAssembly, and performed well on projects I tested. I also cite speed and compatibility figures from my own project; those claims depend on the chosen tests and are not an independent benchmark.

A viewer suggested that people who operate at a higher level of abstraction will benefit most. I would amend that: the advantage goes to people who can move flexibly between high and low levels, and who will abandon a preferred implementation when another option better serves the goal.

For our mobile app, I personally prefer a SwiftUI rewrite, but the React Native version benefits from the speed at which agents can work, over-the-air updates and performance improvements by the team. I may choose the less personally attractive implementation because it gets us to the product goal faster.

I am also experimenting with T3OS, a customized Ubuntu image designed for agents rather than for my own desktop preferences. It is headless at startup and can create graphical environments for agents to use. I am working deeper in the operating system while making choices for a different user: the agent.

One example is choosing Bash over my preferred Zsh. In my own audit, I found that a significant share of Claude's errors on my machines involved shell formatting and malformed ripgrep commands. I also found that some Linux distributions were harder for the agents to manage. Those observations shaped my choice of environment.

That willingness to change the level of detail matters. I am not building T3OS for myself directly; I am building an environment in which agents can build things for me. Developers who treat current preferences and boundaries as fixed may miss opportunities that less constrained technical users pursue.

I used to believe models would produce work so complex that only professional developers could make use of it. I now think some of the knowledge that once helped us use earlier models can also make us too cautious. I do not know exactly what the next shift will mean for non-technical users.

A model capable of substantial compiler work may also help someone reimagine a favorite game. I did not expect friends without conventional programming backgrounds to do that. Their projects keep changing my view of who can benefit, and I expect the possibilities to keep expanding.

I was wrong, and I have been reflecting on it. My request is that developers reconsider where model capabilities are going and who can use them. Ask questions, test ambitious ideas, keep the ones that work and be willing to discard the rest.