I'd argue that another key aspect is to break programs up into small independent units that can be verified in isolation, and to compose them into larger programs with contracts between them. I've had a pretty good experience using Claude with a framework where I express the program as a state graph, and each node is treated like a microservice that gets some input and produces some output. Then the workflow engine verifies that the output matches the declared schema and then decides which step to execute next. https://github.com/yogthos/mycelium

As the state travels across the graph, I keep a trace of the steps which were executed, which means that when an error happens, the agent has a lot more information than it normally would, it can see what decision points the code passed through already, it can cross references that with the declared workflow, and quickly find where it screwed up.

The idea of workflow engines has been around for a long time, but they feel too awkward to use when you're writing code by hand. Writing conditional logic directly in the code keeps you in your flow, and having to jump out and declare it in config somewhere feels awkward. Coding agents completely change the dynamic though because they don't have that problem. If the LLM is writing the code, then I can just focus on ensuring the code meets the contract, while the agent can deal with the implementation details.