Yeah that's the other side of it, learning that is.

Before you would pause at overwhelming, now you get to "fail forward" with less at stake because the end result can still be verifiable even if the internals are a blackbox to you.

It's a sort of "deferred" and/or "optional" learning dilemma we now exist.

You could open the box, look inside, ask questions, but you would need to care and feel engaged, which is very hard to do when the result is already there.

This is why I framed it as requiring self awareness and discipline. Very easy to get caught into the slot machine dopamine cycle loop.

▲

skydhash an hour ago | parent [-]

Sometimes the end result is good, but the means aren’t. With the “give me something” approach of most LLM usage, often you won’t realize you have bad code full of hidden bugs. Often, the steps are “it works on my machine” follows by an error in prod.

	▲	hmokiguess 36 minutes ago \| parent [-]
		Absolutely, and this is true to handwritten code as well. This is why code review, tests, constraints, and putting effort into the critical pieces of software is paramount to success. I also would argue that in this case, the end result wasn't good but rather perceived good. It was good enough to pass a smoke test, but not an integration test, and end-to-end test, a runtime edge case, etc. All of software development lifecycle should still apply and be relevant here, the tool just changes the rate at how it gets written and it is tempting to move faster and continue skipping other steps. Especially so in greenfield work as a solo founder with limited time. I think at the end of the day, a good metric is your "give a shit quotient". How much do you give a shit about what you are doing is likely the most important thing into how it is going to perform.