Perspectives on LLM-assisted development

Work in progress.

This post collects various content about LLM-assisted development that I think contain interesting ideas and are written by humans, along with some of my own commentary. It is a bit disorganized: I have wanted to blog about my thoughts on the direction of the software development industry for some time, but have hemmed and hawed over how to phrase things. In the end, I decided that I should simply dump all the thoughts in my mind, for otherwise no blog would ever be written, and the result is this post.

Prelude

I have conflicted thoughts on LLM-assisted development.¹

Without doubt, there is some part of me that is saddened by the reduced need for writing code by hand. For many years, I enjoyed playing with and debating the shape of the code that I craft. Code is not merely a means to an end to me.

Yet I also enjoy building things, and solving user problems. Many of my open-source contributions to the YAGPDB project were motivated by (occasionally frustrating) support threads users in the community Discord and looking for patterns in the types of questions they raised.

Historically–until early this year, perhaps–my position was thus split. With my craftsman hat on, I felt that I ought to reject LLM-assisted development, and feel only sadness about the direction of the industry. On the other hand, with my builder hat on, I felt that I should certainly try out LLM-assisted development. Yet whenever I did so I felt only frustration. The tool was slower than I imagined; it interrupted my train of thought; and it generated objective slop. I found it difficult to reconcile my experience with reports from respectable developers I follow.

It eventually became clear to me that I was missing some nuance about how to work with LLMs effectively, but what this was I could not tell. But whenever I attempted to learn how to work with LLMs in a more principled way by looking for posts and guides on the web, I was swamped by a deluge of clearly AI-generated content. When even the official OpenAI and Anthropic documentation is AI-generated with minimal signs of human intervention, what am I to do?

---

With these points in mind, the rest of this post attempts to do two things:

1. Collect human-written posts that contain interesting ideas about LLM-assisted development (and offer some commentary.) I don’t necessarily agree with all the positions in the linked posts, but I do think that they are worth reading, to inform your own thinking and improve your mental model of where LLMs can help you and where they cannot.

2. Argue that LLMs can benefit the software craftsman too–one who cares about the shape of the code need not necessarily despair and flee the industry.

Jagged edges

The first thing I think one should understand about LLMs is that their output quality can have surprisingly high variance. In other words: there are “hard” problems that (to my surprise) the LLM does exceptionally well on, and conversely there are “easy” problems that (to my surprise, or disappointment) the LLM fails on. (The difficulty levels in quotation marks are relative to my judgement.)

If you don’t believe this assertion, the spoiler below includes some examples in the first category: in other words, “hard” problems that LLMs did exceptional on. If you already agree that LLMs can surpass humans in various interesting settings, then you should skip this section, because it will sound like advertising for the AI labs–which, in some sense, it is, though I’m not affiliated.

Show examples

• OpenAI models conclusively beat world-class competitive programmers at algorithmic contests.

• OpenAI models conclusively beat world-class competitive programmers at heuristic contests, with a significantly shorter and simpler solution

• Fable 5 identifies a massive performance improvement in a critical subsystem of the Ghostty terminal

• Fable 5 ports Bun from Zig to Rust while seemingly improving user-facing product quality: the port is controversial (and the link goes to an Anthropic blog, which certainly should not be trusted on face value), but I have not seen evidence for the claim that, from an end user perspective, the Rust release of Bun was noticeably more buggy than the Zig version. I will remove this item if I receive credible information otherwise.

  To make it clearer what the achievement is to me: Fable 5 ported a massive Zig codebase (of questionable quality, admittedly) to a Rust codebase (of similarly questionable quality) faster and more cost-effectively than a human, without introducing more user-facing issues. This is interesting and impressive to me.

• OpenAI models resolve a longstanding mathematical conjecture of sufficient importance that the result could be published in a top academic journal: not related to programming, but as a wannabe mathematician I feel the need to include this :-)

To reiterate, the point of this section is as follows. I am not arguing that LLMs can solve every hard problem (that would certainly be a reason to despair!) but rather that it definitely can solve hard problems, and that it’s a bit tricky to see the pattern in which problems it can solve. Thus you should approach LLMs with an open mind; they may well surprise you occasionally instead of frustate you.

How sane humans use LLMs

In this section, I collect some experience reports from sane human developers (so, most of the lunatics from my Twitter feed do not count) on LLM-assisted workflows.

• “My AI Adoption Journey”, Mitchell Hashimoto
  • I was aware of Mitchell’s excellent technical reputation long before LLMs. When I was learning the Go programming language, often I would see comments suggesting to read Hashicorp’s Go code to understand idiomatic Go style. If nothing else, I think Mitchell is a very good developer with good taste.
  • I agree with the point that it is worth trying to replicate your work with LLMs for some time at the start, even if it is excruciatingly slower than doing it by hand, to be able to build a good understanding of the tool. When I was going through this initial learning process myself, there were several times where–after finishing a Claude session with multiple rounds–I felt the irritating sense that I could have written this code a whole lot faster myself. Eventually you get a slightly better sense of what the tool is useful for, and the feeling goes away. Sometimes the feeling is just plain hubris too and an overestimate of how fast I can actually code.
• “Agentic Coding Recommendations”, Armin Ronacher–note that this post is about a year old, and Armin states that he doesn’t expect it to age well, but I think that there are some durable ideas
  • Similar to Mitchell, I think similarly about Armin’s reputation. I have never touched Flask in my life, but insta is pretty neat.
  • The advice on writing scripts for LLMs to use (and the specific recommendations Armin lists) still feels relevant to me. Though agents have gotten a whole lot more intelligent in the year since, reducing the number of intermediate commands that an LLM needs to run to test a change helps with context bloat and speeds up the process overall.
• “Know thine enemy: A critical engagement with AI-assisted software development”, Amy J. Ko
  • On the weaknesses of generative AI.
• “Talk more to your coding agents”, Will Jones
• “How I use LLMs as a staff engineer in 2026”, Sean Goedecke
• “Artificial adventures”, Jamie Brandon
• “From a Luddite to a Vibe-Coder”
  • Lots of AI-generated images, but the text seems human-written and is worth a skim, I think.

LLMs can benefit craftsmen too

• “Using AI to write better code more slowly”, Nolan Lawson
• “The Short Leash AI Coding Method For Beating Fable”, Greg Slepak

The future

• “Rewriting Bun in Rust”, Jarred Sumner
  • No, I’m not saying that Bun is the future, and this post probably has Anthropic marketing’s fingers on it. But there are some interesting, if brief, technical details about how dynamic workflows were used to port Bun in a more systematic way than “rewrite in Rust, make no mistakes!” that are worth reading.
• “The Coming Loop”, Armin Ronacher
• “In defense of not understanding your codebase”, Sean Goedecke
• “A new era for software testing”, Salvatore Sanfilippo aka antirez
• “Control the ideas, not the code”, Salvatore Sanfilippo

Tutorials for Claude, Codex, etc.

This section is about actually figuring out, mechanically, how to get started with your coding harness of choice (how it works, what the commands do, what the key terminology is.) Unfortunately I have not found a good introductory tutorial that is human-written… so there is some slop in this section, albeit somewhat useful slop.

• “How to Build an Agent”, Thorsten Ball
  • Not slop. Really great blog that shows the inner workings of an agentic coding harness (i.e., how you go from something like the original ChatGPT to something that can edit files and so on.)
  • It helped me build a better mental model for what Claude|Codex|... do under the hood, and why it’s important to keep threads short when possible (to avoid quadratic scaling.) Also just plain interesting. You should have an idea of what your tools know under the hood.
• “Agentic Engineering Patterns”, Simon Willison
  • Not slop. That said, it’s not a tutorial per se and hence doesn’t fit perfectly in this section. But it has some useful content.
• “How I Use Every Claude Code Feature”, Shrivu Shankar
  • The clanker definitely had a hand in the writing of this piece, but I’m pretty sure the human did too. And it’s kind of useful!
• “Best practices for Claude Code”, Anthropic
  • Has that slop texture to it, but just hold your nose and tolerate it.
• If you want to skip the middleman, you can also just ask Claude or Codex or whatever you’re using about specific commands and features of the harness. It’s not bad.