Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vibe Coding and the Future of Software Engineering

alexp.pl

Post reply on HN
Print view View original

51–60 of 103 posts

Re: Vibe Coding and the Future of Software Engineering

#51

Post by adamq_q »

LPisGood wrote: post #17
Karrot_Kream wrote: post #6

If you're writing one-off scripts though, I find vibe coding fantastic. I found myself in a work meeting where I was mostly there to let a junior present some joint work we did and answer any questions the junior couldn't. Since I wasn't really needed (the junior eng was awesome), I was fidgeting and wanted to analyze the results from an API I had access to. A few prompts from Claude and I was hitting the API, fetchi…

I recently tried this _exact_ same thing (except it was less of a meeting and more like a phone call) and I got stuck because it kept making up fake API endpoints OR I had to go manually login somewhere to get the API key.

Which model?

Re: Vibe Coding and the Future of Software Engineering

#52

Post by jcgrillo »

antirez wrote: post #4
PartiallyTyped wrote: post #3

Earlier quoted context omitted.

Are you willing to elaborate about how they can accelerate you?

I have a youtube channel with a playlist of coding with AI, where I show what I do with it (a small part, actually, but representative enough I hope). This is is the first video of the series I believe: https://www.youtube.com/watch?v=_pLlet9Jrzc&list=PLrEMgOSrS_... And here, Redis bugfixing with Claude Sonnet: https://www.youtube.com/watch?v=rCIZflYEpEk&list=PLrEMgOSrS_...

I don't get it. Watched the first video, and it seems like the LLMs provided no value at all? Like, you already knew where the bug was, and what the bug was, and they couldn't find it? So 20+min of messing around with prompts and reading through pages of output.. for nothing? How is this supposed to help?

Re: Vibe Coding and the Future of Software Engineering

#53

Post by throwaway290 »

hnthrow90348765 wrote: post #18

My guess is CRUD app development will become commoditized like ordinary pentesting. The money in security is definitely not regular pentesting these days. You'll see smaller team sizes at first, then continuing to shrink as individual positions get a higher workload and spread of knowledge. I think "Vibe coding" is probably a canary for all of this so it's worth paying attention to what a non-programmer can actually…

> You'll see smaller team sizes at first, then continuing to shrink as individual positions get a higher workload and spread of knowledge.

In other words: "programmers on whose work the LLMs were trained will lose their jobs"

Re: Vibe Coding and the Future of Software Engineering

#54

Post by t-writescode »

hooverd wrote: post #37

I wonder how many new developers will have legit panic attacks if their LLM of choice has an outage.

"I wonder how many new developers will have legit panic attacks if:

  * Slack is down
  * StackOverflow is down
  * their default docs website is down
  * their IDE of choice is being buggy and so they have to use
    something without autocomplete
Life gets harder when assistive tools are lost, no matter what the tool.

Re: Vibe Coding and the Future of Software Engineering

#55

Post by re-thc »

sergiotapia wrote: post #21
PartiallyTyped wrote: post #3

Earlier quoted context omitted.

Are you willing to elaborate about how they can accelerate you?

One example: I had to send a report to a slack webhook, showing how many oban jobs were completed in the last 24 hours for specific uses cases based on oban job params. That's: sql query, slack webhook api docs reading, ecto query for oban jobs with complex para filtering, oban job to run cron, cron syntax. easily like a 2 hour job? it took me 5 minutes with AI. then we decided to send the slack alert at 7am EST inst…

> these gains are compounding.

It's not really. You could have done the same using no code tools in a similar time.

Question is, would you? It's alarming the amount of trust/praise that goes into "AI".

> if you're an experienced engineer > it took me 5 minutes with AI

You'd at least read the code and fix things up so it wouldn't be 5 minutes.

Re: Vibe Coding and the Future of Software Engineering

#56

Post by t-writescode »

Swizec wrote: post #5
PartiallyTyped wrote: post #3

Earlier quoted context omitted.

Are you willing to elaborate about how they can accelerate you?

> Are you willing to elaborate about how they can accelerate you? A few examples from my experience: - Here is a SQL query. Translate this back into our janky ORM - Write tests that cover cases X, Y, Z - Wtf is this code trying to do? - I want to do X, write the boilerplate to get me started - Reshape this code to follow the new conventions And it often picks up on me doing a refactor then starts making suggestions s…

To add:

  - "I've never used this language / framework, this is what I'm trying to do, how would I do it?"
  - the documentation for these libraries is ... not useful. How do I do X?
    Followed by: "these parts didn't work due to these restrictions, tell me more".
    (I'm currently using this one to navigate Unity and UdonSharp's APIs. It is far from perfect
     but having *something* that half-works and moves me in the right direction of understanding
     how everything connects together is much much faster than sitting there, confused, unable
     to take a single step forward)
I find that a lot of cases where "just read the documentation" is the best route are situations where there is good (or any) documentation that is organized in a single, usable space and that doesn't require literal days worth of study to sufficiently understand the whole context to do what is, with all that context, a very simple task.

I'm reminded a bit of the days when I was a brand new Java programmer and I would regularly Google / copy-paste:

  public class Foo {
  
    public static void main(String[] args) {
        
    }
  }
Or new Python devs when they constantly have to look up

  if __name__ == '__main__':
    run_me()
because it's just a weird, magical incantation that's blocking their ability to do what they want to do

Re: Vibe Coding and the Future of Software Engineering

#57

Post by t-writescode »

re-thc wrote: post #55
sergiotapia wrote: post #21

Earlier quoted context omitted.

One example: I had to send a report to a slack webhook, showing how many oban jobs were completed in the last 24 hours for specific uses cases based on oban job params. That's: sql query, slack webhook api docs reading, ecto query for oban jobs with complex para filtering, oban job to run cron, cron syntax. easily like a 2 hour job? it took me 5 minutes with AI. then we decided to send the slack alert at 7am EST inst…

> these gains are compounding. It's not really. You could have done the same using no code tools in a similar time. Question is, would you? It's alarming the amount of trust/praise that goes into "AI". > if you're an experienced engineer > it took me 5 minutes with AI You'd at least read the code and fix things up so it wouldn't be 5 minutes.

For a lot of the vomit code which is mostly just skimming the API to find the magical incantation, it probably is 5 minutes, honestly.

Re: Vibe Coding and the Future of Software Engineering

#58

Post by re-thc »

zero_shift wrote: post #7
PartiallyTyped wrote: post #3

Earlier quoted context omitted.

Are you willing to elaborate about how they can accelerate you?

Data point of one: ChatGPT 3.5, even the free product, is so much better at answering technical questions than Google. Some questions I had successfully answered recently: > "I would like to animate changing a snippet of code. I'll probably be using Remotion. Is there a JavaScript library that can animate changing one block of text into another?" > "In Golang, how can I unit test a http mux? How can I test the routes…

> Data point of one: ChatGPT 3.5, even the free product, is so much better at answering technical questions than Google.

That's not the point of Google. It gives you a start to research the answer you need. ChatGPT just gives you an answer that might not be correct. So how do you define "successfully answered"?

In programming there are always tradeoffs. It's not about picking the 1st answer that looks like it "runs".

Re: Vibe Coding and the Future of Software Engineering

#59

Post by zamadatix »

thwarted wrote: post #48
AlwaysRock wrote: post #24

Earlier quoted context omitted.

I was doing some file management last weekend and wanted a little script to remove any numbers at the start of a file name and any region values at the end. I also wanted to ensure any duplicate files were moved into a separate folder so i could remove them. I could have written that code. I'm sure there is a program that can do exactly that for me that I could have downloaded. But one prompt, a few tests to make sur…

There's probably a program in /usr/bin on your machine that does that.

Such as /usr/bin/bash!

More seriously rename (sometimes rename.ul) is built to do (some) of this task, and you may have some others depending how "featureful" your install is, but why bother for a one time task when it's not going to be more work to figure out what tool to use, what options it needs, and what parts will still need to be done after anyways?

Honestly this is just a great task for a script, even if you were going to hand write it. It'll be clearer, rely on fewer assumptions, and be more flexible if the task needs to change as you try to do it and notice something else.

Re: Vibe Coding and the Future of Software Engineering

#60

Post by AdieuToLogic »

AlwaysRock wrote: post #24
brundolf wrote: post #8

Earlier quoted context omitted.

Agreed. I've had a lot of success using ChatGPT for nontrivial bash one-liners. They're small in scope and there must be a huge amount of training data for them, I use them rarely enough that I don't remember details off the top of my head, and they're intrinsically throwaway code

I was doing some file management last weekend and wanted a little script to remove any numbers at the start of a file name and any region values at the end. I also wanted to ensure any duplicate files were moved into a separate folder so i could remove them. I could have written that code. I'm sure there is a program that can do exactly that for me that I could have downloaded. But one prompt, a few tests to make sur…

> I was doing some file management last weekend and wanted a little script to remove any numbers at the start of a file name and any region values at the end. I also wanted to ensure any duplicate files were moved into a separate folder so i could remove them.

> I could have written that code.

Not knowing precisely your desired result, the benefit of going through the effort of writing a script is experienced gained and deepening one's understanding of the tools involved.

For example, assume this file structure exists:

  .
  ├── 001name-eu-central1.ext
  ├── 001name-us-west.ext
  ├── 002name-eu-central1.ext
  ├── 003name-eu-central1.ext
  ├── keep
  └── research
The script logic to do what you describe could be similar to:

  for file in [0-9]*
  do
    dest="$(echo $file | sed -E -e 's/^[0-9]*//' -e 's/-(eu-central1|us-west)//')"

    if [[ -f "keep/$dest" ]]
    then
      mv "$file" "research/$file"
    else
      mv "$file" "keep/$dest"
    fi
  done
This results in:

  .
  ├── keep
  │   └── name.ext
  └── research
      ├── 001name-us-west.ext
      ├── 002name-eu-central1.ext
      └── 003name-eu-central1.ext
The net-net is that the journey is sometimes more valuable than the destination.
Post reply on HN