In my first gig (~30 years ago), QA could hold up a release even if our CTO and President were breathing down their necks, and every SDE bug-hunted hard throughout the programs.

Now QA (if they even exist) are forced to punt thousands of issues and live with inertial debt. Devs are hostile to QA and reject responsibility constantly.

Back to the OP, these things aren't calculable, but they'll kill businesses every time.

However, the essential thing to do is to make sure that you're not shooting down the person. Better still, if you can socratically get them to the point of understanding why their idea won't work, that will have them own the shoot-down, and it may lead to a better idea that addresses the actual problem set more effectively.

When you know why something won't work, get other people there, but do it without being a jerk or crushing in inventive spirit.

I've been leading advanced development and applied science teams for decades. There aren't enough hours in the week to give every idea someone brings to me a full watch-them-realize shake, but I can (and do) take the time to make sure that the next time they have an interesting idea, they still want to bring it up.

Shooting down ideas is absolutely a skill; one that every innovator needs to have for their own ideas and the ideas of their collaborators. The way I learned it was to have others shoot my ideas down, and that's the way I teach it.

Germans have it nailed down with the Kölsch Stange, a 200ml glass that so readily disappears that it stays cold and you just get another from the Kranz.

For folks at the implementation level, the problem is often the prize. I just need to get paid enough to not care about how much I get paid. And implicitly contributing to social good is a form of gamification that works well. I've encountered lots of folks who operate in the same way. Yes, we're paying a bit more of a "feed the beast" tax than the good old days, but we're still able to operate with a remarkable degree of latitude.

Sometimes the entrenched default that collects an inertial premium doesn't get disrupted...

But, yes, anyone without a moat who operates with a presumption of retention runs the risk of being knocked off of their perch; their fate left to others.

Wanna be treated like an adult? Cool. You'll also be held accountable like an adult.

(And, yeah, I'm all Claude Code these days...)

Goodhart's law shows up with people, in system design, in processor design, in education...

Models are going to be over-fit to the tests unless scruples or practical application realities intervene. It's a tale as old as machine learning.

1. Confirmable, predictable behavior (can we test it, can we make assurances to customers?).

2. Comparative performance (having an LLM call to extract from a list in 100s of ms instead of code in <10ms).

3. Operating costs. LLM calls are spendy. Just think of them as hyper-unoptimized lossy function executors (along with being lossy encyclopedias), and the work starts to approach bogo algorithm levels of execution cost for some small problems.

Buuuuuut.... I had working functional prototype explorations with almost no work on my end, in an hour.

We've now extended this thinking to some experience exploration builders, so it definitely has a place in the toolbox.

Years later, swimming in Hawaii, I found myself looking for wipes. I mentioned it to a snorkel-outfit operator, and she looked at me like I was insane. They didn't even put damaging sunscreen in the water, and there was no expectation of little 1-2 inch sticky spots of oil.

The good old days, in the 80's, where we swam in oceans filled with slow-motion natural disasters. I wonder how much of it was place (Hawaiians seem to have a stronger relationship with the land and nature surrounding them) and how much of it was the time (20 years later).

(I'll admit that I've built a few "applications" exploring interaction descriptions with our Design team that do exactly this - but they were design explorations that, in effect, used the LLM to simulate a back-end. Glorious, but not shippable.)

However, I use Claude for a few things:

1. Research buddy, having conversations about technical approaches, surveying the research landscape.

2. Document clarity and consistency evaluator. I don't take edits, but I do take notes.

3. Spelling/grammar checker. It's better at this than regular spellcheck, due to its handling of words introduced in a document (e.g., proper names) and its understanding of various writing styles (e.g., comma inside or outside of quotes, one space or two after a period?)

Every time I get into a one hour meeting to see a messy, unclear, almost certainly heavily AI generated document being presented to 12 people, I spend at least thirty seconds reminding the team that 2-3 hours saved using AI to write has cost 11+ person-hours of time having others read and discuss unclear thoughts.

I will note that some folks actually put in the time to guide AI sufficiently to write meaningfully instructive documents. The part that people miss is that the clarity of thinking, not the word count, is what is required.

Anyone who spends some time with these tools (and doesn't black out from smashing their head against their desk) is going to find substantial benefit in planning with clarity.

It was #6 in Boris's run-down: https://news.ycombinator.com/item?id=46470017

So, yes, I'm glad that people write things out and share. But I'd prefer that they not lead with "hey folks, I have news: we should *slice* our bread!"

They've actually hit upon something that several of us have evolved to naturally.

LLM's are like unreliable interns with boundless energy. They make silly mistakes, wander into annoying structural traps, and have to be unwound if left to their own devices. It's like the genie that almost pathologically misinterprets your wishes.

So, how do you solve that? Exactly how an experienced lead or software manager does: you have systems write it down before executing, explain things back to you, and ground all of their thinking in the code and documentation, avoiding making assumptions about code after superficial review.

When it was early ChatGPT, this meant function-level thinking and clearly described jobs. When it was Cline it meant cline rules files that forced writing architecture.md files and vibe-code.log histories, demanding grounding in research and code reading.

Maybe nine months ago, another engineer said two things to me, less than a day apart:

- "I don't understand why your clinerules file is so large. You have the LLM jumping through so many hoops and doing so much extra work. It's crazy."

- The next morning: "It's basically like a lottery. I can't get the LLM to generate what I want reliably. I just have to settle for whatever it comes up with and then try again."

These systems have to deal with minimal context, ambiguous guidance, and extreme isolation. Operate with a little empathy for the energetic interns, and they'll uncork levels of output worth fighting for. We're Software Managers now. For some of us, that's working out great.

Yeah, these systems are going to get absolutely rocked by exploits. The scale of damage is going to be comical, and, well, that's where we are right now.

Go get 'em, tiger. It's a brave new world. But, as with my 10 year old, I need to make sure the credit cards aren't readily available. He'd just buy $1k of robux. Who knows what sort of havoc uncorked agentic systems could bring?

One of my systems accidentally observed some AWS keys last night. Yeah. I rotated them, just in case.

It was a $13 knife, but he liked it.

No doubt that was a security violation, but it's all security theatre.

I don't know the specifics of the process for selection, but I can confidently say that the process is bigoted.