I'm not a heavy AI user but there are a couple of things I noticed trying to make copilot generate something for me from scratch.

The first is that having a single file with everything you have in mind is very useful. So I end up writing what the project is about, how the model is organized, what each button does, etc. This is good practice in general because writing down everything that the AI will have to consider forces you to consider edge cases before you program them. E.g. if you write "the detail pane shows the fields of the selected item," it makes you consider what should it show when there are no items, or if multiple selection is possible. As you can imagine, this file ends up a very long document even for a simple project because the goal is to pseudo-program everything and let the LLM translate it to an implementation.

Then it still gets things wrong about design, e.g. which pane goes left and which goes right, if you don't also provide an image that shows the layout.

And then, if you supply an exhausting amount of detail, the agent can generate more or less what you had in mind....... or rather, it can generate an OUTPUT that matches your specification from scratch.

The problem is that if there is something you failed to consider, and the AI makes an assumption there, you can end up with a fundamentally broken architecture that you will have to untangle yourself later. And at that point it's easier to write everything from scratch than to fix a pile of AI code that is based on a flawed design.

And it turns out that due to the "totem pole" way that software works, there are infinite places in code that a bad design decision can affect everything it touches.

A good example is how 2 components in a UI are bound to data. You can use events, a bus, state reactivity, etc. Personally I think the mediator pattern is the simplest way to handle GUIs. But an LLM is probably just going to use events for property bindings.