Simon Willison (4 blogmarks)

The math has shifted, in some cases, significantly.

Coding agents dramatically drop the cost of typing code into the computer, which disrupts so many of our existing personal and organizational intuitions about which trade-offs make sense.

That prototype, that bug fix, that nice-to-have -- those things that tend to get pushed off over and over because more urgent things are taking your time -- are suddenly viable in a lot of cases with an LLM coding agent. Equipped with a paragraph of detail and using something like Cursor or Claude Code, we can hand off these back-burner tasks, iterate on the idea in minutes instead of hours, and have at the very least an MVP if not a ready-to-ship implementation. All with a relatively minimal interruption to the main task at hand.

While we're trying to catch up to what is possible here, all the different processes our organizations and engineering teams have surrounding how we go from feature idea to shipped and supported implementation of said feature have some catching up to do as well. In some cases, these processes are meant to slow things down, as a way of managing risk. These processes are in opposition to the mandate to using AI agents to ship faster. What are organizations going to do with this contradiction? That's an open question.

I also like that as part of this series Simon is putting forth the term Agentic Engineering as the other side of the spectrum from vibe coding when it comes to using LLMs to write code.

Simon Willison on whether LLMs are going to replace software developers and what these tools mean for our careers:

I do think that AI-assisted development will drop the cost of producing custom software - because smaller teams will be able to achieve more than they could before. My strong intuition is that this will result in massively more demand for custom software - companies that never would have considered going custom in the past will now be able to afford exactly the software they need, and will hire people to build that for them. Pretty much the Jevons paradox applied to software development.

Fun fact: there's no rule that says you can't create a new blog today and backfill (and backdate) it with your writing from other platforms or sources, even going back many years.

I should probably skim back through my past tweets and see if I have some popular posts or under-developed ideas that could be turned into backfilled blog posts.

This quote about Simon is spot on and it is why I recommend his blog whenever I talk to another developer who is worried about LLM/AI advancement.

A leading light in this area is Simon Willison, an uber-geek who has been thinking and experimenting with LLMs ever since their appearance, and has become an indispensable guide for informed analysis of the technology. He has been working with AI co-pilots for ever, and his website is a mine of insights on what he has learned on the way. His detailed guide to how he uses LLMs to help him write code should be required reading for anyone seeking to use the technology as a way of augmenting their own capabilities. And he regularly comes up with fresh perspectives on some of the tired tropes that litter the discourse about AI at the moment.

It is tough to wade through both the hype and the doom while trying to keep tabs on "the latest in AI". Simon has an excitement for this stuff, but it is always balanced, realistic, and thoughtful.

The author then goes on to quote Tim O'Reilly on the subject of "what does this mean for programming jobs?"

As Tim O’Reilly, the veteran observer of the technology industry, puts it, AI will not replace programmers, but it will transform their jobs.

Which compliments the sentiment from Laurie Voss' latest post AI's effects on programming jobs which expects we will see a lot more programming jobs in the wake of an LLM transformation of the industry.

And as my friend Eric suggested, the Jevons Paradox may come in to play where programmers are the "resource" being more efficiently consumed which will, paradoxically, increase the demand for programmers.