[noduerme]

I've always spent 90% of my work time thinking and sketching what the architecture should be to solve a problem. I find that once I've worked that out, it's actually still faster for me to code it than to try to explain it and refine it in prompts. And the code ends up more succinct and covers the edge cases I've already considered. If I need a fast script to do one thing, or unit tests, sure an LLM is faster at writing those. But for clean code, nothing beats knowing what you're going to write and just writing it yourself.

[witx]

Exactly. At my previous work we spent an awful amount of time planning and architecting the solutions and refining them. No matter the person who prompted or the model used, the solution was never close to satisfactory.

Layers of unnecessary abstraction, weird decisions (like wth it used triple pointers once) hard to debug issues and obvious race conditions. Segfaults are through the roof and people are burned out and gasping hard to solve the bugs. I called their attention to this at the time and I was ignored and a bit laughed about. I left and couple months later I know others are too.

[kakacik]

... and 10x that for long term maintenance and evolution of the code. When you read your code later, understanding of it comes more naturally/faster than somebody else's code (at least for me). I break down bigger problems into small chunks in one way, other folks may view things differently.