> When you watch someone who knows what they are doing, you'll see them looping over the following steps:

> Build a mental model of the requirements

> Write code that (hopefully?!) does that

> Build a mental model of what the code actually does

> Identify the differences, and update the code (or the requirements).

This is pretty right on but I think it leaves out an aspect of writing code that I think is often pretty under appreciated. Code does two things at once: it provides a set of instructions to a machine and it communicates the authors' understanding of the program behavior those instructions are intended to express. I think this is a large part of what makes programming so fascinating and frustrating. It's what's behind the cliche that "naming things" is one of the hardest parts of programming. In growing software systems it's often not enough that a feature's implementation works. Ideally, that implementation should impose a minimum barrier to understanding for contributors to do something with it afterward. I'm not convinced this is an aspect of software development that LLMs will be able to meaningfully achieve.