I’ve been writing more lately, as I work through my feelings about changes to the software development industry. After Cory Doctorow was eviscerated about his use of a local for spellcheck I shut my mouth about them. And I’m tired of that. This post is for my #neverAI peers, when they eventually catch up on my RSS feed and realize that I’ve been using LLMs this whole time. It’s an explanation of why I’ve leaned into agentic coding tools and why I think they should, too. I’m not likely to convince anyone, but I’m tired of shying away from it.
I can’t control how others use agentic coding tools. There are cybersecurity breaches that wouldn’t be possible without LLM-powered agents, and there are similar issues with cloning copyrighted software. Both of those crimes are way easier to do with agentic coding tools. But I don’t control the tools, and my use of the tools doesn’t impact how they’re misused by others. Similarly for the other impacts that AI has on our industry and world, I don’t know what to do about junior developer career paths, or RAM shortages, or data centres. But neither do I know what to do about run-off from rare earth metal refinement despite my career building software for smartphones. The argument that using a tool is an endorsement for everything bad about that tool is not convincing to me.
Agentic coding is probably the thing that LLMs are best at. Text-based inference is among the cheapest uses of LLMs. And generating source code has been the biggest bottleneck to developing software my entire career. Probably much longer. We’ve built ever higher-level programming languages to speed this up. We’ve built WYSIWYG flowcharts so marketing teams can avoid needing programmers at all. We’ve built vast open source libraries to avoid having to write the same code more than once. Agentic coding is another means to speed up software development by automating the creation and validation of source code.
The cat is out of the bag. I used to cope by telling myself when the bubble popped, token costs would soar and companies would return to coding by hand. But token costs have only decreased, and inference alone is profitable once a model is trained. Local inference on open weight models has also become very capable; it turns out even a slow LLM can write code a lot faster than I can. Agentic coding is going to survive the inevitable AI bubble collapse.
So given that the tools exist, and that employers are looking for those skills, I decided to learn them. To not merely reluctantly use them, but to embrace them. To be curious about what they could do, and find novel uses for them.
Like many developers, I’m familiar with the limitations of LLMs. They are not deterministic, and you can’t trust their output. Claude will give you confidently wrong output. Or accidentally malicious output. I’ve seen some developers use the fact that the tools aren’t reliable in the same way a compiler is as an excuse to not use them. It demonstrates a kind of incuriosity that irks me. As if coding agents were the only flakey tool programmers use. I’ve seen enough flakey-yet-useful end-to-end test suites to know that developers can solve problems even when the tools aren’t 100% reliable.
Agents write slop? Sure, but I’ve written a lot of slop too. Agents write slop fast, which is the actual problem. Okay, so how do you get them to write not-slop? The nice thing about an agent is that it will conform to whatever linters and architecture checks I force it to (instead of opening endless RFC’s complaining about how much extra typing I’m making them do). It’s possible to get agents to write less-sloppy code, just like it’s possible to write less-flakey e2e tests.
As I was pursuing my promotion to Staff Engineer at Artsy, I was coding across many different systems and languages. I had to become comfortable writing code that I didn’t have as deep knowledge of as Swift and Objective-C. Every language has its quirks, and I learned to become proficient enough with a tool. When I returned to focus exclusively on mobile, I was leading a team. I didn’t spend much time coding, and the time I did get to spend in code was used to help others be productive. I started to resent compilers and tool chains and IDE’s. All I wanted to do was build a nice feature or fix an interesting bug, but instead I had to waste time fixing whatever broke our Babel setup when the web team updated the GraphQL schema, or whatever. I had things I wanted to build but I never got to actually build them.
So now I have LLMs. When I hit a type error, I don’t have to stare at it until my head hurts. When a new iOS SDK starts crashing my app on launch, I don’t have to figure out how to attach a debugger to a TestFlight build. When there’s a quick change I need in a backend system, I don’t need to figure out the quirks of whatever framework they’re using. Agentic coding tools make me proficient enough.
Developers aren’t paid to code. We never have been. We’re paid to solve problems. Historically, the longterm employment prospects of software developers who decide not to use new tools have not been favourable. Technology is a fast-moving industry, and quite famously so. You’re allowed to feel however you want about that, but I’d encourage you to be curious about what these tools can do. To keep an open mind about what software development might look like in the future.