3 ms·

You're missing the point. The point isn't and never has been that it's a flawless tool. The point is that you can work the tool and get a working POC of someth

by baq 2y ago

You're missing the point. The point isn't and never has been that it's a flawless tool. The point is that you can work the tool and get a working POC of something you'd never attempt to do before in literally a couple hours. It isn't a compiler, it isn't a logician, it's a lossily-compressed image of the whole internet with English as a query language. Use it within the operational envelope, which is what the author did, with some interesting results and possibly pointing to a large implications on vibe-coding solutions you'd previously pay for.

feverzsj 2y ago
For this piece of code, one can rewrite it correctly and much more performant in much less time. If the tool only drags you down, you'd better drop it.
- ohmygoodniche 2y ago
  The estimated run time of this code provided by another poster would have compelled me to seek alternatives as quickly as possible that's for sure...
- baq 2y ago
  Again, missing the point. You can. I can't. I don't want to. I don't care if it's slow, I can easily tell if it's correct and I can make the LLM fix incorrectness (in this simple case, anyway). The point is this project probably wouldn't have happened without an LLM.
  - bko 2y ago
    I'm reminded of the infamous hn comment when Dropbox was announced > 1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software. https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224
  - mpalmer 2y ago
    This "project" is a toy application that exists for no other reason than vibe coding evangelism. > You can. I can't. > I can easily tell if it's correct and I can make the LLM fix incorrectness (in this simple case, anyway). Pick one.
    - baq 2y ago
      I'm pretty sure black box testing is not a dark art around here.
      - bena 2y ago
        Getting the right answer with the wrong process is still a failure. So even if the result happens to be correct for the example you gave it, this process may not be able to produce correct results for other cases. Or even this case again. And if you can't understand the process, then you won't know when that happens. Now, if you're just trying to sell the result. I guess, no harm, no foul. When the process breaks, you'll be the one affected. That's fair play. But if you're trying to sell the process, you should be able to verify the process. Because otherwise you are selling a broken tool.
      - namaria 2y ago
        Are you just running code you don't understand to see what happens?
  - djmips 2y ago
    This project actually didn't happen even with the LLM.
- Jcampuzano2 2y ago
  Just a note that - 'one can' does not mean everyone can. And this can be applied between any two languages or tasks. An AI will simply have better broad knowledge than practically anyone at a task they are unfamiliar with so they can massively reduce the friction of getting started.
  - feverzsj 2y ago
    If you cannot exam the result, you better not touch anything LLM generated.
foolswisdom 2y ago
The sounds like exactly the point OP is making. The way LLMs are spoken about implies much more than actually demonstrated.
sksrbWgbfK 2y ago
> The point isn't and never has been that it's a flawless tool It's a contradiction with all the managers and vibe-coding developers that have been saying for months that it can replace 90% of a development team.
- Jcampuzano2 2y ago
  I'm going to go against the grain and say that AI could feasibly replace a very large percentage of most development teams, even today. Not because the AI itself could do all of the coding with no developers at all in the room, but the developers who do know how to use it effectively could output so much more than those who don't that they would more than make up for their lost productivity. Lots of companies have not yet fully embraced AI, and their developers are actually held back by not having access to it as a tool. But as someone who was recently given full access to sophisticated AI tooling, it makes a massive difference in my productivity. Lots of people don't like to hear this, but if you are not using AI today in some capacity, or your company is lagging in its adoption your career is at risk, especially if you are still relatively young. This said as somebody who originally was a massive AI skeptic, but decided to give it a shot. Yes, you still need to know how to code. That is not going away. But there will come a time when you yourself write an order of magnitude less code than you do today because you will become more of a reviewer than a developer yourself. Software development as a role will still exist, because in essence our job is to solve problems and build software, it just happens to be we write a lot of code to do that nowadays. But we will reach a breaking point where we don't write much of the code ourselves at all, maybe just some edits, and we review orders of magnitude than we do today.
  - ghuntley 2y ago
    > Lots of people don't like to hear this, but if you are not using AI today in some capacity, or your company is lagging in its adoption your career is at risk, especially if you are still relatively young. This said as somebody who originally was a massive AI skeptic, but decided to give it a shot. spot on - key reason behind authoring https://ghuntley.com/ngmi/ https://ghuntley.com/ngmi/ > Yes, you still need to know how to code. That is not going away. But there will come a time when you yourself write an order of magnitude less code than you do today because you will become more of a reviewer than a developer yourself. Software development as a role will still exist, because in essence our job is to solve problems and build software, it just happens to be we write a lot of code to do that nowadays. But we will reach a breaking point where we don't write much of the code ourselves at all, maybe just some edits, and we review orders of magnitude than we do today. spot on - key reason behind authoring this https://ghuntley.com/multi-boxing/ https://ghuntley.com/multi-boxing/ - I see a future where exactly that. SWE's spend more time reviewing code than artisanally crafting it by hand. Instead of the IDE we use today being the tool, it will become something only used exceptional circumstances. Instead, our primary tool will be a code review tool (that doesn't suck) that drives agents.

by baq 2y ago

feverzsj 2y ago

For this piece of code, one can rewrite it correctly and much more performant in much less time. If the tool only drags you down, you'd better drop it.

ohmygoodniche 2y ago
The estimated run time of this code provided by another poster would have compelled me to seek alternatives as quickly as possible that's for sure...
baq 2y ago
Again, missing the point. You can. I can't. I don't want to. I don't care if it's slow, I can easily tell if it's correct and I can make the LLM fix incorrectness (in this simple case, anyway). The point is this project probably wouldn't have happened without an LLM.
- bko 2y ago
  I'm reminded of the infamous hn comment when Dropbox was announced > 1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software. https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224
- mpalmer 2y ago
  This "project" is a toy application that exists for no other reason than vibe coding evangelism. > You can. I can't. > I can easily tell if it's correct and I can make the LLM fix incorrectness (in this simple case, anyway). Pick one.
  - baq 2y ago
    I'm pretty sure black box testing is not a dark art around here.
    - bena 2y ago
      Getting the right answer with the wrong process is still a failure. So even if the result happens to be correct for the example you gave it, this process may not be able to produce correct results for other cases. Or even this case again. And if you can't understand the process, then you won't know when that happens. Now, if you're just trying to sell the result. I guess, no harm, no foul. When the process breaks, you'll be the one affected. That's fair play. But if you're trying to sell the process, you should be able to verify the process. Because otherwise you are selling a broken tool.
    - namaria 2y ago
      Are you just running code you don't understand to see what happens?
- djmips 2y ago
  This project actually didn't happen even with the LLM.
Jcampuzano2 2y ago
Just a note that - 'one can' does not mean everyone can. And this can be applied between any two languages or tasks. An AI will simply have better broad knowledge than practically anyone at a task they are unfamiliar with so they can massively reduce the friction of getting started.
- feverzsj 2y ago
  If you cannot exam the result, you better not touch anything LLM generated.

foolswisdom 2y ago

The sounds like exactly the point OP is making. The way LLMs are spoken about implies much more than actually demonstrated.

sksrbWgbfK 2y ago

> The point isn't and never has been that it's a flawless tool It's a contradiction with all the managers and vibe-coding developers that have been saying for months that it can replace 90% of a development team.

Jcampuzano2 2y ago
I'm going to go against the grain and say that AI could feasibly replace a very large percentage of most development teams, even today. Not because the AI itself could do all of the coding with no developers at all in the room, but the developers who do know how to use it effectively could output so much more than those who don't that they would more than make up for their lost productivity. Lots of companies have not yet fully embraced AI, and their developers are actually held back by not having access to it as a tool. But as someone who was recently given full access to sophisticated AI tooling, it makes a massive difference in my productivity. Lots of people don't like to hear this, but if you are not using AI today in some capacity, or your company is lagging in its adoption your career is at risk, especially if you are still relatively young. This said as somebody who originally was a massive AI skeptic, but decided to give it a shot. Yes, you still need to know how to code. That is not going away. But there will come a time when you yourself write an order of magnitude less code than you do today because you will become more of a reviewer than a developer yourself. Software development as a role will still exist, because in essence our job is to solve problems and build software, it just happens to be we write a lot of code to do that nowadays. But we will reach a breaking point where we don't write much of the code ourselves at all, maybe just some edits, and we review orders of magnitude than we do today.
- ghuntley 2y ago
  > Lots of people don't like to hear this, but if you are not using AI today in some capacity, or your company is lagging in its adoption your career is at risk, especially if you are still relatively young. This said as somebody who originally was a massive AI skeptic, but decided to give it a shot. spot on - key reason behind authoring https://ghuntley.com/ngmi/ https://ghuntley.com/ngmi/ > Yes, you still need to know how to code. That is not going away. But there will come a time when you yourself write an order of magnitude less code than you do today because you will become more of a reviewer than a developer yourself. Software development as a role will still exist, because in essence our job is to solve problems and build software, it just happens to be we write a lot of code to do that nowadays. But we will reach a breaking point where we don't write much of the code ourselves at all, maybe just some edits, and we review orders of magnitude than we do today. spot on - key reason behind authoring this https://ghuntley.com/multi-boxing/ https://ghuntley.com/multi-boxing/ - I see a future where exactly that. SWE's spend more time reviewing code than artisanally crafting it by hand. Instead of the IDE we use today being the tool, it will become something only used exceptional circumstances. Instead, our primary tool will be a code review tool (that doesn't suck) that drives agents.