I think that's just the way you're doing it?

I feel the opposite. I appreciate the ability to iterate and prototype in a way which lowers friction. Sure I have to plan steps out ahead of time, but that's expected with any kind of software architecture. The stimulating part is the design and thought and learning, not digging the ditch.

If you're just firing off prompts all day with no design/input, yea I'm sure that sucks. You might as well "push the big red button" all day.

> If it fails, I just switch to another model—and usually, one of them gets the job done.

This is a huge red flag that you have no idea what you're doing at the fundamental software architecture level imo. Or at least you have bad process (prior to LLMs).

> I feel the opposite. I appreciate the ability to iterate and prototype in a way which lowers friction.

I feel the same way. Things I like: Thinking about architectures and algorithms. Things I don't like: Starting out with a blank slate, looking up the exact function names or parameters. I find it much easier to take something roughly implemented and improve upon it than to start from nothing and build it.

I think about what I want fairly specifically. I discuss it with the LLM. It implements something. Half of the time it's what I expect, I can move on. Sometimes it's done something I wasn't expecting in a better way, which is nice. Frequently it's done something I wasn't expecting in a worse way; I either tell it to fix it, or just fix it myself.

In my previous role, I did a huge amount of patch review, which I always found quite tedious. Even though this looks superficially similar, it doesn't have the same vibe at all. I think it's because the LLM will accept being told what to do in a way no self-respecting coder would. (One complaint I'd heard about another person's reviews was that the person whose code was reviewed felt like they were a marionette, just typing exactly what the reviewer told them to type.)

This way I can do the things I enjoy, while neither having to worry about some human being's feelings, nor having to do the low-level stuff that's a chore.

As the saying goes, mathematics is not a spectator sport. The same applies to programming. If you don't do the lower level work, you are a spectator that is rearranging other people's laundered code, or even their laundered architectures.

For prototyping UI it's actually amazing.

"Add a sidebar to the side that tracks where we are in the document".

"Move all elements in area A into a split screen view with those elements at the left hand side and the remaining elements in the right hand side"

The above sort of thing can be painful to do manually. Changing a layout which can have 100's of elements and moving everything across to the new layout structure. Often you can waste a day tweaking it in various ways. LLMs are actually pretty amazing at it since it's a job where you "put old things from one context into a new context" and that's basically what they do. As in AI has saved me some of the biggest pain points and allowed me to focus on the meatier aspects of the code (which it's not so good at).

> This is a huge red flag that you have no idea what you're doing at the fundamental software architecture level imo. Or at least you have bad process (prior to LLMs).

Particularly in the present. If any of the current models can consistently make senior-level decisions I'd like to know which ones they are. They're probably going to cross that boundary soon, but they aren't there yet. They go haywire too often. Anyone who codes only using the current generation of LLM without reviewing the code is surely capping themselves in code quality in a way that will hurt maintainability.