This isn’t anything new. There have been multiple waves of “code-gen for normies”, and every time after the hype dies down there’s a heap of shitty code to fix.

There’s gonna be no shortage of customers up to their eyeballs in broken slop after the bill comes due and Anthropic has to stop subsidizing their prices. AI slop is the best thing to happen to our job security in a while. (Provided you retain your critical thinking skills.)

At SolarWinds, he took a leadership role in the firm’s nascent Cloud business division of SaaS offerings built for developers/operators working on modern, cloud-native architectures.

Hmmm…

A SolarWinds product, Orion, used by about 33,000 public and private sector customers, was the focus of a U.S. federal government data leak in 2020. The attack persisted undetected for months in 2020, and additional details about the breadth and depth of compromised systems continued to surface after the initial disclosure.[7] In February 2021, Microsoft President Brad Smith said that it was “the largest and most sophisticated attack the world has ever seen”.[8]

To be clear, this is when yall were still reading the code, right?

We have well and truly lost the plot.

Speed of slop-generation is not really the critical barrier here. We’re already generating more synthetic text than humanity can possibly verify.

Pretty sus. I’m not saying it definitely didn’t happen, but Kim Dotcom is a weird pick and if the treasure trove is really that massive then why not drop a little morsel?

The classical cultural example is the Luddites, a social movement that failed so utterly that its name because a common metaphor for stubborn morons who are terrified of technological innovation that helps everybody. Deservedly so, to be clear…

Wow. I know every day in the US features some prominent individuals proudly demonstrating their ignorance of history, but this one still got me.

1. The Luddites didn’t oppose “technological innovation that helps everybody”. They opposed the new social order that came with this innovation — one that saw widespread poverty and starvation, extreme concentration of wealth, and entire generations of children maimed by machines or burned to death while locked in unsafe factories.
2. They didn’t fail. They were so powerful that knitting frames were declared property of the crown and destroying one became a capital offense (i.e. public execution). They laid the groundwork for modern workplace regulations — ones that we all benefit from today.

Edit:

Omfg

Technology changes things, and sometimes it hurts people in the short-term, but every invention from fire to mRNA vaccines has wound up generally increasing human welfare.

Looking only at one side of the balance sheet are we, moron?

These things come with costs. When you gain the ability to make fire, you also gain the ability to burn yourself to death. When you invent electricity, you also invent electrocution. Nuclear reactors can melt down.

There is a reason we don’t use radium paint, leaded paint, asbestos, CFCs, and leaded gasoline anymore. (We’re headed there with PFAS, too, I hope.) It’s not because we hate progress or that these didn’t do anything useful. They were too dangerous.

What a fucking braindead blob.

AI (through agents, but even completions to an extent) extends your reach and reduces your grasp.

For some sectors, that’s perfectly acceptable. There are plenty of codebases that don’t need to worry about keeping devs accountable.

There are also plenty of business models these days (especially in the Trump era) that face no downside from failing to keep devs accountable even if they should. VC-backed vaporware looking to exit before they drown in tech debt, private equity acquisitions that just need to bleed existing customers dry while disemboweling the productive capacity of the firm, or even publicly-traded brands that are chronically unable to think past next quarter’s P&L. And especially if they’re already a monopoly.

The trouble is really when a CTO misunderstands what kind of business they’re running, and considers the wrong folks to be their “peers”. There’s a big incentive to just copy whatever Amazon/Microsoft/Google says. It’s the new “nobody ever got fired for buying IBM”.

Idk if that’s your situation or not.

He’s even got some yellow as a backup

Is there a perfect building?

Probably not, since they exist in an environment — which is constantly changing — and are used by people — whose needs are constantly changing.

The same is true of software. Yes, programs consist of math which has objective qualities. But in order to execute in the physical world, they have to make certain assumptions which can always be invalidated.

Consider fast inverse sqrt: maybe perfect, for the time, for specific uses, on specific hardware? Probably not perfect for today.

You can learn to do anything. You’ll have an easier time learning if you like doing it. So what do you like? Or: what would you want to try and see if you like?

Also: why do you want to make a game? What interests you about that?

Why link to falsehoods without context?

Oviraptor
Oiaptor
Overaptor

eye twitch

Judge the code, not the coder.

Oh no, they learned how to make short and quippy — but wrong — statements.

If you think running an open source project is primarily about managing code and not people, then I humbly suggest you pay closer attention the next time you engage with one.

Source: https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

(Sorry dude, my time was limited by how long I could spare poopin in-between meetings.)

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing - is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil - objects are merely a poor man’s closures.”

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.

Here’s the thing… code is much closer to doing group therapy than it is to flipping burgers. The final produced artifact is somewhat less important than converging on the tiny itty-bitty details of how to collaborate on the journey of getting there. This is especially true for open source projects.

Spending time trying to understand the perspective of a chatbot-managed contributor is a waste of time. You’re not going to be able to build a community around having a good developer experience for doing XYZ if half of the people weighing in on “how to do that” are not developers who are directly experiencing the thing they’re poking at.

Edit: Also, on testing specifically… this is something I see teams get wrong all the time. The real value of a test suite is not from making sure your system works correctly, but from making sure it’s easy to inspect how your system works. If it’s hard to write or modify tests, that’s an indication that you’ve got some unwieldy abstractions floating around. LLMs don’t care about whether the friction of test-writing is increasing.

Very big agree. This is actually one of the things that I love about TypeScript.

Because the compiler makes a strong guarantee that type info cannot modify runtime behavior, you’re free to manage the type layer and implementation layer independently to whatever extent you desire.

That means you can get granular and pedantic in the places where you see value in having the compiler enforce things, or get loose and permissive where that makes more sense.

It’s an approach that I really miss when I have to use languages that require your runtime behavior to comport with type system rules. I wish more type checkers had some kind of Ron Swanson escape hatch.

Except that code is generally made of… other code. And generally gets transformed from some kind of source form to some kind of deployment form. And then executed by some kind of runtime, made of code. On some kind of OS, made of code.

The level of abstraction at which you make paper by hand is pretty much constant. The level of abstraction at which you make even a “hello world” program by hand is extremely flexible.

Depending on your operating environment, even an incredibly complex and impressive task may just be a matter of passing the right flag to a CLI tool that you already use.

Being attentive to the manual experience of how a codebase “feels” is pretty important for making sure a system has a coherent (read: not over-engineered) approach to bridging the high and low levels of the tasks it performs.

Not paying attention to that, because you can delegate it to a chatbot, is kind of like forgoing having light switches in a room because you can just keep a crane parked outside and have it slam a lighting fixture through the ceiling when you need it and then dump a mound of dirt to cover the hole when you don’t need it.

Like, that functions and accomplishes the task in a pinch, but you do not want to try occupying that room in person at any point to do any kind of detail work.

In order to be effective at software engineering, you must be familiar with the problem space, and this requires thinking and wrestling with the problem. You can’t truly know the pain of using an API by just reading its documentation or implementation. You have to use it to experience it. The act of writing code, despite being slower, was a way for me to wrestle with the problem space, a way for me to find out that my initial ideas didn’t work, a way for thinking. Vibe coding interfered with that.

If you’re thinking without writing, you only think you’re thinking.

– Leslie Lamport

Yep. This what I don’t get about people who are using these spaghetti-bots. How do they figure out the right solution to a problem without actually walking around the whole perimeter of the problem?

My guess is they are not, and they’re just waiting until someone complains and they’ll get a job somewhere else and leave the mess for someone else(‘s chatbot) to clean up.

Between that and the death of open source, our industry is about to become a disaster area.

The “dark forest” internet is in full swing

I mourn it too, because there are dumbasses like this who are buying the hype and setting the industry back by decades as a result.