3 ms·
This article is really only useful if LLMs are actually able to close the gap from where they are now to where they want to be in a reasonable amount of time. T
by rkozik1989 1y ago
This article is really only useful if LLMs are actually able to close the gap from where they are now to where they want to be in a reasonable amount of time. There are plenty of historical examples of technologies where the last few milestones are nearly impossible to achieve: hypersonic/supersonic travel, nuclear waste disposal, curing cancer, error-free language translation, etc. All of which have had periods of great immediate success, but development/research always gets stuck in the mud (sometimes for decades) because the level complexity to complete the race is exponentially higher than it was at the start.
Not saying you should disregard today's AI advancements, I think some level of preparedness is a necessity, but to go all in on the idea that deep learning will power us to true AGI is a gamble. We've dumped billions of dollars and countless hours of research into developing a cancer cure for decades but we still don't have a cure.
- BinaryIgor 1y ago100%; Exactly as you've pointed out, some technologies - or their "last" milestones - might never arrive or could be way further into the future than people initially anticipated.
- bgroat 1y agoWe're 90%... we're almost half way there!
- germandiago 1y agoExactly this.
- HumblyTossed 1y agoIt costs 10% to get 90% of the way there. Nobody ever wants to spend the remaking 90% to get us all the way there.
- dakiol 1y agoIn software we are always 90% there. Is that 10% the part that gives us jobs. I don’t see LLMs that different from, let’s say, the time compilers or high level languages appeared.
- bpt3 1y agoUntil LLMs become as reliable as compilers, this isn't a meaningful comparison IMO. To put it in your words, I don't think LLMs get us 90% of the way there because they get us almost 100% of the way there sometimes, and other times less than 0%.
- Jensson 1y agoCompilers reliably solves 90% of your problems, LLM unreliably solves 100% of your problems. So yeah, very different.
- bluefirebrand 1y agoIf it's not reliable then the problem is not solved You've just moved the problem from "I can't solve this" to "I can't trust if the LLM solved this properly"
- CamperBob2 1y agoIf it makes money, the problem is solved. At least from the perspective of the people with the money. Less cynically, it doesn't matter whether some code was written by a human or an LLM -- it still has to be tested and accepted. That responsibility ultimately must end up on a human's desk.
- deleted 1y ago[deleted]
- nomel 1y agoThere is a level of reliability that is sufficient, as proven by us humans, the existence of issue trackers, and the entire industry that is software QA. And, further, the existence of offshore, low quality, contractors that are in such frequent use.
- jrecyclebin 1y agoI'm already not going back to the way things were before LLMs. This is fortunately not a technology where you have to go all-in. Having it generate tests and classes, solve painful typing errors and help me brainstorm interfaces is already life-changing.
- xp84 1y agoI am in a similar place, I think, to you. Caveat: I don't spend a lot of my day-to-day coding anyway, so that helps, but I've never even tried Cursor or Windsurf. I just poke copilot to write whole functions, or ask ChatGPT for things that seem like they'd be tedious or error-prone for me. Then I spend 3-5 minutes tying those things together and test. It saves about 80% of the time, but I still end up knowing exactly how the code works because I wrote most of the function signatures and reviewed all the code. I know in the very right circumstances the "all-in" way could be faster, but it's already significant that I can do 5x as many coding tasks or do one in a fifth the time. Even if it never ever improves at all.
- derefr 1y agoI would argue that "augmented programming" (as the article terms it) both is and isn't analogous to the other things you mentioned. "Augmented programming" can be used to refer to a fully-general-purpose tool that one always programs with/through, akin in its ubiquity to the choice to use an IDE or a high-level language. And in that sense, I think your analogies make sense. But "augmented programming" can also be used to refer to use of LLMs under constrained problem domains, where the problem already can be 100% solved with current technology. Your analogies fall apart here. A better analogy that covers both of these cases, might be something like grid-scale power storage. We don't have any fully-general grid-scale power storage technologies that we could e.g. stick in front of every individual windmill or solar farm, regardless of context. But we do have domain-constrained grid-scale power storage technologies that work today to buffer power in specific contexts. Pumped hydroelectric storage is slow and huge and only really reasonable in terms of CapEx in places you're free to convert an existing hilltop into a reservoir, but provides tons of capacity where it can be deployed; battery-storage power stations are far too high-OpEx to scale to meet full grid needs, but work great for demand smoothing to loosen the design ramp-rate tolerances for upstream power stations built after the battery-storage station is in place; etc. Each thing has trade-offs that make it inapplicable to general use, but perfect for certain uses. I would argue that "augmented programming" is in exactly that position: not something you expect to be using 100% of the time you're programming; but something where there are already very specific problems that are constrained-enough that we can design agentive systems that have been empirically observed to solve those problems 100% of the time.
- CuriouslyC 1y agoLLMs are noisy channels. There's some P(correct|context). You can increase the reliability of noisy channels to an arbitrary epsilon using codes. The simplest example of this in action is the majority decoding logic, which maps 1:1 to parallel LLM implementation and solution debate among parallel implementers. You can implement more advanced codes but it requires being able to decompose structured LLM output and have some sort of correctness oracle in most cases.
- derektank 1y agoThere are no technical hurdles remaining with respect to nuclear waste disposal. The only obstacle is social opposition
- golemotron 1y ago..and regulation. The same with supersonic.
- Frieren 1y ago> There are no technical hurdles remaining with respect to nuclear waste disposal. That is very inaccurate. There are still a million problems to solve. nuclear waste is extremely dangerous. Even "normal" trash has been proven dangerous and difficult to get rid of with landfills leaking dangerous materials into ground water. Accumulating nuclear waste for millennia hopping that nothing goes wrong is far from a proven solution. People cannot trust a solution when all concerns for people safety are disregarded.