It's fine for your pet projects. But for most of professional programming it's no longer feasible as you'll be at a small fraction of your machine assisted performance.

▲

sph 4 days ago | parent | next [-]

My performance in writing code was never once the problem. I don’t get why I should increase the amount of output by depending on a third party tool to do my thinking to whom I have to explain my very abstract thought process in words.

The point of being an experienced programmer is thinking in data structures and transformations, not in prose. Why would I introduce all that friction?

▲

witx 4 days ago | parent | prev [-]

If you think performance relates to speed and amount of code per unit of time yes. If you're more grounded with the reality of software engineering then no

▲

varjag 4 days ago | parent [-]

I have in fact masters in SE and three decades experience of commercial programming. Loved every minute of it (well except the burnout episode) and still do my hobby projects. So I would say no, you are wrong. The models decimate not just the coding (the best and the most fun part of development) but all the pseudo-engineering roles like architects or product managers too. Simply because there's less need for communication in the team as the surface of work for each dev is now quite enormous.

	▲	witx 4 days ago \| parent [-]
		Well and my experience of 2 years working full time with AI (and 15 others of engineering) on safety critical adjacent products tells me you're full of it and wrong. We've had 4 teams on this model and sure it helped in some things (mostly data analysis and scripts) but generating code and doing architecture is utter crap 90℅ of the time. So much so that we've even had juniors noticing some design patterns that, and I quote: "this is one the examples of bad code we were taught in sw design classes'. The worst is how non deterministic they are. The same prompt from different people yields vastly different results SW engineering is mostly x + y + z Where x=planning, y=writting code and z=reviewing, then rinse and repeat. Llm spedup y but made everything else take so much longer that equation result is much worse. Now reviewing is utter torture and during planning we're dicussing how to mitigate the pitfalls of LLM (like over engineering, too many abstractions) that we spend fewer time on the planning of the engineering itself and more on cuddling this brain addled tool