I've renovated houses (and I have a bad habit of buying 100 year old hacked up chaos-boxes - my current house was moved from one hill in San Francisco to another 80 years ago, so it's a puzzle box), so yes, I've been using "load-bearing" as a shorthand for decades, reduced to be less jargon-y by adopting "structurally essential" for increasingly international team composition, where English is a second or third language.
However, I've been hearing "load-bearing" at least two orders of magnitude more often over the last few months, particularly after uncorking Claude Code for the team.
I don't think it's a dead give-away of AI usage, and I don't think AI usage is a problem. I just think we can introduce phrases into common use by having them be used by common tools. So let's train the models on obscure/archaic terms and see what happens. Heck, we can just prompt it...
I have heard so many of my co-workers use "load-bearing" over the last couple of months. It's truly comical. Maybe this is a way that we can make "fetch" happen.
I don't think it is. It's really easy to get a persistent, clever, hacky model to dial that down a bit and just come back to chat before stomping off into the woods.
If a model couldn't ever do that in the first place, it'll just get stuck.
I work in the "ZeroOne" space, working on concepts and prototypes for things that don't exist in market yet. Sometimes these models crank hard and immolate tokens while grounding themselves on expensive-to-ingest self-developed frameworks. If the results are well judged and the crank-turn latency is low, I'm okay with the cost as long as the model isn't wasting my time.
But when I want to do more boilerplate work, I turn down the model and thinking level and get more traditional about restraining action. For the really hard stuff, I reach for the models that will start a token bonfire in the back yard.
(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.
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.
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.
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.
- 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.
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.
However, I've been hearing "load-bearing" at least two orders of magnitude more often over the last few months, particularly after uncorking Claude Code for the team.
I don't think it's a dead give-away of AI usage, and I don't think AI usage is a problem. I just think we can introduce phrases into common use by having them be used by common tools. So let's train the models on obscure/archaic terms and see what happens. Heck, we can just prompt it...