The West forgot how to make things, now it’s forgetting how to code

The problem is, in the minds of these people 'firing at 100% all the time' generally means doing busywork and/or thinking of ways to cheat/manipulate their customers and the market for maximum gain whole delivering minimum value. I would have loved to be 100% engaged working on solving real problems in honest ways at some of my past jobs, but alas MBA/marketing leadership, which has taken over much of tech has very little interest in actually building good things and solving real problems in honest ways.

I think the bean counters get a bad rap for this a bit unfairly. The past century has seen more progress in knowledge and technology than the rest of human history combined. The world and business environment are changing too rapidly to make longtermist thinking practical.

Few care if you have a lifetime warranty and excellent service or replacement parts if the majority will upgrade in a few years! Mature technologies increasingly become cheaply available as services, eg. laundry, food, transportation. That further reduces demand on production, as many can get by with the bare minimum and don't need the highest quality, longest lasting appliances. Software is even more ephemeral and specialized.

Developing education and training pipelines is wasting money if the skills you need are constantly changing! There is plenty of "slack" in the workforce so this works just fine in most cases - somebody will learn what they need to get paid. There are very few fields where qualified worker shortages are a real problem.

R&D can be outsourced or bought and subsidized by the government in universities, so why do everything yourself? Open source software has even further muddied the waters. Applications have only a limited lifetime before being replicated and becoming free products (this has only been intensified by the introduction of AI), so companies develop services instead.

Technology and knowledge deepening and rapidly becoming more specialized makes the monolithic corporation much less practical, so companies also need to specialize in order to effectively compete. Going too far in the name of efficiency can destroy core competencies, but moving away from the old model was necessary and rational.

I’ll note at the end of the last century I worked at IBM research which had a budget of 6 Billion dollars. Management was trying very hard to get better return on that investment. Even today IBM though often ridiculed in the tech space (sometimes they do deserve it) spends a lot on R&D.

> Which in turn means, in their mind, every part of the system needs to be firing at 100% all the time

Not just that, you have to be always doing less for more gains. Real work is bad work. Shrinkflation good. I don't know what it is if it wasn't a pure scammer mindset.

> When bean-counters took over the ecosystem [...] in their mind, every part of the system needs to be firing at 100% all the time.

This is only fair, because they themselves are firing at 100% all the time IYKWIM ;)

I believe private equity ownership represents this in an aggressive form. The 2 and 20 percent takes that PE usually mandates as part of their purchase agreement means that they are highly highly incentivized to maximize short term "wins" over long term survival.

I think Chesterton and Taleb also had pretty reasonable things to say about understanding a system before you make changes and fragile/anti-fragile systems as well.

I haven't read this book but I see it often mentionedin contexts like this. it was written in 2001 and I think its synopsis still stands.

Slack by Tom Demarco (2001)

https://www.goodreads.com/book/show/123715.Slack

It’s especially ironic since the bean counters produce no value. I like ‘Developer Hegemony’, even if the title needs changing. The author makes a great case for why information workers produce almost all the value. It’s them that make the profits, yet they’re always a cost center.

> If there were known "make more software, make more money" opportunities available, they would have already done them.

Sometimes they're available, but not palatable, when the opportunity could threaten their existing investments or patterns. That might mean "self-cannibalism", or changing the ecology so that the main product niche is threatened.

Then those opportunities are ignored, or actively worked-against via lobbying, embrace-extend-extinguish, etc.

> doesn't generate any for later.

"any" is quite an assumption.

I agree that any sufficiently complex human operation - whether industrial or scientific or whatever - requires a culture and a living tradition that develops over time and communicates knowledge and understanding across generations. In fact, many problems in our culture can be attributed to a contempt for tradition that developed. (It is true that tradition can ossify. That's can be a problem with attitudes toward tradition rather than tradition itself, or a sign that something needs to be addressed. A good tradition is a dialogue spanning history.)

However, it is also true that technology develops and produces changes that in the short term cause pain, but in the long term produce a better outcome in some desirable sense. Coding is not an end in itself. Just as switchboard operators and human computers are obsolete, because the conditions that caused the need for them ceased to exist, it may be the case that a certain manual style of programming is also becoming obsolete.

You can imagine human computers decades ago thinking that computing technology is bad, because people will loose numerical facility. But this misunderstands the structure of the value of practical skills and the difference between knowledge of principles and practical skill. Sure, few if any people today can perform numerical computation as quickly and competently in their heads or on paper as human computers, but...

1. that's different from understanding the principles of computation which is closer to a theoretical grasp and has eternal or at least lasting value

2. the value of the practical numerical facility was rooted in the need for obtaining results as quickly as possible, and that particular set of techniques or skills is no longer practical

Perhaps manual coding is like that. I don't know why people are surprised. Generative programming has always been a desired end in CS for along time. CS grads can still and should still learn the principles of their field and learn them well, but the profile of practical industrial techniques and needed skills is changing. As software eats more and more of the world, it is becoming increasingly impractical for manually fiddling with silly bits of plumbing. We obviously haven't been able to develop abstractions well enough to avoid it, and part of the reason is that appetite comes with eating. Once you make something easier, it makes it easier to achieve even greater things more easily...hence new plumbing and implementation complexity.

Let's be honest here. Much of programming is intellectually dull. It's is plumbing. It's not algorithmically interesting. It's not interesting from a modeling perspective. It's not interesting conceptually. It's not interesting as a matter of system design. Most programming out in the wild is the same old crap being recapitulated a million times over. If all you want is to become skilled in doing the same thing over and over again, then I can understand why you might find LLMs threatening. Your market value as a maker of yet-another-flask-web-app has plummeted hard. People who enjoy that kind of programming are generally not very intellectually motivated people - at least not where programming is concerned - and likely prefer the tedious comforts of rehearsed ephemeral detail. LLMs can keep us from rabbit holing and focused on the domain.

In any case, I don't think LLMs are a threat to the field per se. I just think that the skill set is shifting and developing. I think we are still figuring out what it means to develop the right understanding and intuitions to develop software without the benefit of having had done it manually. Time will tell. However, I also think being able to read code has become relatively more important than writing it. When you have to verify the quality of LLM-generated code and put your name behind it, you have to be able to understand it, and that's a somewhat neglected skill in my view. Programming very often prefer to write code than to read it. LLMs might be just the thing to coerce an improvement in the latter sort of literacy. With this also comes a greater importance of formal specification. That's where I would expect the future of the field to shift.

The deeper I wade through Microsoft’s Azure documentation the more I feel the reality of this. There’s so much of it that it basically is unreadable in real terms, most employees will never get the time allocated, and when you do try to exhaustively read up on a specific area you find that the documentation is incomplete and wrong in subtle but important ways. I’m sure Microsoft spends a lot of resources on that documentation, but it seems somewhat of a hopeless mission.

There are certain things that are too obvious to some person at a given time. Hence they would not consider it's worth documenting. Some of those things are important bits and pieces of the theory[1] of the program.

[1] https://pages.cs.wisc.edu/~remzi/Naur.pdf

I think it's an important property of a system to be documentable not just documented. What I mean essentially, is the system was designed with sound principles, and said principles were written down and followed.

I have seen this work only once in my life, and it was so nice to see, but yeah, most code is just a ball of twine, and even if there was a guiding principle beneath, it has been long abandoned, and overruled, and the only way to understand the system is to take it all in at once.

This is such a weird counter-argument, that only serves to prove OP’s point.

“It’s not that it’s not documentable. It’s just that it would take tens of thousands of pages and no one would be able to write that or read that to effectively take over the project.”

Okay, so surely this is what OP had in mind when they said documentation doesn’t work… Is it no longer safe to assume reasonable expectations when making an argument? Why the need to “well actually” them with this response?

Documentation should serve as a general overview of the system (purpose, architecture, etc.), and elaborate on the interface of that system. Other than documenting historical relics like ADRs, I see it as a net negative in being very granular.

It quickly becomes outdated and at some point you just need to accept that only the code will be the most accurate source of truth.

<< [belief that] knowledge can be replaced with documentation, tools, and processes. [It] cannot. << volume of documentation that I would have to write would be insane

I am not sure those are mutually exclusive. We all know if situations where a person knows of tiny and typically undocumented system quirks. We even have a corporate name for it: institutional knowledge. The issue is that executives think it can ALL somehow be done, when even cursory real life project lift will quickly teach one how insane average gap between documented and undocumented tends to be. Add to that near constant changes to API, versions, systems, people and I can't help but wonder at executives, who really do think this way.

But you've just perfectly described the tacit knowledge problem.

Yes, you can spend all your time writing docs, or just mentor a junior and let them grok the system through osmosis.

Also your doc won't ever have 100% coverage unless you write an absolute tome. Tacit knowledge are things that are so obvious that you wouldnt even think of writing it down in the first place.

It’s way easier (for this type of scenarios) and far more effective to learn by doing than to learn by reading (even tens of thousands of pages of) documentation, that is the crust of it.

We see this in our open-source community. We've had a community channel for over two decades, where community members help newcomers and each other solve problems and answer questions.

Increasingly we have people join who tell us they've been struggling with a problem "for days". Per routine, we ask for their configuration, and it turns out they've been asking ChatGPT, Claude or some other LLM for assistance and their configuration is a total mess.

Something about this feels really broken, when a channel full of domain experts are willing to lend a hand (within reason) for free. But instead, people increasingly turn to the machines which are well-known to hallucinate. They just don't think it will hallucinate for them.

In fact I see this pattern a lot. People use LLMs for stuff within their domain of expertise, or just ask them questions about washing cars, and they laugh at how incompetent and illogical they are. Then, hours later, they will happily query ChatGPT for mortgage advice, or whatever. If they don't have the knowledge to verify it themselves then they seem more willing to believe it is accurate, where in fact they should be even more careful.

People are losing their ability to reason without prompting an LLM first.

It's affecting their ability to collaborate. They retain the confidence of years of experience, but their brain isn't going through the appropriate process anymore to check their assumptions.

I've seen a similar thing happen to engineers who move into management, but this is now happening at such a large scale.

> if I’m asking the AI a question, that’s replacing a human interaction I would have had with a coworker.

Importantly, you're removing a signal: If I'm not asked things anymore, I don't know which aspects of our domain are causing the most confusion/misunderstandings and would as such benefit most from simplifying the boundaries of.

There is a lot of wisdom in this.

At the end of the day chatgpt won't be there to hold our hands in the hospital, have a laugh over failing to pick up a date, get invited to a bbq, groan over the state of the code in utils.c, or recommend us for our next job/promotion. They say software is social for a different reason than most of these examples.

It's good to be efficient, whatever that means, but there are no metrics on the gains that get made by talking to people. In a lot of ways those gains are what life is about.

I think you are right, but it also makes sense. Human communication is inherently inefficient. Points of view, miscommunication, interpretation... It's the obvious point to automate. Not defending it, just my thoughts

You could have done this with Google search or Wikipedia or reading through books though

I am rereading the Asimov robot novels. A decrease in human to human interaction is a major side effect that he has foreseen. Decreasing interaction and collaboration are some of the core themes.

> In the west, government is optimizing for "loads and loads of moooney"

More appropriately, government is optimizing for 4 year electoral terms. No one cares about longer timescales necessary to tackle hard problems.

This is where autocracies like China, or monarchies for example, win over democracies.

I always think that’s the failure of citizens, not just the officials. Eventually history is going to blame us for not taking action, not pushing back, and pretty much sleep tightly when things fall apart around us.

Perhaps US companies should invest more in their employees then? Advancement, promotions beyond %1-3% COLAs, career paths, etc would go along way to keep employees interested in seeing their employers succeed instead of jumping ship every couple of years. The would require some effort from the C-suite however and since they jump ship every few years as well, I don't see that changing anytime soon.

> Most MBAs are taught to optimize and reduce the slack.

With a myopic definition of "optimize". But as long as they are being rewarded for it, the incentives are broken.

> Why would anyone have a sight longer than a quarter? I mean how does long term thinking help the execs get their compensation this quarter?

Vesting schedules, conditional grants, contractual equity ownership requirements

> ...any actual product RD and support is a real annoying cost that just cuts into the profits...

Worse, it might not generate a return. If you have enough profits, you just buy anyone who successfully produced something innovative. Let them take the risks. As Cisco used to say, "Silicon Valley is our R&D lab."

It is a very difficult mindset to argue against.

Would be interesting to get a law that says that all positions supposed to take long-term decision should be paid with X% of their salary in (non-redeemable until Y years?) stocks.

I'm biased, but I think you're on to something. People are writing about this under the broad framing of "cognitive surrender"

Agree with you for my day job (which is coding corporate web app), for sure. I'm still letting A.I. drive more nowadays, but it does feel less fulfilling than it used to.

But for my personal projects, I work on games, and by offloading a lot of the coding work to A.I., my puzzle solving is no longer 'how to fix this stupid library spitting stupid errors at me' or 'how to get this shader working' or 'why is this upgrade breaking all the things' and more 'what does this game need in order to be fun and good?', which I find a lot more fulfilling.

It's also why I switched my focus to board game design for the longest time. I didn't have to fight my tools or learn some new api or library frequently. And if I wanted to try a new mechanic, I didn't need to spend 20 minutes or 2 hours or 2 days implementing it, I could write something on an index card in five seconds and shift mid-game most of the time.

A.I. just brought video games closer to that experience, which actually has made them more fun to work on again, because board games has the immense (financial/logistical if self-publishing or social/networking if attempting to get published through a publisher) challenge of getting physical games published to worry about.

I find this interesting as someone who does primarily devops, my satisfaction has increased with ai. Since for me the code isn't the puzzle but an annoying inconvenience in the way of completing the entire system. For me QA is a big part of solving the puzzle.

why I agree with both of you?

>I'm the opposite I don't think I've read a single line of code I've shipped in over 6 months.

This feels unfair to the people dealing with your (LLM’s) code. You don’t vet it at all? Or am I reading this wrong?

At work we are literally forced to use AI and it’s part of our performance review. Even though I really like coding by hand, I have to now use AI so I can keep my job. I will try this out though, 2 days per week using AI and the rest handcoding, enough to stave off the inevitable lay off perhaps.

There is a difference between understanding the shape of a solution and keeping the "finger memory" of a language alive

Who is the 'we' here? When did I become ok with LLMs writing code end to end or against LLMs being used to assist writers? I wasn't aware I held either of these positions.

That's because the purpose of code is to be used, not to be read.

The only purpose of the written word is to be read.

The purpose of writing is to get your thoughts across in words. A prompt sufficient enough to get out an article with zero chance of it adding things you don't mean has to contain as much information as the article itself would. Just write the article.

> I do not see the difference between writing code and writing prose.

That’s the problem.

This is a funny point. People don't want to read LLM code either, so who knows where that puts us.

Since I cannot edit my comment, I replied my comment. I did not mean to insult HN moderators. I am actually very happy that they are protecting HN by removing and flagging AI content. I only wanted to attract attention to the topic that for some areas AI is promoted but then for some areas AI is demoted and I do not get it.

What I mean with "we" is that there is a general perception that using AI is okay and mandatory. This idea is becoming more and more prevalent in management positions and it disturbs me deeply.

I got some replies since I commented, but I am still in the same mind. I did not see a strong refutation to my idea. Why are some people (I didn't want to use the word "we" again) are okay with AI use in code but not in prose? I know that they are not exactly same but they have some similarities. If we are unhappy with sloppy prose, why are we happy with sloppy, potentially buggy or hard to maintain code?

I would say that the simple reason is that writing is often artistic and coding very rarely is.

I don’t listen to AI music or watch AI videos, I don’t want to read AI articles

It is full of these short sentences that AI writing loves, sort of to feel "punchy". Normally you would copy-edit that stuff, join them up, have the writing have some rhythm. I agree with GP, the article is hard to read because it seems to have a lot of https://tropes.fyi/

On the other hand articles mistakes (missing the, a or wrong the). So it'z not AI translated, but also not fully AI generated...

The advantage of Bored Ape NFTs is that one could very quickly visually identify one and block or scroll past without much thought. On the other hand, reading AI slop takes a few extra cycles to parse out and categorise appropriately, with the occasional false evaluations and second guesses. It will be a fine day, indeed, when this pattern of writing fucks off forever.

Even the title is likely AI-generated, as are all the subject headings. I worry we're all getting inured to these writing patterns.

I'd color this a little. I think there's also an engineering mindset some people have, and some don't. And over 10 years in, I'm still not sure if it can be trained or not. Some people are just really good at seeing the technical solutions in terms of engineering: Where does the data live, where does it go. How does it get there, how does it change. How does it break, how will we know, how will we fix it, how will we cope with its shortcomings. All of those questions to some people are a relatively quick and intuitive part of scoping and design. And for others its like a constant cliff they run into midway through their projects, or worse (and far more common) a set of bugs that are "tech debt" (for someone else to inherit) as the slap the "Mission Accomplished" on yet another project.

I've seen people that are very proactive and generally fall into your former group, but also don't quite seem to think like an engineer. I really want it to be trainable - I am trying - but IDK if it is or not.

>It's almost impossible to turn someone from the latter group into the former.

Only if you're constrained by the same short-term thinking as US businesses. The way to do that is more of an apprenticeship model when someone observes/works closely with someone from the first group over years.

Even then, the businesses don't want to pay for that, and why should the workers give that away for free? They want people to churn out code because they've chosen to hire micromanagers that need constant updates and babysitting through communication.

I highly agree. Let us stop talking about software dev and look behind the curtain a bit...

I want to point at the discouraging framing of developers who learn to be helpless whenever they are stuck in an organization for long enough where they start to believe they cannot do better and there is something that cannot be changed.

The majority of people I met started out in the former group but have been reshaped by the environment they are in.

If you are in the former group and find yourself turning into someone from the latter group, becoming unrecognizable to your past self, ask yourself if you have been reshaped by the organizational experience you were having and where that spark went.

The chance is very high the organization figured out how to keep you in your position or you have internalized things about your professional self at face value that do not depict reality outside the org and that start to affect deeper layers like your confidence and outlook.

You start to identify with the made up labels or arbitrary hurdles of reaching some next level that will change everything. Essentially you are in a box and you developed tunnel vision, could be dept, org, branch or industry wide.

Just bash your head against a project away from work for 3 months on the side and gauge for yourself how capable you are with no economic intention disregarding time and value investments and so on. Repeat this long enough to fill any gaps in knowledge you encounter and at some threshold the coin flips again.

You will do DevOps but you are no DevOps guy, you do Frontend but you are no Frontend guy. Just a free flowing human walking through the layers that create something real.

There is an art in unplugging yourself from economics and thinking in organizational hierarchies and patterns and I think if most of us see it for what it is, software would turn into a calmer place, grounded closer in reality.

> There's the kind that, when given a problem, will jump in, learn what they need to learn to solve the parts they don't fully understand yet, deliver meaningful iterative results, talk to people as needed, keep you posted on their progress, loop in other team members and offer/request help to/from them, take initiative on the obvious missing parts that would benefit the project as a whole, etc.

I would rather tweak that a bit and say, we need a kind that has two things: 1. aptitude - not genius or 10x something just plain being able to think clearly and having problem solving skills 2. care i.e. not just dump whatever hack works in the short-term and declare victory. It doesn't imply that you obsess over perfection and ignore deadlines etc. But basic care about the solution being sensible, good code quality and not causing a new set of problem due to shortcuts. Both are things we routinely expect from programmers and I see less and less of them. #2 is rarer than #1.

> There's the kind that, when given a problem, will jump in, learn what they need to learn to solve the parts they don't fully understand yet, deliver meaningful iterative results, talk to people as needed, keep you posted on their progress, loop in other team members and offer/request help to/from them, take initiative on the obvious missing parts that would benefit the project as a whole, etc

You're framing this person as a good developer, and sure. Probably some people who behave like this are good. MANY people who are like this leave mountains of problems in their wake. It takes a very special person to be able to build good quality with this kind of approach.

You're basically taking about someone getting the right answer on the fly at full speed

It's much more likely to get a subtly wrong answer, which is then dropped on that second group to manage and maintain going forward, while the fast moving person is hurried along to go drop a subtly wrong solution on another project with another team. This has happened to me many times in my career

Thank you for this.

> That's unfortunately human nature, we are not capable to learn and internalize things simply from reading or watching others do it, we absolutely need to do it ourselves to truly learn.

That is, and has always been, true. Currently, however, the narrative that is sold (and unfortunately accepted by so many of the senior developers who post here) is that the experience of telling someone else to do something is just as valuable.

I've never worked in a corporate environment beyond client projects.

Picked up a book on XHTML (no, that isn't a typo) and CSS in 2007, just kept trying to build stuff I wanted to build and backfilling knowledge as I went. Not only is it possible, it's preferred. ~20 years in and I've learned how to build my own full-stack JS framework, deployment infra, a CSS framework, and an embedded database to boot.

Not one drop of this would have been possible had I taken the traditional corporate track.

Maybe they mean you can be not employed and build products yourself? Technically true, but that's like running your own surgeries or something, you're still doing surgery.

Analogies to other professions give your argument an air of legitimacy, with none.

There’s plenty of people in this world who are expert programmers without following any traditional path.

“Oh yeah, like who”, you say.

Con Kolivas, anaesthetist, work on kernel schedulers including the Staircase Deadline (RSDL) scheduler which was a precursor to the Completely Fair Scheduler in Linux and the Brain Fuck Scheduler and the ck Patchset.

I think I might enjoy it for a little bit and then become very depressed at the idea that it will never end, a future of fixing things that should never have been broken in the first place and which won't stay fixed.

> I find that I can obsessively breathe down the neck of an LLM for far longer than I could ever stay in the traditional flow state.

I can do that too. Most programmers can.

That's because it requires less skill! Critiquing something is always easier than doing it.

I can literally keep an LLM fixing things forever by just saying things like "This is not scalable", or "this is not maintainable", or "this is not flexible" or "this is not robust", ... etc ad nausem.

That doesn't take skill at the level to actually write the software. For the market which is hoping to switch to mostly LLM coding, the prize they are eyeing is skill devaluation and not just, as many think, productivity gains.

They have no reason to double output, but they'd sure love to first halve the people employed, and then halve the salaries of those people (supply/demand + a glut of programmers in the market), and then halve salaries again because almost no skill necessary...

Perhaps you have the psychological make up to thrive in this new environment. Glad it is working for you.

Who really truly enjoys that and doesn't see it as a chore?

I find the real way to review other people's code is to program with it and then I start seeing where the problems are much more clearly. I would do a review and spot nothing important then start working on my own follow-on change and immediately run into issues.

Which is a really, really bad idea.

Most people don't spend nearly enough time going through a code review. They certainly don't think as hard as needed to question the implementation or come up with all the edge cases. It's active vs passive thinking.

I, for one, have found numerous issues in other people's code that makes me wonder, "would they have ever made such a mistake if they hand coded this?"

btw, a side effect is that nobody really understands the codebase. People just leave it to AI to explain what code does. Which is of course helpful for onboarding but concerning for complex issues or long term maintenance.

The problem is the LLMs completely change the equation. Before LLMs, beyond very junior (needs serious coaching) levels, reviewing was typically faster than writing the code that was reviewed. With LLMs, writing code is orders of magnitude faster than reviewing it. We already see open source projects getting buried in LLM slop and you have to find the real human or at least carefully curated contributions among the slop.

I would not be surprised if many open source projects will outright stop taking PRs. I have had the same feeling several times - if I'm communicating with an LLM through the GitHub PR interface, I'd rather just directly talk to an LLM myself.

But ending PRs is going to be painful for acquiring new contributors and training more junior people. Hopefully the tooling will evolve. E.g. I'd love have a system where someone has to open an issue with a plan first and by approving you could give them a 'ticket' to open a single PR for that issue. Though I would be surprised if GitHub and others would create features that are essentially there to rein in Copilot etc.

We humans cannot scan 100’000 articles looking for the golden nugget, the AI data mining can do it and present it in seconds. Obviously we need to verify the data.

A couple of decades ago, we didnt trust compilers, we did assembly manually. Today is same barrier, some developers will explode with productivity while others will be left behind.

Because a lot of engineering is pattern repetition, which is not very fun for engineers either, and LLMs can do it much faster?

> The tropes that AI introduces into articles are very noticeable, quite annoying, and very unnatural -- they unfortunately don't write well.

Quite paradoxical: when its a person's native language we can spot it a mile away but there's no shortage of engineers who claim how good the code output is.

Whatever the reason for the default tone of AI in English, it's still there when generating code. It makes me think that the senior engineers who claim that it produces awesome output just don't understand the specific programming language as a someone who thinks in it almost natively.

People have also started copying the AI tropes, especially your period/comma example.

Unnecessary emphasis can get... quite comical... indeed.

It really feels sometimes like they were trained on too much short-form fiction or something. Really stunts their sentence and paragraph texture.

The uncanny valley is an attractor basin.

The filler from AI articles drives me absolutely bonkers. Im a fast reader in general and can skim through articles to find important details at lightning speed, but it still takes me 5x longer to skim through all the AI fluff than it does to go back and search for a non-ai article and then read through that.

The filler stuff is really a huge waste of time and effort. I tried to Google weather Ranch Corn Nuts are vegan and every result in the top 10 was the same AI generated slop with 10 paragraphs that had nothing to do with what I was trying to find.

All the top results had the same AI feel to them. The same format and structure.

The best part? None of them said yes or not. None of them answered the question. They just listed common dairy and non-vegan ingredients to look out for. So, all that AI and nobody put in the ingredients list. Lol

Many such cases. Both the priest anecdote, and AI-critical posts being AI-generated.

Sort of a taste receptor I’m sure many have developed now.

The most obvious patterns here are: antithesis constructions, words choices and distribution, attempt at profundity in every paragraph but instead are runs of text that doing say anything, and even the perfect use of compound hyphenation. I think and can appreciate that there is definitely an attempt at personalization and guidance to make it less LLM-y and not just a default prompt, but it’s still kind of obvious. You could use a detector tool too of course.

What are the obvious tells? List them, because I think our sense of the tells may not overlap.

This article is clearly LLM-generated, even the title. A key indicator is that it almost makes sense: we forgot how to manufacture because that got sent to a different nation. The coding thing isn’t getting sent anywhere, so humanity is forgetting how to code. The distinction undermines a lot of the emotional baggage about offshoring that the article wants you to bring along.

The blog post reads nothing like Hemingway. Here's a classic example: https://anthology.lib.virginia.edu/work/Hemingway/hemingway-...

Hemingway writes simple sentences with a kind of detachment to make the emotional flow of his stories as transparent as possible.

LLM slop reads more like slide bullet points extrapolated to prose-length text

Blog posts aren't typically written like Hemingway.

Find some pre 2020 that are, and you'd have a point.

https://awnist.com/slop-cop (via https://news.ycombinator.com/item?id=47806845) points out Staccato Burst, Dramatic Fragment, Colon Elaboration, and Short-Hook Paragraph. To me, those define the tone of this article.

Costs are externalized, profits are privatized. A tale as old as the society itself.

The problem was the government providing the blank check loans with no underwriting. Without that subsidy from future taxpayers, incentives would be properly aligned.

No lender would have been stupid enough to give 18 to 22 year olds $200k for bullshit degrees and sports facilities.

The onus would have remained on employers and government to pay for education, rather than a certification, because they would have been the ones paying.

No, you probably need to elaborate on that. Because in my experience, the quality from people in India varies just as much as the quality from any other country, including the USA.

What does make a difference is the company they work for. Large hourly "body shops" gives you coders whose quality tends to be lower, regardless if we are talking about an Indian firm or an American firm. Direct hires of independent individuals tend to be higher. But there is always individual variation.

You see people from India more, sure. There are more of them. Over a billion of them, to be precise. Anyone who dismisses a billion people as "always the same" is not being clever, they are being racist. And you know that, otherwise you wouldn't have pre-empted this response with "everyone who is ready to accept it."

Say that there are communication gaps to overcome. Say there are cultural differences. Say that those cultural differences change the assumed business expectations and the mechanisms by which people express their thoughts and opinions. Those things are all true. My recommendation to anyone who has an urge to dismiss an entire population is to instead get to know them: Step up and learn how your teammates think and work. It will make for a better team, better communication, and better results.

[dead]

America could just reduce their cost of living, optimize their healthcare, make domestic business more attractive etc instead of trying to ban everything to duct tape over deeper problems

> It's really strange how we're just letting them get away with this.

Choosing to pay less is what almost all people do, and it is consistent with almost all of human history.

> They're on a fast trajectory toward putting Americans completely out of work and without aid, even though they're American companies first and foremost.

When push comes to shove, i.e. paying lower prices to consume more goods and services or paying higher prices to ensure your countrymen can buy more goods and services, almost everyone will choose to pay lower prices. See political unpopularity of sufficient tariffs to stop imports.

“American” is a nebulous term, and Americans have been choosing lower prices for many decades before the current crop of employees at the global big tech companies chose lower prices. It is no different than when someone picks up lower priced workers outside waiting Home Depot, who are there because they do not have legal work authorization in the US.

[flagged]

[flagged]

According to [0] the military was basically doing under-the-radar preparations in the last few weeks before the attack, because the official narrative was that nothing's gonna happen.

> A small group of officers at HUR, Ukraine’s military intelligence agency, did begin quiet contingency planning in January, prompted by the US warnings and the agency’s own information, one HUR general recalled. Under the guise of a month-long training exercise, they rented several safe houses around Kyiv and took out large supplies of cash. After a month, in mid-February, the war had not yet started, so the “training” was prolonged for another month.

> The army commander-in-chief, Valerii Zaluzhnyi, was frustrated that Zelenskyy did not want to introduce martial law, which would have allowed him to reposition troops and prepare battle plans. “You’re about to fight Mike Tyson and the only fight you’ve had before is a pillow fight with your little brother. It’s a one-in-a-million chance and you need to be prepared,” he said.

> Without official sanction, Zaluzhnyi did what little planning he could. In mid-January, he and his wife moved from their ground-floor apartment into his official quarters inside the general staff compound, for security reasons and so he could work longer hours. In February, another general recalled, table-top exercises were held among the army’s top commanders to plan for various invasion scenarios. These included an attack on Kyiv and even one situation that was worse than what eventually transpired, in which the Russians seized a corridor along Ukraine’s western border to stop supplies coming in from allies. But without sanction from the top, these plans remained on paper only; any big movement of troops would be illegal and hard to disguise.

[0] https://www.theguardian.com/world/ng-interactive/2026/feb/20...

Killing of families is what happened in Ukraine in the Russia controlled territories.

GP also probably had a sampling bias. The ones who were actually concerned about the impending Russian invasion presumably fled out of the country (or at least, away from the major cities to rural areas that probably see less fighting)

> While nobody actually believed Putin would be dumb enough

I'm not sure why you'd say nobody thought they would invade. To me it was clear in December the year before when the Russian navy began sailing the long way around Europe, getting in the way of Irish fisherman and confirmed days before the invasion when they had stockpiled medical personnel and blood on the front lines.