How I Learned To Stop Worrying and Love The LLM
16 Feb 2026
Denial
In my current workplace, I was once known for being the "anti-LLM guy".
I strongly believed that code that was produced by an LLM was worse than what the developers around me were capable of producing. They would hallucinate and make mistakes and would produce code that was more difficult to understand and maintain than code that had been deliberately written with these things in mind.
Even worse, the developers that were using LLMs were starting to value speed over quality and were losing their ability and their desire to learn and understand the code they were working with. Worst of all was when I started to hear the dreaded "I don't know, the LLM wrote it" when asking questions during code reviews.
These initial impressions contributed to my decision at the time to not use LLMs for software development.
I took pride in my ability to develop and maintain a deep understanding of the projects that I was working on. I worried that would be lost if I used an LLM to do the work on my behalf.
It was important to me to write good quality code and to make decisions that would allow my projects to be successful and provide a strong foundation for myself and other developers to have a positive experience working on those projects for years to come. I worried that allowing an LLM to write that code and make those decisions would take that away.
I enjoyed reading documentation and exploring the capabilities of packages I used and services I integrated with. I worried that an LLM would remove the need for learning and the growth that came with it.
Indifference
For a while, everything continued as normal. I kept working and kept delivering projects while other developers in my workplace were starting to build their workflows around LLM tab completions, conversational flows with ChatGPT then agent driven workflows with Cursor and Claude Code.
My impressions of building software with LLMs were starting to change. I was still writing code myself but the models were getting significantly better and it was no longer realistic to argue that a typical developer would always produce better code than an LLM. LLM assisted software development was no longer the worse option but it was simply not the way I wanted to work.
When working with other developers who were using LLMs, I focused on the software development practices around the code rather than how it was written. As long as a developer could demonstrate that they understood the changes that had been made and that those changes addressed all of the relevant requirements, then the fact that they may not have written it themselves was no longer important.
Acceptance
Most of the public discussion around LLMs still leaned towards vibe coding and which tool was going to finally automate software developers out of software development.
So what changed?
One of the developers at my workplace gave a Friday afternoon presentation about a feature they had added to one of our projects using Cursor. But this was different to the usual "build feature pls don't make mistakes" LLM workflows that I had been exposed to so far.
They manually defined their Typescript types to give the LLM more context and allow its output to better align to their requirements.
They understood which changes were low risk and well suited for an LLM and which were higher risk and needed to be handled with more care.
They developed, reviewed and iterated on plans that were generated by the LLM the same way they would have done if they were working with a developer.
They reviewed the generated code and made changes themselves where things didn't feel right.
They demonstrated a realistic way that an LLM could be used alongside an existing workflow that emphasises and builds on everything we know about building software instead of trying to replace it.
It sounds so simple in hindsight that it is almost embarrassing that it took this long to figure it out.
The future?
After that presentation, I finally installed Cursor and planned to use it to complete a few features for a current project.
I've been using it for the last few weeks and have been getting a feel for how it fits in my workflow and how I can still hang on to the things that are important to me as a software developer.
I'll probably write something more specific about my workflow another time, but for now the plan is to keep experimenting and see where the technology and tools go from here.
Just try not to worry too much about what my job might look like 6 months from now...