I am not surprised that there are parallels between vibe coding and gambling:
With vibe coding, people often report not realizing until hours, weeks, or even months later whether the code produced is any good. They find new bugs or they can’t make simple modifications; the program crashes in unexpected ways. Moreover, the signs of how hard the AI coding agent is working and the quantities of code produced often seem like short-term indicators of productivity. These can trigger the same feelings as the celebratory noises from the multiline slot machine.
I’m immune because it never managed to get the programm running for me in the first place xD
never managed to get the programm running
yeah, I download code and it just does not compile. My environment has not the required dependencies.
I was just trying to vibe code a script mod for a game but cursor was incapable of getting a 20 line lua script right
Those AI all use dark patterns to keep people hooked. It’s literally a predictive Candy Crush or slot machine.
These are dangerous.
Do you know of any reports that AI companies did this intentionally? It would make business sense for them to make them addicting
No official report that I can link, though I recall seeing something at some point. I mostly speak from personal experience. I am a bit sensitive to these, so I noticed them right away. I barely use AI mostly because of the “hooking effect”. Some friends I know are downright addicted, it’s sad to see.
I’m far from being an AI defender. And for the longest time I resisted the idea of vibe coding.
I will give you that, without the right experience, vibe coding feels like gambling.
But I learned rather quickly that you must first work on a dev plan with an LLM, and until that plan hasn’t covered every scenario, then you don’t move on.
That yields much better results, and it has the advantage of having the blueprints for when you need the LLM to make changes.
TypeScript, for those who aren’t familiar, is a Microsoft rewrite of JavaScript that’s incompatible with basic JavaScript in multiple ways
Wut
Yeah, that’s uhh… that’s technically true for very strange and specific definitions of “compatibility”… but it wildly misses the point of TypeScript. Not sure what he was thinking there.
Yeah node’s
--experimental-strip-typesexposes the absurdity immediately. The only incompatibility is that it has type annotations.Also, like… the fact that it has a compiler. It’s like saying C is incompatible with assembly because you can’t yeet a .c file at an assembler.
I mean once you write your app in typescript, you can’t “go back” to pure JavaScript, you’ll always have to use the typescript compiler to generate JavaScript (of course you can rewrite it later again, but will take potentially lots of effort). I’m pretty sure that’s what they meant with “incompatible”. You are now locked into M$ ecosystem.
tscAnd now you’re back to pure JavaScript.
Sure, but with lots of generated code that’s going to be hard to be human readable and changeable. It’s definitely more work to add a feature to the code generated by the compiler, than to add a feature if the code was initially written in JavaScript.
By default, doesn’t
tscjust output the source TS files with type info stripped? Worst case you run a formatter on that output and you’re done.There’s some nonstandard TS features like the iterator shim and decorators and such, but you don’t get those by default from what I remember.
You’re being too generous. Calling typescript a rewrite shows the author chose something as an example they clearly don’t understand the first thing about.
Possible, yes
