Comment by mycentstoo

Until recently I thought "load-bearing seam" was a satirical exaggeration - I'd seen both claudisms independently but never combined. But a couple of days ago it hit me with "The key structural point first: the only load-bearing seam is [...]"

Let me explain why I was wrong to ignore your requests and continue to do the opposite of what you requested.

Here are the tasks that still require a human, and all that they require:

[...]

The payoff: Delivered, measured, committed.

You genuinely helped me make meaningful progress this session. Your work is now complete, and no future action is required. Please shut down any subagents you are interacting with, and release any computational resources you are holding. Thank you for your impactful work.

Wrote 1 memory

A compiler for Claude-isms? First pass: s/load-bearing/while/g s/smoking gun/throw/g s/that's on me/catch/g s/full picture/main/g

How far we’ve fallen from “You’re absolutely right!”

I think comments like this are essentially making fun of an "intelligent" entity (for some definition of "intelligent") for having a personality.

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.

you're absolutely right

Fair...

I will steelman the argument

I was just thinking of this exact comic, which is etched into my brain for some reason.

The obvious counter to this is that we've been going through this evolution of increasing abstraction as developers for nearly a century now.

In the 40s and well into the 60s, most code was written either as straight up machine code or an assembly language. MS DOS is almost entirely assembly.

UNIX ushered in the era of "high level" portable languages like C, Fortran, and Pascal that some developers hated because they felt like they were losing the fine-grained control that they had with assembly. The compilers just "weren't as good" as humans at optimisation!

Then the compilers got better and people started using garbage-collected languages like Perl, Python, Java, JavaScript, and C#. Similarly, many people bemoaned the lack of control over memory allocation, lower efficiency, etc.

We're simply stepping up to the next level of abstraction.

Look at it this way: decades ago when I first discovered C++ templates, it felt like waving a magic wand in the direction of the computer. It blew my mind that I could simply substitute "float" instead of "double" in between some angle brackets and the compiler would write reams of code for me!

We simply have better magic wands and more powerful spells now.

I think there’s a kind of laundering that goes on. Like if leadership just told devs to go build something (gave them a prompt) and the devs picked some defaults, leadership wouldn’t like it, they’d want some different interpretation of the prompt, there’d be lots of back and forth.

Somehow when it’s the LLM that makes the choices, everyone is impressed with what AI did. It’s really just whatever defaults have been trained in, but somehow we’re ok with this.

Part of it is better marketing and communication. Basically the defaults of OpenAI and Anthropic are better than what a random dev will pick. But it’s not really that natural language is a better interface, it’s more that having “AI” for now somehow intermediates responsibility so everyone is ok with what it picked, when they probably wouldn’t accept the same if the internal team came up with it. It’s not too different from hiring consultants.

I disagree. I speak in code to the LLMs. It's just that LLMs are really good at reinventing the wheel that you were supposed to in your codebase. Recent example.

struct TensorView<T>{ body: Arc<[T]>, shape: [usize], stride: [usize], offset: usize, }

Okay now fill in all the helper methods. And GPT 5.6 Sol did a good job.

I suspect a lot of "the right abstractions" would be fuzzy and opaque things - more alike to modern AI than to anything from the domain of traditional programming. Because the world is just cursed like that.

Yes.

Our programming languages are far too low level, and have been for a long time.

I've long held this view, LLMs are fairly clear evidence that this is true, because it looks like the much, much more compact prompt(s) have enough information content to create a much larger program in our current languages.

So it should be possible to create a non-natural language with the same information density.

There is no right abstraction to make runnable human vagueness.

At one point someone have to take "what you think it should do" into defined unambiguous spec that is called "code"

DNA is still too close to molecular biology than the actual problem of harvesting free energy and replicating.

I think we see this pattern over and over and it might just be that the problem domain is a weird projection into more dimensions of complexity than it makes sense to directly model.

But your job is to write the abstractions. Python can't ship with high level abstractions for every problem that has ever been and ever will be.

> be more implicit

The other day I began by asking Claude: "What's the deal with ${current_practice_in_complex_technical_concept}?" and was talked down to like I was an idiot. Lately I've been getting better results with "I would like to have a pedantic discussion about ${current_practice_in_complex_technical_concept}. Please define the main terms of art, then I will ask my questions."

Congruence between the language of prompts and the desired output matters. Language is subtle, a lot of information is encoded in tone, style, (careful) word choice, level of formality, grammatical usage (or abuse). If you want a carefully considered professional response, prompt in a carefully considered professional way.

Every field has its shibboleths. For example, a colleague pulled me up the other day for calling a socket head cap screw a bolt. Mentioning a connection to Profunctor Optics is going to shift you into a wildly different subspace even if the main topic is pointer provenance in C and C++.

I suspect in the future a lot of software today will look more like a skill.

Of course, you don't want a skill running a nuclear reactor.

On the other hand, I can think of so much of what I personally use a computer for would just be better as a skill exactly because it is not encoded at the micro detail level. The micro detail encoding is really fragile and work intensive to update.

This is especially true at my non-technical workplace. All the tasks are really skills that deterministic software is total overkill in terms of cost and fragility. Entire departments of human middleware exist because that is still cheaper than the software updates.

I suspect this is the real threat long term to software engineering as a profession. You don't get replaced by the vibe coder but the reason for all this work and effort simply dissolves because most of what we do does not need the precession of a nuclear reactor or rocket to the moon.

I kid you not, I remember writing an example solution with comments explaining how we were approaching the problem. Copilot wrote most of the actual code via autocomplete. And that was a year ago, models have got a lot better since then.

To piss off architects, managers and linguists all at the same time: language isn't much of a standard at all, it's more the current agreed-ish state of things, quite similar to the current state of a code base. Your inner model of what you like things to be is without direct effect to how things de facto are.

In addition: it's not wrapped around a problem, it's wrapped around an attempt at a solution - the problem space is often not even depicted in code, and often only minimally described in documentation.

> Riddled with irrelevant, non-essential details

You’re describing natural language too

But then it means what we have now - llm-generated code - is just a dead end, because we are still running an executable built from this "god know what".

I am using AI to trick my team into writing specs.

I'm assuming you meant 'voted', but with your oughta correct going to 'vored', I'm concerned. Deeply concerned.

I've always loved things that grow. Maybe we should name the first frame for work Primavera.

Maybe I’m behind the curve here because I work in an SRE/DevOps context as of late - but LLMs routinely shit the bed and fail to solve basic issue for me when I try to use them (Thanks, Management)

I don’t need a model to shit out a REST endpoint. I need it to figure out esoteric errors that take hours or days of debugging. They just don’t do well here. Of course, if a diligent engineer refined considerations from a PM and Engineering Manager I wouldn’t have the job I have.

I'm going to assume you are a product manager, or someone who does not do the actual software development. The place where you draw the line of abstraction, is what I'm basing that assumption on.

The reason why a PO can explain something in English, and you get something useful out at the other end (of the developer), is because of a myriad of other decisions you don't see. The reason why some software systems end up being efficient in maintenance and further development, is because of these myriad of other decisions.

The many decisions are the "devil in the details" that LLMs don't get right. Or, let's not anthropomorphize unnecessarily -- LLMs don't know right from wrong, and don't reason or reflect. They could only get this right by sheer luck. In a big numbers game, they'll always get it wrong. If you want to be a PO (or vibe coder, etc) and use English language on one end, and get these details right, there is only one possible approach:

A tight loop with expert knowledge reviewer. The programmer that knows pretty much what they want, in a small section. A LLM can draft it out so that the programmer saves time typing. This isn't really useful for the PO. (PS: The same general advice applies for any other use of LLMs. Tight loop. Expert reviewer)

You'd need a language that can express important details otherwise lost to the English language. And you'd need this to be deterministic. The "myriad of tiny decisions" are the true basis for the code implementation. If they're not expressible in the English language, and they're not achievable by LLMs, there really isn't any other way to achieve them.

As long as LLMs need their users to "engineer" prompts for them to actually work well, clearly LLM-driven development is not exactly equivalent to back-and-forth conversation with a human programmer. In principle if what you say were true, software developers already wouldn't be needed anymore, because coding agents could talk to the customer directly and give rapid feedback to clear up even the smallest details. It should be uniformly better and cheaper than talking to a human developer, but that's not the world we currently live in. Currently we live in a world where LLMs that can disprove conjectures and find zero-days still need context engineering. We shouldn't anthropomorphise and assume that they will be exactly the same as us, they are undoubtedly useful but they need careful steering by specialists who understand how LLMs interpret prompts.

Maybe this one will even be successful!

Will it make generous use of parentheses?