all 16 comments

sorted by: hot top controversial new old
[–] [S] 26 points 9 months ago (4 children)

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.

  • source
  • hideshow 4 child comments
  • [–] 7 points 9 months ago (3 children)

    Those AI all use dark patterns to keep people hooked. It’s literally a predictive Candy Crush or slot machine.

    These are dangerous.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 6 points 9 months ago (2 children)

    Do you know of any reports that AI companies did this intentionally? It would make business sense for them to make them addicting

  • source
  • parent
  • hideshow 2 child comments
  • [–] 5 points 9 months ago* (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 9 months ago

    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.

  • source
  • parent
  • [–] 5 points 9 months ago (10 children)
  • [+] 8 points 9 months ago (9 children)
  • [–] 8 points 9 months ago (2 children)

    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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 9 months ago* (5 children)

    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.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 2 points 9 months ago (2 children)
    tsc
    

    And now you're back to pure JavaScript.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 9 months ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 9 months ago

    By default, doesn't tsc just 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.

  • source
  • parent