That’s the source of my “easy” framing. It has always had the lower cognitive load in my experience. Now that I can offload the mechanical part to AI, I spend more time on the hard parts.
I still read plenty of code along the way, maybe less of it now because it’s easier to surface which parts of the code I need to read.
They're called Business Analysts, sometimes simply Analysts, and that's effectively their job - come up with a spec and give it to the software engineers.
to further that example, many people with the help of AI are ostensibly copy pasting trig problems from the book without understanding the mechanics running through them and labouring under the impressions they’ve become closer to skilled mathematicians
In my view, "programmer" merged with "analyst" to become "software engineer".
The only reason dev jobs paid more (by a factor of two or more) than pure solution modeling was because "writing code" was the hard part.
If you wanted to get paid just modeling the solution and handing it off to a coding team, those jobs were available for decades, typically called Business Analysts but few devs moved from dev to BA.
> Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load.
I've found that the act of physically writing refines my understanding a lot more than simply reading.
We don't typically expect a person to read a trigonometry textbook and then perform well on an exam. They have to drill problems to surface their misunderstandings to themselves.
My fear is that, with developers adopting your approach, they're "designing" systems in much the same way that a read-the-book-only trigonometry student solves trigonometry problems.