4 ms·

the only good part was the joke about "vibecoding" (shudder what a stupid term) being like a fart and attracting flies... ok investors still, this "ai code too

by davydm 2y ago

the only good part was the joke about "vibecoding" (shudder what a stupid term) being like a fart and attracting flies... ok investors still, this "ai code tools will deprecate real programming" bullshit will one day be laughed at just like how most of us laugh at shitcoin maniacs it just takes a lot of people way too long to learn

skydhash 2y ago
Maybe there's a different universe out there, where the code you write is not expected to work, so you can poke the LLM for a whole day to see if it barfs something out. I spend much of the day reading and thinking and only a small portion actually writing code, because when I'm typing, I usually have a hypothetical solution that is 99% correct and I'm just bringing it to life. Or I'm refactoring. You can interrupt me at any time and I could give you the complete recipe of what I'm doing. Which is why I don't use LLMs, because it's actually twice the work for me. Typing out the specs, then verifying and editing the given result, while I could type the code in the first place. And they suck at prototyping. Sometimes I may want to leave something in the bare state where only one incantation works, because I'm not sure of the design yet, and have a TODO comment, but they go to generate a more complicated code. Which is a pain to refactor later.
- wrs 2y ago
  I agree with the spirit of the argument, but I don’t think you’re taking into account the scale of “typing” we’re talking about now. For example, yesterday I needed a parser for a mini-language. I wrote a grammar — actually not even the formal grammar, just some examples — and what I wanted the AST to look like. I said “write the tokenizer”, and it did. I told it to tweak a few things and write tests. It did. I told it to “write a recursive descent parser”, and it did. Add tests and do some tweaks, done. The whole thing works and it took less than an hour. So yeah, I had to know I needed a parser, but at that point I could pretty much hand off the details. (Which I still checked over, so I’m not even in full vibe mode, guess.)
  - LPisGood 2y ago
    This is a cool use case that probably saved you some time, but writing a recursive descent parser is something freshman CS students do for a lab assignment. It isn’t exactly breaking new ground or doing anything you couldn’t find with a quick google search.
    - wrs 2y ago
      You want me to do a Google search for a parser for the language that I just invented? If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it.
      - kuschku 2y ago
        > If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it. That's the part where the LLM would be useful. Turn the examples into a grammar, verify the grammar, and use a parser generator for the rest. You know the code does what it should and you get there in minutes.
        wrs 2y ago
        I'm pretty sure it could have done that equally easily, but this grammar is small enough that a parser generator is overkill. (I made that decision before I asked the LLM to write the parser.)
  - skydhash 2y ago
    Isn't that what tools like antlr [0], bison[1] do? [0]: https://www.antlr.org/ https://www.antlr.org/ [1]: https://www.gnu.org/software/bison/ https://www.gnu.org/software/bison/
    - jdlshore 2y ago
      They typically generate generic LALR parsers, not custom recursive descent parsers. I'm no expert, but my understanding is that custom recursive descent parsers have advantages in terms of readability and error message generation.
- danielbln 2y ago
  I disagree, agentic coding is amazing for prototyping. It removes a ton of friction and inertia and allows me to try a bunch of ideas to see what works (from a delivery and/or UX perspective). Of course, you should have the systems thinking and experience in place to know what it is you're doing with it at any given point , but for demos and prototypes it has been an absolute boon. Generally, you wouldn't type out the spec either, either you provide an existing spec to the model (in form of white board notes, meeting notes, etc.) or you iterate conversationally until you arrive at an initial implementation plan. It's a different way of working for sure, and it has distinct draw backs and requires different mental modes depending if you're doing green field, demo/prototype, existing large app feature development etc. but it's been a massive productivity enhancement, especially when tackling multiple projects in quick succession.
  - hombre_fatal 2y ago
    A good example of this at the extreme is game design. When you're making a game, it's really expensive to try out different ideas, like a few different implementations of a mechanic. It could be hours of work to make a change. You tend to have to do a lot of thinking to tweak a mechanic in a fundamental way just to see what it feels like, knowing that you're probably going to throw it away. LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like. Rollback the change or continue tweaking. Same with branching the UI to see what a different idea would feel like. Simple changes to explain could result in hours of refactoring UI code (chore work) just to see if you like the result. Or just ask the LLM to do it, see what it feels like, roll it back.
    - bluefirebrand 2y ago
      > LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like How do you verify that Claude did what you wanted? Maybe more importantly, how do you verify that Claude didn't make a change that you didn't want? Trying to verify the code changes just by testing the running project seems incredibly careless
null_name 2y ago
Yeah, call me a cynic or conservative or whatever - I'll believe it when I see it. I give very little weight to predictions about the future from AI shills, especially when they include some variant of "we're 90% there already" or "an exponential shift is imminent, if things keep improving at this rate, which they Will." Opinion discarded, create your thing and come back if/when it works. Everything is shifting so fast right now that it hardly matters anyways. Whatever I spend time learning will be outdated in a few years (when things are predicted to get good). It does matter if you're trying to sell AI products, though. Then you gotta convince people they're missing out, their livelihood is at stake if they don't use your new thing now now now.

by davydm 2y ago

skydhash 2y ago

Maybe there's a different universe out there, where the code you write is not expected to work, so you can poke the LLM for a whole day to see if it barfs something out. I spend much of the day reading and thinking and only a small portion actually writing code, because when I'm typing, I usually have a hypothetical solution that is 99% correct and I'm just bringing it to life. Or I'm refactoring. You can interrupt me at any time and I could give you the complete recipe of what I'm doing. Which is why I don't use LLMs, because it's actually twice the work for me. Typing out the specs, then verifying and editing the given result, while I could type the code in the first place. And they suck at prototyping. Sometimes I may want to leave something in the bare state where only one incantation works, because I'm not sure of the design yet, and have a TODO comment, but they go to generate a more complicated code. Which is a pain to refactor later.

wrs 2y ago
I agree with the spirit of the argument, but I don’t think you’re taking into account the scale of “typing” we’re talking about now. For example, yesterday I needed a parser for a mini-language. I wrote a grammar — actually not even the formal grammar, just some examples — and what I wanted the AST to look like. I said “write the tokenizer”, and it did. I told it to tweak a few things and write tests. It did. I told it to “write a recursive descent parser”, and it did. Add tests and do some tweaks, done. The whole thing works and it took less than an hour. So yeah, I had to know I needed a parser, but at that point I could pretty much hand off the details. (Which I still checked over, so I’m not even in full vibe mode, guess.)
- LPisGood 2y ago
  This is a cool use case that probably saved you some time, but writing a recursive descent parser is something freshman CS students do for a lab assignment. It isn’t exactly breaking new ground or doing anything you couldn’t find with a quick google search.
  - wrs 2y ago
    You want me to do a Google search for a parser for the language that I just invented? If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it.
    - kuschku 2y ago
      > If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it. That's the part where the LLM would be useful. Turn the examples into a grammar, verify the grammar, and use a parser generator for the rest. You know the code does what it should and you get there in minutes.
      - wrs 2y ago
        I'm pretty sure it could have done that equally easily, but this grammar is small enough that a parser generator is overkill. (I made that decision before I asked the LLM to write the parser.)
- skydhash 2y ago
  Isn't that what tools like antlr [0], bison[1] do? [0]: https://www.antlr.org/ https://www.antlr.org/ [1]: https://www.gnu.org/software/bison/ https://www.gnu.org/software/bison/
  - jdlshore 2y ago
    They typically generate generic LALR parsers, not custom recursive descent parsers. I'm no expert, but my understanding is that custom recursive descent parsers have advantages in terms of readability and error message generation.
danielbln 2y ago
I disagree, agentic coding is amazing for prototyping. It removes a ton of friction and inertia and allows me to try a bunch of ideas to see what works (from a delivery and/or UX perspective). Of course, you should have the systems thinking and experience in place to know what it is you're doing with it at any given point , but for demos and prototypes it has been an absolute boon. Generally, you wouldn't type out the spec either, either you provide an existing spec to the model (in form of white board notes, meeting notes, etc.) or you iterate conversationally until you arrive at an initial implementation plan. It's a different way of working for sure, and it has distinct draw backs and requires different mental modes depending if you're doing green field, demo/prototype, existing large app feature development etc. but it's been a massive productivity enhancement, especially when tackling multiple projects in quick succession.
- hombre_fatal 2y ago
  A good example of this at the extreme is game design. When you're making a game, it's really expensive to try out different ideas, like a few different implementations of a mechanic. It could be hours of work to make a change. You tend to have to do a lot of thinking to tweak a mechanic in a fundamental way just to see what it feels like, knowing that you're probably going to throw it away. LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like. Rollback the change or continue tweaking. Same with branching the UI to see what a different idea would feel like. Simple changes to explain could result in hours of refactoring UI code (chore work) just to see if you like the result. Or just ask the LLM to do it, see what it feels like, roll it back.
  - bluefirebrand 2y ago
    > LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like How do you verify that Claude did what you wanted? Maybe more importantly, how do you verify that Claude didn't make a change that you didn't want? Trying to verify the code changes just by testing the running project seems incredibly careless

null_name 2y ago

Yeah, call me a cynic or conservative or whatever - I'll believe it when I see it. I give very little weight to predictions about the future from AI shills, especially when they include some variant of "we're 90% there already" or "an exponential shift is imminent, if things keep improving at this rate, which they Will." Opinion discarded, create your thing and come back if/when it works. Everything is shifting so fast right now that it hardly matters anyways. Whatever I spend time learning will be outdated in a few years (when things are predicted to get good). It does matter if you're trying to sell AI products, though. Then you gotta convince people they're missing out, their livelihood is at stake if they don't use your new thing now now now.