I find it disconcerting that an article about cognitive debt contains many "tells" of being written by AI.

Independent of that, the article is just a summary of a HN thread...

I had the same reaction, but the article is not AI-generated according to pangram, which I've generally found reliable. I wonder if LLM turns of phrase and even thought patterns are creeping into normal human thought.

Or, stay with me here, the LLMs were trained on how we, statistically, write.

There are typical LLM voices and styles, just like human writers have differentiated voices and styles. And some common elements of the typical LLM style are distinct from humans I've previously read.

I recognize this. It's also the case that I suspect that I've read more about how annoying suspected LLM output is to read than I have read LLM output. The slop is, to me, an incredibly unwelcome contribution of humans that don't enjoy the craft but complaining about it is equally stuck in and further exacerbating the froth rather than distilling down to the substance. That is it keeps the focus on the surface rather than on what the core content is and whether it has value.

LLM writing doesn’t have substance, it’s statistically likely text generated from some bullet points, without intention or style.

Anytime I see “this is not just x, it’s y” i can almost guarantee with high degree of confidence that slop was used.

As someone from outside the Anglophone cultural sphere, when I first learned to write in English, the kind of writing that AI now often produces was taught to me as “formal" writing.

But these days, when I write in that formal style, people sometimes say it sounds like AI. That has been a difficult and frustrating point for me.

I still find the subtle difference hard to understand.

I was raised and educated well inside the Anglosphere (USA) and was also taught to write formally in that way.

Do the people who say you sound like AI give you any specifics?

Also, if you don't mind, what was your English education like? I understand that quite a few Americans work in South Korea as teachers but I have no details about how that manifests.

That used to happen to me more often. When I first came to HN, and even now if I am not careful, my comments can get flagged. Also, when I translate from Korean using DeepL and paste the result, people often say it sounds flagged, awkward, or unnatural. I studied English more seriously in graduate school, although I dropped out. In Korea, there are quite a few Americans who teach English. Public schools often have native English-speaking instructors, but in my case I learned English more seriously at graduate school, and universities also make students study English almost semi-compulsorily.

In Seoul, there are probably many teachers who mainly teach middle and high school students, but a lot of that is through private education rather than the public school system.

I'm still pissed that I had to practice removing that from my writing habits. I liked that device, dammit!

It's not just AI-generated, it's also slop!

When you say "we" you're talking about Twitter, right?

I used that once, during a conference about 6 years ago and never again since. My use of "we" references humanity.

In that case, I feel that "we" needs some correction. Because these slopcannons get their ammunition from scraping the gargantuan septic tanks of the Internet, like Twitter and Facebook and whatever 600M Chinese people are using that I've never heard of.

Comparatively very little of that "humanity" corpus is coming from Shakespeare or Swift or Douglas Adams, much as we might prefer if it did.

I never claimed it was trained on the notables of humanity. On the other hand, to your adjacent point (to twist it) that humanity needs some correction, I whole heartedly agree.

It's worth mentioning pangram is more confident in it's positive detections than it's negative ones, as stated by the founder in an interview on the most recent ThursdAI episode

I think its bidirectional. We change our writing based on what we see (AI generated content on the internet) and AI will learn based on what we write.

Guarantee enterprises with SLAs aren't accepting them

The thing about an SLA is that once you’ve broken it you’ve lost the trust. It doesn’t _really_ matter what the cost is for breaking it, nobody chooses their platform based on the refund they’ll get if they’re down. But they absolutely do choose based on reliability and uptime. The enterprise SLA refund credit will show as a (big) metering blip, but the problem is the people who signed the contracts are going to be speaking to Gitlab now

I wonder about the nuance within the data. Like does AI do much worse with children than adults, but still better overall for example. Or biological male vs female. I think we'd want it to do better across all groups, ages etc so we're not introducing some kind of horrible bias resulting in deaths or serious health consequences for some groups

True. But this makes it easier to stand out in a sea of monotony.

It's not, but the author did say they have used this test against models when they come out. So it's possible that put the unpublished text into the training data for the next model, somehow linked back to the author's identity

> The obsession with the word "seam" as it pertains to coding

I quite liked this term when it started using it. And I appreciate the consistent way it talks about coding work even when working on radically different stacks and codebases

"Seam" has been stretched by AI from its original legacy-code context to any point in code where something can be plugged in. I actually asked an AI about this a few weeks ago because I was surprised by the consistent, frequent use of "seam".

Frequent words I see from GPT: "shape", "seam", "lane", "gate" (especially as verb), "clean", "honest", "land", "wire", "handoff", "surface" (noun), "(un)bounded", "semantics" (but this one is fair enough), and sometimes "unlock"

It feels like AI really likes to pick the shortest ways to express ideas even if they aren't the most common, which I suppose would make sense if that's actually what's happening.

This has happened in other industries before. Drafting for example when CAD arrived. Entry level wasn't "can draw, willing to learn" anymore, but demanded high domain understanding. So the pathway became compressed learning through study, and field exposure.

Study of senior drafter "red lines": what and why they changed the initial drawing, RFI response etc. Reverse engineering good work. Failed design studies etc.

SWE equivalents: PRs, code review, studying high quality codebases (guess what: LLMs are amazing at helping here), pair programming (learning why what the LLM did was wrong, how to improve it, etc), customer support, debugging prod incidents, studying post mortems etc

We don't hire juniors and throw them boilerplate and tiny bugs while expecting them to learn along the way ad hoc through some pair programming and the occasional deep end. We give them specific tasks and studies that develop their domain understanding and taste, actively support and mentor them, and expect them to drive some LLMs on the side to solve simple issues that still need human eyes on it.

> We don't hire juniors and throw them boilerplate and tiny bugs while expecting them to learn along the way ad hoc through some pair programming and the occasional deep end.

Is that generally the case though? I'm about two years into my first job in the industry and that's exactly my experience, and certainly frustrating...

>We don't hire juniors and throw them boilerplate and tiny bugs while expecting them to learn along the way ad hoc

Huh? This is exactly what almost everyone does

He didn't say that though. He said many species are living quite happily, but nature has also changed, sometimes for the worse

> Writing detailed specs and then giving them to an AI is not the optimal way to work with AI. > That's vibecoding with an extra documentation step.

Read uncharitably, yeah. But you're making a big assumption that the writing of spec wasn't driven by the developer, checked by developer, adjusted by developer. Rewritten when incorrect, etc.

> You can still make the decisions, call the shots

One way to do this is to do the thinking yourself, tell it what you want it to do specifically and... get it to write a spec. You get to read what it thinks it needs to do, and then adjust or rewrite parts manually before handing off to an agent to implement. It depends on task size of course - if small or simple enough, no spec necessary.

It's a common pattern to hand off to a good instruction following model - and a fast one if possible. Gemini 3 Flash is very good at following a decent spec for example. But Sonnet is also fine.

> Stop trying to use it as all-or-nothing

Agree. Some things just aren't worth chasing at the moment. For example, in native mobile app development, it's still almost impossible to get accurate idiomatic UI that makes use of native components properly and adheres to HIG etc

this is my workflow, converse with it to write a spec. I'm reviewing the spec myself. Ask it to trace out how it would implement it. I know the codebase because it was originally written mostly by hand. Correct it with my best practices. Have it challenge my assumptions and read the code to do so. then it s usually good enough to go on it's on. the beauty of having a well defined spec is that once it's done, I can have another agent review it and it generates good feedback if it deviates from the spec at all.

I'm unsure if this is actually faster than me writing it myself, but it certainly expends less mental energy for me personally.

The real gains I'm getting are with debugging prod systems, where normally I would have to touch five different interfaces to track down an issue, I've just encompassed it all within an mcp and direct my agent on the debugging steps(check these logs, check this in the db, etc)

Experienced engineers that know the codebase and system well, and with enough time to consider the problem properly would likely consider this case.

But if we're vibing... This is the kind of bug that should make it back into a review agent/skill's instructions in a more generic format. Essentially if something is done to the message history, check there tests that subsequent turns work as expected.

But yeah, you'd have to piss off a bunch of users in prod first to discover the blind spot.