And UML even made a lot more sense to precisely describe a problem compared to human language prompts.
IME it's more useful to treat a source file (or new project) like a sketchbook, you start with an empty sheet of paper but already have a rough idea what you want, then you quickly sketch out the outlines, try out different ideas, explore different solutions (all without going into too much detail yet), you step through the code, explore some different paths to get an idea what "feels right", delete things, shuffle them around, rewrite them and slowly filling out the details and that way incrementally get towards the first working version.
Which such an approach of incremental "micro-feedback-loops" you already eliminated a lot of dead ends that will appear anyway despite the best plans - but identifying such dead ends early is much better than late.
This incremental approach also forces you to keep the code small, tidy and malleable. The planning stage basically already happens in source code, and it's not one long planning stage, but many micro-planning-stages.
...this is also my problem with the current state of LLMs, they're pretty good at creating a first initial sketch from a very general problem statement (but only for things that have been done thousands of times by other people - but that's a different issue...) - but the more you'll need to go into the details and discover and fix problems in your initial 'mental design' (e.g. discovering what you actually wanted in the first place), the more the differences to traditional programming disappear, and at some tipping point it gets even more complex because you need to steer the LLM with a language (the human language) that simply isn't useful enough for detailed problem descriptions - that's why lawyers, mathematicians, engineers and scientists all invented their own precise 'DSLs'.
After a few iterations your prompts need to be just as detailed as writing source code in the first place - so what's the point of writing prompts in human language again?
I feel like productivity could be improved much more by improving programming tools (yeah - boring old-school incremental maintenance work) instead of betting on some weird AI future which will just move the focus from writing source code to writing human-language prompts (which IMHO is a definitive step backwards because human language lacks precision - and adding that precision is how you end up with programming languages).
Why are editing, compilation and debugging/testing still separate steps, why do debuggers still have those 60s style bare variable panels instead of realtime visualizations of the internal program state? Why do I still need to wait for a build to finish? Why is version control still such a PITA to work with? Instead everybody is jumping on the AI hype train while everything around them is crumbling into a post-apocalyptic wasteland.
A Driverless Tesla Will Travel From L.A. to NYC by 2017, Says Musk
https://www.nbcnews.com/business/autos/driverless-tesla-will...
Ray Kurzweil was even more on the money in his 2006 book "The singularity is near". I remember reading some of the stuff in there that is now happening. From the top of my head he predicted 2030 for human-level AI hardware and software that could be bought for 1000 USD by anyone. I feel he's going to be very close.
But do you want to chat a bit about your math journey? I saw it here [1]. I'm curious about it. If you're (potentially) up for it, my email is in my profile.
Cheers!