5 ms·

> My main issue with vibe coding etc is I simply don't enjoy it. Having a conversation with a computer to generate code that I don't entirely understand and the

by timr 1y ago

> My main issue with vibe coding etc is I simply don't enjoy it. Having a conversation with a computer to generate code that I don't entirely understand and then have to try to review is just not fun. It doesn't give me any of the same kind of intellectual satisfaction that I get out of actually writing code. I am the opposite. After a few decades of writing code, it wasn't "fun" to write yet another file parser or hook widget A to API B -- which is >99% of coding today. I moved into product management because while I still enjoy building things, it's much more satisfying/challenging to focus on the higher-level issues of making a product that solves a need. My professional life became writing specs, and reviewing code. It's therefore actually kind of fun to work with AI, because I can think technically, but I don't have to do the tedious parts that make me want to descend into a coma. I could care less if I'm writing a spec for a robot, or I'm writing a spec for a junior front-end engineer. They're both going to screw up, and I'm going to have to spend time explaining the problem again and again...at least the robot never complains and tries really hard to do exactly what I ask, instead of slacking off, doing something more intellectually appealing, getting mired in technical complexity, etc.

kiitos 1y ago
> After a few decades of writing code, it wasn't "fun" to write yet another file parser or hook widget A to API B -- which is >99% of coding today. If this is your experience of programming, then I feel for you, my dude, because that sucks. But it is definitely not my experience of programming. And so I absolutely reject your claim that this experience represents "99% of programming" -- that stuff is rote and annoying and automate-able and all that, no argument, but it's not what any senior-level engineer worth their salt is spending any of their time on!
- NewsaHackO 1y ago
  People who don’t do 1)API connecting, 2)Web design using popular frameworks or 3) requirements wrangling with business analysts have jobs that will not be taken over by AI anytime soon. I think 99% of jobs is pushing it, but I definitely think the vast majority of IT jobs fit into the above categories. Another benchmark would be how much of your job is closer to research work.
dlisboa 1y ago
You touched on the significant thing that separates most of the AI code discourse in the two extremes: some people just don't like programming and see it as a simple means to an end, while others love the process of actually crafting code. Similar to the differences between an art collector and a painter. One wants the ends, the other desires the means.
- morkalork 1y ago
  I think I could be happy switching between the two modes. There's tasks that are completely repetative slop that I've fully offloaded to AI with great satisfaction. There's others I enjoy that I prefer to use AI for consultation only. Regardless, few people liked doing code review before with their peers and somehow we've increased one of the least fun parts of the job.
- timr 1y ago
  That's not fair, and not what I am saying at all. I enjoy writing code. I just don't enjoy writing code that I've written a thousand times before. It's like saying that Picasso should have enjoyed painting houses for a living. They're both painting, right? (to be painfully clear, I'm not comparing myself to Picasso; I'm extending on your metaphor.)
  - bluefirebrand 1y ago
    You would rather debug the low quality LLM code that you know you could write better, a thousand times?
    - timr 1y ago
      Well, I don't write bugs in my code, of course, but let's just say that you were the type of person who does: having a bot that writes code 100x faster than you, that also occasionally makes mistakes (but can also fix them!), is still a huge win.
      - bluefirebrand 1y ago
icedchai 1y ago
Same. After doing this for decades, so much programming work is tedious. Maybe 5% to 20% of the work is interesting. If I can get a good chunk of that other 80%+ built out quickly with a reasonable level of quality, then we're good.
prmph 1y ago
After like the 20th time explaining the same (simple) problem to the AI that it is unable to fix, you just might change your mind [1]. At that point you just have to jump in and get dirty. Do this a few times and you start to realize it is kinda of worse than just being in the driver's seat in terms of the coding right from the start. For one thing, when you jump in, you are working with code that is probably architectured quite differently from the way you normally do, and you have no developed the deep mental model that is needed to work with the code effectively. Not to say the LLMs are not useful, especially in agent mode. But the temptation is always to trust and task them with more than they can handle. maybe we need an agent that limits the scope of what you can ask it to do, to keep you involved at the necessary level. People keep thinking we are at the level where we can forget about the nitty gritty of the code and rise up the abstraction level, when this is nothing close to the truth. [1] Source: me last week trying really hard to work like you are talking about with Claude Code.
- timr 1y ago
  > After like the 20th time explaining the same (simple) problem to the AI that it is unable to fix, you just might change your mind [1]. At that point you just have to jump in and get dirty. You're assuming that I haven't. Yes, sometimes you have to do it yourself, and the people who are claiming that you can replace experienced engineers with these are wrong (at least for now, and for non-trivial problems). > Do this a few times and you start to realize it is kinda of worse than just being in the driver's seat in terms of the coding right from the start. For one thing, when you jump in, you are working with code that is probably architectured quite differently from the way you normally do, and you have no developed the deep mental model that is needed to work with the code effectively. Disagree. There's not a single piece of code I've written using these that I haven't carefully curated myself. Usually the result (after rounds of prompting) is smaller, significantly better, and closer to my original intended design than what I got out of the machine on first prompt. I still find them to be a significant net enhancement to my productivity. For me, it's very much like working with a tireless junior engineer who is available at all hours, willing to work through piles of thankless drudgery without complaint, and also codes about 100x faster than I do. But again, I know what I'm doing. For an inexperienced coder, I'm more inclined to agree with your comment. The first drafts that these things emit is often pretty bad.
getnormality 1y ago
Your use case seems relatively well-suited to AI. Even an unreliable technology like LLMs could be useful for automating a task that is mundane, well-defined, and easy to review for accuracy.

by timr 1y ago

kiitos 1y ago

> After a few decades of writing code, it wasn't "fun" to write yet another file parser or hook widget A to API B -- which is >99% of coding today. If this is your experience of programming, then I feel for you, my dude, because that sucks. But it is definitely not my experience of programming. And so I absolutely reject your claim that this experience represents "99% of programming" -- that stuff is rote and annoying and automate-able and all that, no argument, but it's not what any senior-level engineer worth their salt is spending any of their time on!

NewsaHackO 1y ago
People who don’t do 1)API connecting, 2)Web design using popular frameworks or 3) requirements wrangling with business analysts have jobs that will not be taken over by AI anytime soon. I think 99% of jobs is pushing it, but I definitely think the vast majority of IT jobs fit into the above categories. Another benchmark would be how much of your job is closer to research work.

dlisboa 1y ago

You touched on the significant thing that separates most of the AI code discourse in the two extremes: some people just don't like programming and see it as a simple means to an end, while others love the process of actually crafting code. Similar to the differences between an art collector and a painter. One wants the ends, the other desires the means.

morkalork 1y ago
I think I could be happy switching between the two modes. There's tasks that are completely repetative slop that I've fully offloaded to AI with great satisfaction. There's others I enjoy that I prefer to use AI for consultation only. Regardless, few people liked doing code review before with their peers and somehow we've increased one of the least fun parts of the job.
timr 1y ago
That's not fair, and not what I am saying at all. I enjoy writing code. I just don't enjoy writing code that I've written a thousand times before. It's like saying that Picasso should have enjoyed painting houses for a living. They're both painting, right? (to be painfully clear, I'm not comparing myself to Picasso; I'm extending on your metaphor.)
- bluefirebrand 1y ago
  You would rather debug the low quality LLM code that you know you could write better, a thousand times?
  - timr 1y ago
    Well, I don't write bugs in my code, of course, but let's just say that you were the type of person who does: having a bot that writes code 100x faster than you, that also occasionally makes mistakes (but can also fix them!), is still a huge win.
    - bluefirebrand 1y ago

icedchai 1y ago

Same. After doing this for decades, so much programming work is tedious. Maybe 5% to 20% of the work is interesting. If I can get a good chunk of that other 80%+ built out quickly with a reasonable level of quality, then we're good.

prmph 1y ago

After like the 20th time explaining the same (simple) problem to the AI that it is unable to fix, you just might change your mind [1]. At that point you just have to jump in and get dirty. Do this a few times and you start to realize it is kinda of worse than just being in the driver's seat in terms of the coding right from the start. For one thing, when you jump in, you are working with code that is probably architectured quite differently from the way you normally do, and you have no developed the deep mental model that is needed to work with the code effectively. Not to say the LLMs are not useful, especially in agent mode. But the temptation is always to trust and task them with more than they can handle. maybe we need an agent that limits the scope of what you can ask it to do, to keep you involved at the necessary level. People keep thinking we are at the level where we can forget about the nitty gritty of the code and rise up the abstraction level, when this is nothing close to the truth. [1] Source: me last week trying really hard to work like you are talking about with Claude Code.

timr 1y ago
> After like the 20th time explaining the same (simple) problem to the AI that it is unable to fix, you just might change your mind [1]. At that point you just have to jump in and get dirty. You're assuming that I haven't. Yes, sometimes you have to do it yourself, and the people who are claiming that you can replace experienced engineers with these are wrong (at least for now, and for non-trivial problems). > Do this a few times and you start to realize it is kinda of worse than just being in the driver's seat in terms of the coding right from the start. For one thing, when you jump in, you are working with code that is probably architectured quite differently from the way you normally do, and you have no developed the deep mental model that is needed to work with the code effectively. Disagree. There's not a single piece of code I've written using these that I haven't carefully curated myself. Usually the result (after rounds of prompting) is smaller, significantly better, and closer to my original intended design than what I got out of the machine on first prompt. I still find them to be a significant net enhancement to my productivity. For me, it's very much like working with a tireless junior engineer who is available at all hours, willing to work through piles of thankless drudgery without complaint, and also codes about 100x faster than I do. But again, I know what I'm doing. For an inexperienced coder, I'm more inclined to agree with your comment. The first drafts that these things emit is often pretty bad.

getnormality 1y ago

Your use case seems relatively well-suited to AI. Even an unreliable technology like LLMs could be useful for automating a task that is mundane, well-defined, and easy to review for accuracy.