cabacon

I have a kid in high school who uses LLMs to get feedback on essays he has written. It will come back with responses like "you failed to give good evidence to support your point that [X]", or "most readers prefer you to include more elaboration on how you changed subject from [Y] to [Z]".

You (and another respondent) both cite the case where someone unthinkingly generates a large swath of text using the LLM, but that's not the only modality for incorporating LLMs into writing. I'm with you both on your examples, fwiw, I just think that only thinking about that way of using LLMs for writing is putting on blinders to the productive ways that they can be used.

It feels to me like people are reacting to the idea that we haven't figured out how to work it into our pedagogy, and that their existence hurts certain ways we've become accustomed to measuring people having learned what we intended them to learn. There's certainly a lot of societal adaptation that should put guardrails around their utility to us, but when I see "They will make us dumb!" it just sets of a contrarian reaction in me.

I guess my point is that the argument being made is "if you lift dumbbells with a forklift, you aren't getting strong by exercising". And that's correct. But that doesn't mean that the existence of forklifts makes us weaker.

So, I guess I'm just saying that LLMs are a tool like any other. Their existence doesn't make you worse at what they do unless you forgo thinking when you use them. You can use a calculator to efficiently solve a wrong equation - you have to think about what it is going to solve for you. You can use an LLM to make a bad argument for you - you have to think about the inputs you're going to have it output for you.

I was just feeling anti-alarmist-headline - there's no intrinsic reason we'd get dumber because LLMs exist. We could, but I think history has shown that this kind of alarmism doesn't come to fruition.

Yup. I have an Erdős number, but despite being a Bacon, no Bacon number to my great dismay.

Yes, absolutely. They did something like this at the Sun Microsystems field office outside of Chicago while I worked there. You would log into a sunray with your smartcard and pick up whatever you had left behind in your session, with no permanent desk assignment.

It was unpopular, to say the least. Your personal belongings went into a pedestal on wheels that you could take to whichever workspace you wound up at that day. This was in 2000/2001 or so.

Truth be told, I don't think I'm calibrated on the question yet; I've only used it twice. In one org, there was a shining star who attracted all the answers. In the other org, someone laughed because of the number of good answers, and started rattling off names and reasons.

In hindsight, I wish I'd had enough experience with the question and possible scenarios to ask for a second answer from people in the first org; I suspect there were more good answers available, but one obvious answer that everyone snapped to first.

My favorite interviewing question as an IC was "Tell me about someone on your team you admire". It let me learn about what people valued based on why people were admired, and gave some depth-of-bench sense whether there were lots of distinct names, or if everyone was in awe of the one good person on the team.

If you're looking for cross-team health, maybe you could adapt it to "Tell me about someone on the other team that you admire?"

Regarding "theoretical best", I think that is "in the absence of mitigations". I think you can build a service with a higher SLA than one of its dependencies, but only if you recognize that impedance mismatch and build in defenses.

As a contrived example, if you've got a microservice that provides data FOO about a request that isn't actually end-user critical, you can mitigate your dependency on it by allowing your top-level request to succeed even if the FOO data is missing. Or maybe you can paper over blips of unavailability with cached data.

But, yes, know what you depend on and how reliable they are, then see if you need to take more action than that if your target is higher than the computed target.