I like to think of it as a how -> what -> why pipeline.

Early programming in assembly mostly involved telling the computer how to do things that you want it to do. You instruct it in terms of the mechanical capabilities of the machine.

Compilers and interpreters came along and raised the layer of abstraction that programmers work on from the "how" domain to the "what" domain. Instead of saying how to move bits around to solve problems, we tell the computer what to do, and it would do it. Even languages like C in which programs seem like a description of how to compute something, they are more of a vague suggestion to the compiler, which will do what you told it to do, how it wants to do it.

Now in the era of agentic programming, the "what" isn't even the domain that programmers are operating in, it's "why". Why should we use these technologies? Why should certain architectural decisions be made to support future development? Why should protocols have or not have certain information in them? The relevant "what" questions are handled by the LLM, just like the "how" is handled by the compiler.

I really like using spec-driven development to capture the "why" as artifacts. I personally use the tool openspec, and I like it because it explicitly captures my reasoning in the documents it produces, but I'm sure there are other solutions. I also have a prompt that will generate a commit message for a change that captures "why" instead of "what", based on the conversation history. This is better than just describing what changed, because the diff already does that, and if you're looking at a commit to understand it, generally you'll be confused by the "why".

No matter how you do it, find some way to capture "why" as a material artifact. The "what" is the code that basically anyone can make now. Why will maintain your purpose.