I think it's important to be conscious of skill atrophy, but I don't see a problem with it if what you're offloading to AI isn't your area of focus. For instance, I don't necessarily want to always know what tricks the compiler is using to compile my program, even if they are pretty smart.

▲

grayhatter 5 hours ago | parent | next [-]

I doubt it's possible to draw a concrete line between in domain, and out of domain. Would you mind trying with a specific example? Because so much of engineering is understanding the interactions between systems. While I cant enumerate the exact asm codes, I do need to understand how the compiler is going to rewrite my function if I want to understand if a cast is safe, or if this function call order needs to be rewritten, or if I'm need a mutex to protect this from a torn read.

	▲	fibonachos 4 hours ago \| parent \| next [-]
		One specific example that comes to mind is developer tooling in the form of bash scripts. Sure, I can write it myself, but I do this so infrequently that there is a cost for the context switch and ramp up. This, and similar dev ex things that have been languishing in the “one day” pile because there is always the next feature to build. I can now spend 10 minutes here and there to ship incremental QoL improvements alongside my core work.
	▲	docheinestages 4 hours ago \| parent \| prev [-]
		I'm not disagreeing with your point. A good understanding of the domain and relevant systems is quite crucial. My point is that you don't always need to inspect the code at such low-level detail, provided there are tests or other ways to prove that the code behaves in the way that you describe.

▲

slopinthebag 2 hours ago | parent | prev [-]

I think Mitchell Hashimoto as a pretty sane take here, where he uses LLM's to offload stuff he doesn't care about / want to think about so he can spend more time and brain power on the stuff that really matters. I tend to agree.