chaboud

Well, it's safe for me!

It's amazing for us to consider "massively wasting someone's time" as "complementary".

That's like a free bus ride to Cleveland... if I wanted to go, I'd happily get myself there.

They seem to have changed this recently, possibly due to theft or items falling from the trunk.

My last two trunk-use rides have had closed trunks on arrival.

Fearful that a simple software issue could do exactly this, I have adopted an approach to using Waymo with luggage:

1. Get out. 2. Leave the door open. 3. Open the trunk. 4. Get stuff. 5. Close the trunk. 6. Close the door that I left open.

I've had enough stupid stuff happen in a Waymo. I'm not going to leave it to faith that it won't drive off with my laptop, etc.

Having had Claude Code jump to inserting juvenile and all-filtering regex to (attempt to) solve open-ended semantic natural language problems (-sigh- there's 12 hours of my life I'll never get back), I can absolutely imagine that this was someone trying to code up a "defense in depth" mechanic that was explosively insufficient after Claude Code (even Opus 4.6) made a series of faulty assumptions.

This one feels like prime space for Hanlon's razor: "Never attribute to malice that which is adequately explained by stupidity."

The hassle with the performance of these systems is that they're ~70% of the way to awesome. For advanced prototyping (my current job description), a fast 60% of awesome is groundbreaking and game-changing. For production and real businesses, that last 30% is a really, really important thing to figure out.

I was under the impression that insider influence was the point of these systems? Want something to happen? Bet a lot of money that it won't, pulling the market forces towards the action you want.

It goes from "taking out a hit" to "betting that someone will live to next Thursday". It's such an obvious outcome of these systems that I was operating on the assumption that it was the actual point.

So maybe the thing this guy did wrong was to be so face-palmingly pants-on-head obvious about it that they had to shut it down?

I think this is, more often, that we are spending too much time pretending to communicate. Far too often I've found myself in a meeting that doesn't have a quorum, but people try to have the meeting anyway. Even more often than that, I've found myself in a meeting that doesn't have the sufficient pre-requisites to be useful. It will just be some AI slop document dropped in front of folks, with little to no regard for coherent thought or responsibility. It's 30 minutes of gaslighting the readers, trying to make them feel stupid for "not getting it", followed by 10 minutes of "this meeting was a waste of time" course-correction (we read our docs in the beginning of meetings).

And the problem is that the communication (or alignment) is the thing that the meeting is supposed to be about, sharing well-considered thoughts and cohesive direction, soliciting meaningful feedback against clearly-articulated assertions. Instead, we're all-to-often addressing someone's attempt to turn their job into a group project, the stone soup of the modern business world. You can lay this bare by asking "what is the aim of this meeting?" early on, to level-set that the meeting owner isn't just setting up a study group.

Birds-eye-view-only managers only see work get done in meetings, so they assume that the meeting is where the work gets done. They don't understand all of the work that went into what came before the meeting to make it a successful one. If you rush the "communication" before you've found the clarity of thought, your meeting is just noise.

There's a simple but powerful response to this sort of persistent malaise, one that strikes fear in the hearts of the secretly inept: "I don't know, but let's figure it out right now."

When it's time to slow down and walk through the problem, I hold folks to an ordering of dependency: Why, What, How, Who, When... If you don't know all of the things before (e.g., Why, What, How - if you're trying to figure out Who), you cannot proceed. I don't care if you're an intern or a VP. No short-cuts to bullshit hand-wavy answers.

Decompose the problem, do the thinking, reason through it right there, and, if the team doesn't change its behavior, find another team. In the right environment, some folks are willing and able to step up to the plate and act like grown-ups working together to craft something better. Sadly, quite a few can't (or won't) answer the call to be responsible adults.

So they call another agenda-less meeting.

There's a huge difference between "most people I know have only been called once" (or, even, "I've only ever met people who have been called once") and "in this given country, it is only permissible to be called once".

Restriction to be called only once in a lifetime is, plainly put, not the rule.

Not quite. It's basically a combined mantissa and exponent test, so it can be thought of as functionally equivalent to scaling epsilon by a power of two (the shared exponent of the nearly equal floating point values) and then using that epsilon.

I think I'll just use scaled epsilon... though I've gotten lots of performance wins out of direct bitwise trickery with floats (e.g., fast rounding with mantissa normalization and casting).

The executive has the veto and a willingness to leave the government non-functional (funny how anti-government types are often okay with kneecapping government). They're not powerless.

From my experience with modern software and services, the actual practice of QA has plainly atrophied.

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.

Shooting down ideas is absolutely a skill, and it's essential to driving out the mountains of slop people throw out these days.

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.

I've joked that the 16oz US pint was a long-play metric-system scheme to drive adoption of 500ml (~16.9oz) as a measure, a Pavlovian mechanic to trick beer-drinking Americans that the metric system is actually better because it results in more beer. The joke's on them. We're all about 12oz cans! 33cl? pfft...

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.

Nerds solving interesting problems find a way. Folks (myself included) worked on Privacy Pass for verifiable ad attestation, but the power of blinded attestation is meaningful in ways beyond advertising authenticity validation.

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.

In a market with perfect price discovery, sure. However, over the years I have learned that even the best products for the job can (and will) lose without the right marketing, sales, distribution, etc.

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.

That's the polite version of "we know where you live". Telling someone you have their phone number is a way of saying "we'll call you and expect immediacy if you break something."

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

Awesome.... With Sonnet 4.5, I had Cline soft trigger compaction at 400k (it wandered off into the weeds at 500k). But the stability of the 4.6 models is notable. I still think it pays to structure systems to be comprehensible in smaller contexts (smaller files, concise plans), but this is great.

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

"When a measure becomes a target, it ceases to be a good measure."

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.

Three things:

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.

When I was a kid growing up in Texas, our ocean visits were to the Gulf of Mexico, off the Texas coast, and you would grab little alcohol wipes for when you got out of the ocean, to wipe the oil off.

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).

Why stop there? Just call the LLM with the data and function description and get it to return the result!

(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.)

I use Claude Code quite a bit (one of my former interns noted that I crossed 1.8 Million lines of code submitted last year, which is... um... concerning), but I still steadfastly refuse to use AI to generate written content. There are multiple purposes for writing documents, but the most critical is the forming of coherent, comprehensible thinking. The act of putting it on paper is what crystallizes the thinking.

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.

It's this line that I'm bristling at: "...the workflow I’ve settled into is radically different from what most people do with AI coding tools..."

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!"

The author seems to think they've hit upon something revolutionary...

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.

Cool. Good for him. I've been building agentic and observational systems and have been working to make them safe and layered in defense. And, well, I probably should have just said "fuck it" and put a disclaimer sticker on the front to let it fly.

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.

Having ripcorded out after realizing the author was trying to prove that water was wet, I'll assume that it's "normalized entropy", in a range of 0-1, indicative of the distribution across the space.

I had a TSA agent take my knife and hide it, carrying it over the X-ray belt and putting it in his bag in the secure area.

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

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

I used to have a Sikh manager who wore a turban. Whenever we traveled together, he would get "randomly" stopped. While they were patting him down, he would inevitably chuckle and say something like "So what are the odds of being 'randomly' selected 27 times in a row?"

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

Awwwww. I was going to hijack this plane and use it as a weapon in a divide attack, but $45?! You got me, TSA! That's just too rich for my blood!