Agree with everything you say here.

> I don't think anything here is new or changed

I would argue it's a little new though. I used to write dumb little programs all the time that explored an idea which was probably bad, and in that exploration I often found that there was a better way to do it, or that I didn't know as much as I thought I did, or that another thing already existed that was much better considered than my half baked idea, etc. But there was learning that happened there, so the process was still valuable. Now you can get a working bad idea without learning anything, there is full conservation of ignorance, but a full dopamine hit from "i made this thing". I guess you could argue it's just everything happening at a faster rate, but it feels different to me, and it is pretty eerie.

▲

hmokiguess a day ago | parent [-]

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 a day 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 a day 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.