I like to use frameworks to steer the agent. I constrain it different primitives for different tasks in order get the shape I want without explicitly prompting too much. You can think of it as API driven development

If this is true, the frameworks will either move to the specs or, worse, remain in the models.

You can't exhaustively write down all the possible ways for software to execute, especially since many programs run forever (e.g. servers, GUIs etc)

So when you say in your spec "when the user clicks here it shows this stuff" there is the tacit expectation that this will always happen and isn't dependent on the entire execution path up to this point. You also wouldn't expect a server to just finish execution after processing a request because you forgot to write "finally, cede control back to the main loop" at the end.

These assumptions are the framework. Almost everything you read is likely written in a framework, unless you limit yourself to non-technical writing for younger readers.

You could try to formalise the framework in your specs. But you'll then end up copy and pasting these paragraphs every time you want another server program. These context frameworks will probably get names, just like today.

Or you could skip that entirely and pretend you're not using a framework, but you are. It's just that the most has already learned tons of frameworks. What worries me here is stagnation. There's no way for the model to learn new frameworks. But this might be a short term effect. Maybe software in the next few years will look quite odd to those in the future as we keep writing it in the language of frameworks we already know. Maybe they'll look back at these relics and ask "what is a view, and why did the model understand that?"