I don’t really understand the slot machine, addiction, dopamine meme with LLM coding. Yeah it’s nice when a tool saves you time. Are people addicted to CNCs, table saws, and 3D printers?

I've watched my boss type out a lengthy few sentences to do a find+replace, it took him a few minutes.

This is a guy with 10+ years experience as a dev. It was a watershed moment for me, many people really have stopped thinking for themselves.

The way humans are depicted in Wall-E springs to mind as being quite prescient, it wasn't meant to be a doco

I have unfortunately found myself doing stuff like this too, although maybe not as egregious.

I think part of the problem is that our brains are wired to look for the path of least resistance, and so shoving everything into an LLM prompt becomes an easy escape hatch. I'm trying to combat this myself, but finding it not trivial, to be honest. All these tools are kind of just making me lazier week over week.

My team lead said he uses coding agents to format code.

I don't use the agentic workflow (as I am using it for my own personal projects), but if you have ever used it, there is this rush when it solves a problem that you have been struggling with for some time, especially if it gives a solution in an approach you never even considered that it has baked in its knowledge base. It's like an "Eureka" moment. Of course, as you use it more and more, you start to get better at recognizing "Eureka" moments and hallucinations, but I can definitely see how some people keep chasing that rush/feeling you get when it uses 5 minutes to solve a problem that would have taken you ages to do (if at all).

Also, another difference is the stochastic nature of the LLMs. With table saws, CNC machines, and modern 3D printers, you kind of know what you are getting out. With LLMs, there is a whole chance aspect; sometimes, what it spits out is plainly incorrect, sometimes, it is exactly what you are thinking, but when you hit the jackpot, and get the nugget of info that elegantly solves the problem, you get the rush. Then, you start the whole bikeshedding of your prompt/models/parameters to try and hit the jackpot again.

It is the rush of "wow it solved this." I should take a break and work on something else, but in the back of my mind "what else can it solve?" Then I come up with extra work and sometimes lose at the LLM casino.

does your table saw build you a bookshelf by itself? and then you build other things and get confident in it and say: ok build me a house and it tries but then the house falls over?

Long term LLM use will greatly reduce your ability to work in the absense of them. Which is how addiction works.

I don't think there are good analogies to physical tools. It would be something like a nondeterministic version of a replicator from Star Trek which to me would feel much closer to a slot machine than a CNC mill.

It's fun and you do get a dopamine rush when LLM does something cool for you. I'm certainly feeling it as a user. Perhaps you can get the same from other tools. I would vote for yes- addictive.

But it's also a tool that (can) save(s) you time.

Not sure what CNCs are but table saws and 3d printers still require thinking, planning, guiding by the operator.

I know I know you're going to say (or simonw will) that effective and responsible use of LLM coding agents also requires those things, but in the real world that just isn't what's happening.

I am witnessing first hand people on my team pasting in a jira story, pressing the button and hoping for the best. And since it does sometimes do a somewhat decent job, they are addicted.

I literally heard my team lead say to someone "just use copilot so you don't have to use your brain". He's got all the tools- windsurf, antigravity, codex, copilot- just keeps firing off vibe coded pull requests.

Our manager has AI psychosis, says the teams that keep their jobs will be the ones that move fastest using AI, doesn't matter what mess the code base ends up in because those fast moving teams get to move on to other projects while the loser slow teams inherit and maintain the mess.

The dopamine rush to fix the issue super quickly, close the ticket, slack / work more?

Absolutely, not understanding why you even ask. Humans are creatures of habits that often dip a bit or more into outright addictions, in one of its many forms.

dopameme?

Yes

A year ago it felt like SoTA model developers were not improving so much as moving the dirt around. Maybe we’re in another such rut.

HN is a bubble. I hear people from outside of Silicon Valley that only just started trying out Claude Code recently. There's still a ton of developers yet to jump on board.

CC kinda sucks compared to opencode & kimi / minimax. It’s slow and annoying and the UI is subpar.

California laws in a nutshell.

I love vibe coding for little tools like that. Tools which can have their outputs quickly validated, and then throw them away. Like a jig in woodworking.

People pushing dozens of PRs per day need to learn to prioritize tasks, and balance a bit more towards quality over quantity.

This is the way. There's nothing inherently wrong with using AI as long as it's used responsibly.

I highly doubt there are any managers or executives who care how AI is precisely used as long as there are positive results. I would argue that this is indeed an engineering problem, not an upper management one.

What's missing is a realistic discussion about this problem online. We instead see insanely reckless people bragging about how fast they drove their pile of shit startup directly into the ground, or people in denial loudly banging drums to resist all forms of AI.

And maybe spend some time doing reviews for other developers. And if they aren't qualified to be, then maybe spend that time becoming qualified rather than pumping out more slop.

Wondering how all of those startups that implement this for GitHub feel right now.

sherlocked

Well if the big players want to tell me their models are nearly AGI they need to put up or shut up. I don't want a stochastically downloaded C compiler. I want tech that improves something.

The US is captured by the Israeli lobby. Spain is captured by the football lobby.

The main problem with TypeScript is the default compiler flags are not safe. I understand having things weak when you’re getting the ecosystem up and running, before you have wide adoption. You don’t want to throw too many red squigglies at early adopters and cause them to give up. But these days the default should not allow any. No implicit any. No explicit any. The stdlib should not use it. JSON.parse() should return either unknown or a recursive union that defines all valid JSON structures.

I believe it’s largely because of these defaults that the idea that TypeScript isn’t really checking types persists. Without the any type, or loose undefined and null checks, your types are as validated as they can be. The only failure point is deserialization or an import which doesn’t type check. And deserialization has this problem in every language.

When you compile C to machine code the executed binary isn’t checking types. This is no different from Typescript that’s been compiled to JavaScript.

Even with strict flags on, there are failures. A trivial example:

  function mutateArray(
    arr: (string | number)[]
  ) {
    arr.push(1);
  }
  const a: string[] = ["one", "two"];
  mutateArray(a);

a is now a string[] with a number inside

Woah, that's quite an issue. The equivalent code in Python doesn't typecheck, since `list` is invariant and hence list[str] doesn't fit list[str|int]. Unusual for TS to handle types worse than Python.

Very interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly.

Is there a name for this failure mode?

I think the problem is the union argument type - intuitively we read "array of strings OR numbers", but actually it means "array of strings AND numbers". Probably generics would be more appropriate here, with the type param constrained to string or number. Then tsc would also complain about pushing a number without checking the item type before.

If it's an "array of strings AND numbers", then it should not be allowed to call the function with a string[], because those are different types.

That would be the sound way to do things, but it's also surprisingly common for arrays for some reason. It also doesn't get checked compile time in Java, although it does throw an exception because the arrays are type-enforced at runtime at least.

This compiles fine:

    class A {}

    class B1 extends A {}
    class B2 extends A {}

    public class MyClass {
        public static void main(String args[]) {
            A[] array = new B1[1];
            array[0] = new B2();
        }
    }

That’s barely scratching the surface.

In TypeScript the following is also valid:

class Something{

    value: Number

}

class SomethingElse{

    value: Number

    foo: String

    bar: SomeOtherThing[]

}

function AddSomething(v: Something)

{

    v.value += 1;

}

var ex = new SomethingElse{

    value: 3,

    foo: “TypeScript is fake types”,

    bar: []

};

AddSomething(ex);

Why does it work? Because in TypeScript as long as you have a “shape” that fits, it’s the “same type.”

Complete and utter insanity to me, to pretend there’s any real type checking, when types are entirely fake and made up.

That's because it's structurally typed (as opposed to nominally typed). I don't happen to prefer it, but I don't think it's fair to conflate that with unsoundness like the example given above; it's totally possible to have a sound structural type system. TypeScript doesn't happen to be sound, but it's not because of that.

Structural typing is great. It's the verified version of duck typing.

You can even get nominal typing with branded types if you need it. (Like for the newtype pattern)

In TypeScript it's called "bivariance", which sounds very programming language theory like, but is not a term typically used in academic contexts, since it is unsound almost by default. It's described here: https://www.typescriptlang.org/docs/handbook/type-compatibil...

Key sentence in their justification seems to be:

"allowing this enables many common JavaScript patterns"

Honestly at this point they should make a new strict "no js" mode, as the ecosystem likely has reached a tipping point where you can get by without mixing typed and untyped js at compile time. Wonder if targeting wasm directly would help ensure those boundaries are ensured...

https://www.assemblyscript.org/ is pretty darn close, but it would probably be better to converge and not split communities

I'm not aware of a name, but I'm also curious if there is one because I had a hard time searching for it.

I came across it on ThePrimeagen's YouTube channel: https://youtu.be/u1WmiqlrqL0

I asked an LLM and it described the problem as "covariant typing of mutable collections" or "unsound covariance". I'm not mathematically educated in this area but that sounds right?

Yes, that's correct. If you're curious for a slightly more concrete source, Wikipedia covers this reasonably well (although citing one often decried source to validate another might not be particularly convincing to some people): https://en.wikipedia.org/wiki/Type_variance#Arrays

Yikes. I've only been using ts for about a year, I had no idea this was considered a "valid" case. Seems like a type error to me. I wonder how they justify this?

> You don’t want to throw too many red squigglies at early adopters and cause them to give up.

That's not the reason.

TypeScript's main design goal was to enable developers to gradually introduce types in codebases that spent years being written purely in JS.

There's still demand for this feature and those who start off with TypeScript set their own config anyway.

I've dealt with people using all kinds of escape hatches, but 2/3 of the time it's caused by lack of proficiency in the language.

The rest is either someone being in a hurry or just not serious about their job.

With TypeScript 6.0 and above it is indeed much stricter by default.