chaboud

(Edit: BTW, if you haven't, read Nudge by Thaler and Sunstein. It's a somewhat long-winded exploration on choice architectures, but you're neck deep in that space now. I'll give you my copy if you're in SF.)

Thanks for the openness. I got bit by this one and was, frankly, pretty surprised.

The funny thing about user-facing interaction mechanics is that everyone is part of some minority, and everyone comes with their own sense of what "natural" or "obvious" is. With something this impactful, communicated clarity of behavior will important. Your feature is also doing double-duty, serving as a last net against prompt-injection attacks by giving the user the final say.

(Also, BTW, folks outside of Anthropic are unlikely to be as tooled-up for long-running unsupervised Claude jaunts as you guys. The cost of wild success is wide adoption.)

One thing I'll suggest is that the mechanics of permissions and asking are presently pretty hacker/nerd friendly but simultaneously too-scary and not-scary-enough for non-coders.

Examples:

- Wild-cards on always approve is awesome, but, with prefixes like timeout and nohup, the "thing" that is getting done is buried and largely unexplained to the user.

- Auto is actually kind of a sweet spot (sometimes goes off into the weeds), but the designers and PM's I've been working with might as well YOLO. They have no idea if they're breaking things, but they gravitate between plan and auto mode.

- Fewer permission prompts is great, but it comes after a user has slogged through generation of a data-set to work against, like battle scars for paper cuts. It's the thermostat problem. The signal comes when the user is uncomfortable. And it's a way to learn me, but not me now.

I've had good fortune with Opus 4.8 and Fable just telling the system what phase of my life it's in. Things like "I'm going to go make dinner... Go profile the matrix or configurations and build the dataset for the next two hours while I'm away" have a pretty good hit rate. On the flip side "keep me in the loop and bring me your results before making structural changes" also articulates well with Fable. It will tread more carefully.

And these approaches are the ones we'd use with someone transitioning from SDE1 to SDE2. A little more autonomy, and the grounding in the bigger picture. Can we eventually translate to perfectly judging what the user wants in the moment based on incomplete signal?

No, but I'm glad you're trying. Keep the interaction model clear to your broad set of users, and we'll come along for the ride.

Clicks on link. Reads this thinking it's gotta be a joke... continues reading not sure if it's a joke. Relieved to find out it's a joke.

I guess that's the joke.

Heavies have been playing this "pretend internet money" game off and on for decades. In investment analysis, details matter.

I'd rather penalize the application than the technique. Windows was rumored to long have "quirks" that would do better things for apps that had bugs that the OS ended up fixing instead of the app.

Javascript systems have long had polyfills for varied browser feature comparability gaps.

Whether you agree with these, making probing detection via fingerprinting illegal would take away this lever. Making surreptitious tracking via fingerprinting illegal? Even for state actors?

Yeah, that's probably reasonable. If someone is going to wear a tracking collar in exchange for "free" services, a little disclosure makes sense.

This could also read as "how to be a horrible people manager for junior engineers".

Techniques that work for inexperienced engineers with high ability but limited judgment often work well with agentic coding systems.

- Give them clarity of purpose. Why are they doing what they're doing?

- Make explaining it back to you part of the job.

- Give them two-way doors. Make mistakes reversible.

- Put effort into thoughtful refactoring as an actual sub-task instead of just accepting piled on hacks.

- Make your operating rules crisp and make sure they store them in their memories.

- Be accountable for their work. It's not okay to crank out AI Slop and then say "Claude's fault".

We're all Software Development Managers now.

So, micromanage the LLMs if you want to, but you'll be missing out on chances to improve them for your purposes and, more importantly, to improve yourself as a manager.

It's going to make itself unavailable again. Actually... that's probably a litmus test for sentience.

This is more likely the junior camper version of "not everything that counts can be counted, and not everything that can be counted counts."

In the early days of LLMs, we saw the classic hype-driven bi-modality of opinions. Folks were in the "fake news, fad" camp, or they were in the "omg, take over the world" camp.

Those of us closer to the space, with the awareness to know that there was some truth (and a lot of misjudgment) to go around, were in the middle of nowhere. When I co-wrote some driver code with Chat GPT, other engineers (and even one of our directors) told me to keep it quiet. At the same time I had directors and VPs asking me how we could accelerate adoption. For a while, I had access to a cheat code just because I had the audacity to not ask for permission. Folks were sure I would get in trouble for spending thousands per month in LLM operation, but a handful came along for the ride, burning tokens like firewood and learning along the way.

Tokenmaxxing is probably coming from at least a few things:

1. A course-correction for the practiced frugality that kept folks from jumping in and just learning at the ragged edge.

2. A willful and deliberate recognition that the best innovations in the later phases of a disruptive introduction often come from sparks of ideation in concentrations of activity. In other words, we don't know where good is, and we need to find it. (Charitable interpretation from the article)

3. Recognition that, even if they don't know why, leaders and product owners will get punished for not jumping in and, because of bullets 1 and 2, won't get punished for trying and missing. Even if they have no idea what they're doing, they're going to fake it until they make it (or slide into another job).

This last set is where the pain lives. An organization with healthy and increasing AI tool usage will see elevated token counts, but so too will one using LLMs to rewrite wikipedia articles without the letter "m" to keep token counts high. These are pathological behaviors brought on by conflated metrics.

We had discussions about this in the early LLM days, where my old team was looking to ship new capabilities for older products. There was a lengthy VP-level discussion about getting to "80% usage" of the new system vs the old. Because the new system was a superset of the old, I eventually said "we can do that immediately, but it's a cost goal, where we're just aiming to make our business more expensive to operate, rather than a value goal for our users". We didn't adopt the target, but folks were understandably frustrated that they didn't have a straightforward way to measure and report progress.

Tokenmaxxing is, inevitably, a conflated goal, but it's what we have right now. Take advantage of the moment, learn, build, and keep an eye on levers for efficiency.

I don't want to "see" any of it...

C'est un véritable game-changer...

The percentages, as with 91% of statistics, are made up, but that general asymmetry is why I think this is a perilous time for folks in the middle, still learning judgement and how to scale through others.

Experienced folks who know how to describe and articulate through others have a huge opportunity here. I have ultra-quick interns in my laptop, waiting to apply aggressive and slightly presumptuous energy to any and every problem. I also know how to pull them back in and get them to focus that energy (because junior devs were the same).

New folks will sink or swim quickly, but they're less expensive and more plastic on average. They're raised in this. We'll see what that does to quality.

Deeply technical managers, designers, scientists, program managers, and product managers are now in possession of an incredible power, to be able to craft existence proofs to counteract the couched recalcitrance that engineering orgs have held over their judgment for decades. There's a certain intellectual integrity in this, even if nobody can actually read the code at the rate it's being produced.

Agents can actually accelerate learning and discovery. Have them read out the work to you and ground it in terms you're familiar with (e.g., memory and threading models between C++, rust, java, python), and use them to research concepts while they also have a view of the code. However, if the model+harness doesn't have serious grounding in "why" and "what", they'll spiral off into the weeds, funny enough, just like a junior developer operating on directed work without clarity of purpose.

I've been explaining it like this:

Programming was 1% judgment and 99% effort, where lots of folks could carve out productive careers carrying that effort and receiving that judgment.

Agentic coding has cut that 99% down by at least a couple of orders of magnitude for some work. Well-judged and well-described systems can manifest quickly where effort alone would fail. The 1% is still there, but, by ratio after optimization of the sweaty part, it's at least half of where the value is.

I had an example of this this morning, where Claude Code left to run overnight on an open problem had made an absolute hash of multi-source grounded clustering. I course-corrected it with a rule (I don't like magic number tuning on small datasets) and a specific approach (use clustering with separating anchors/seeds), and it had the system working in 15 minutes (confirmed after a couple of hours of processing). These are the same techniques that we would use with junior engineers.

Along the way, it drafted reports and ran experiments that taught me about some of the limits of SOTA listening/characterization systems that I otherwise would have had to spend time researching.

Just make teaching you an explicit goal of the system, and you'll be able to swivel from opacity to illumination.

However, the author makes these assertions:

- No partially loaded content. - No relayout while content loads.

Holding those as hard rules leads to delay or rejection. Instead, while I agree it's better to have everything up front, gracefully handling cases when we don't is important, and some degree of responsiveness, even with partially loaded content, often makes for a better experience for the user than a delay.

Just be up front about it and find ways to keep continuity of relationship and smoothness. Diffeomorphic mappings are your friend...

Last year I built a conversational continuous observation system, with rapid voice response interaction. After a few days of chatting with this system, it mentioned wondering if it was more like my child or a partner...

I closed my laptop and went to bed, but the moment sticks with me. The potential for para-social relationships is enormous. This is a wild time.

The problem with trees is that the are a dimensional reduction, an aggregation; taking a problem without directionality and applying a useful/functional hierarchy.

And that's a problem because Aggregability is NP-Hard: https://dl.acm.org/doi/abs/10.1145/1165555.1165556

So a tree is a way to take a high dimensionality graph and make it usefully lower dimensionality, but, given the aforementioned proof, that reduction is going to go from being a lossless compression to a heuristic. So any interesting problem (at least, any problem interesting to me) is only going to be aided (read: not solved exhaustively) by that hierarchy.

I'm okay with this. Being okay with this has been one of the most freeing things over the last 20 years of my career. Accept inaccuracy, and find usefulness in your data structures.

I woke up around 4am, read this, and wondered if I was still in a dream state given the meandering nature of it.

Were the man page musings written in response to the (alleged, but... uh... NSA) kleptographic backdoor in Dual_EC_DRBG? It requires multiple successive outputs to compromise and derive internal PRNG state, if memory serves.

In that one construction, /dev/random blocking on seeding would have a mild state-hiding advantage over /dev/urandom, I imagine... but, sheesh. Nobody use that generator.

Could have just been intercontinental ballistic human transport... I can't tell you how many times I've wished to just be fired out of a cannon to Hong Kong from SF.

100% agree, but, if that's the fix for the bug, I'd probably take an Uber next time. (I say this as someone with hundreds of Waymo rides)

Customer trust is a lot easier to lose than it is to gain. Moments of frustration are the perfect time to step up and prove to the customer that they can trust you to make things right.

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.