This article is inspired by this wonderful conversation between Demetri Spanos & Casey Muratori.
I was on a business trip a few years ago stuck in an Airbnb and happened to watch Rye Lane. It’s a rom-com film about two young adults set in South London and I absolutely loved it.
When I got home I started raving about it to my wife and eldest son. I just couldn’t wait for them to watch it. I remember sitting down and feeling very excited as the film started. We made it halfway through and they hated it.
I was shocked. How had I had such a different experience to them? How had they hated something I thought was amazing?
I think something very similar is happening on a mass scale at the moment with AI in software development.
I’ve never seen a technology like generative AI cause such a wide range of opinions. I want to dive into it to see what’s going on and why this might be happening.
The Current State Of Play
Some developers are orchestrating agents across multiple projects. They are using the “— dangerously-skip-permissions” flag and running parent agents with sub agents. They paint a world of endless possibilities and make the whole software building malarky seem trivial.
Other developers are much more conservative stating their experience with AI isn’t great and they wouldn’t trust multiple agents at once. Citing the output as “slop” and the whole process will just create more work in the end.
Other groups of developers are stating that coding was never the bottleneck anyway and that LLMs are now shining the light on the real bottlenecks such as code reviews, code quality and tech debt.
Why are we as a collective having such a range of experiences with the same tool?
The Type of Task
AI is a tool and task you choose to apply it to seems to be important. It’s fantastic at some tasks and horrible at others.
If you ask an AI to generate some boilerplate code or scaffold out a project it will do this really well most of the time. You may need to advise the tech stack or main libraries you wish to use but the outcome will likely be what you want.
It will save you time.
If however, you ask AI to do a large scale refactor on a legacy codebase which hasn’t been very well maintained then it will likely really struggle. AI does well where the context window is relatively narrow. The wider the scope of the request the more chance there is that AI will go off in unintended directions.
The Model You Use
The Model you use can also make a big difference. Anthropic’s Opus 4.5 model was a turning point when it was released. It was widely reported that developing with this model had noticeable improvements on previous models.
We had a session at work recently where a developer showed us how he had been working with a local model using LM Studio.
He asked the model to explain some python code and it took about 2 minutes “thinking” time before it started responding. Comparing that to the likes of Opus 4.X or GPT-5.X which can review whole code bases in about 30 seconds.
The model you use really can effect your experience.
Greenfield Projects vs Legacy Codebases
Much like the tasks, the type of project you are working on can heavily influence your experience with AI.
AI can generate huge amounts of code very fast. This is just what greenfield projects need. Get up and running fast and either get something out the door or get to the point where they can test out a proof of concept.
With legacy codebases that have been running in production for 20 years it’s a very different use case. In these code bases you have to move slower, not break any existing functionality, be more thorough with testing and follow coding styles and patterns unique to that codebase.
The Type Of Developer
Some developers are very critical of code. They choose quality over productivity. They want separation of concerns, follow best practices such as SOLID or KISS. They want to reduce tech debt and double down on testing every edge case.
There is no right way but from my experience AI is like a Duracell bunny just raring to get started on implementation. Even in plan mode it always ends every prompt with “Ready to implement?!” It just seems so keen to get going with the coding.
Also it will rarely test edge cases or look for ways it could improve its implementation unless specifically asked to do so. AI can definitely find edge cases, it just doesn’t seem to be its “Modus Operandi”.
Some developers love this approach from AI and some hate it.
Conclusion
There are a plethora of factors that seem to influence a developer’s experience working with AI. The model you use, the task you asign it, the type of project and the type of developer you naturally are all play a part.
AI has strengths and weaknesses, like anything else in this world, and playing to those strengths obviously leads to a better experience. I think as a collective we are slowly learning what those strengths and weaknesses are.
What’s really hard to distinguish is the truth around the productivity gains. Whilst one developer might “feel” they are 10x more productive, in reality they may only be 30% more productive. What does productive really mean in this case? Producing 10x more code doesn’t equate to being 10x more productive necessarily from a business perspective.
For the time being, learning when and where to use AI, in which projects and in which situations is likely to lead to the best results.
