Hacker Newsnew | past | comments | ask | show | jobs | submit | prash20026's commentslogin

> frequently contains all too plausible nonsense, and is increasingly jargon dense.

Does anyone know how to deal with the jargon part? It is getting hard to use claude and even worse when someone sends you the direct output from claude.


As with most things LLM, you can generally get what you want by asking for it (maybe not efficiently, but so it goes). "Once you have a answer, please summarize, and ask an agent to convert it to plain English" often helps.


I'm adding "ELI8" (explain like I'm 8 years old) to the end of my prompts a lot. It helps.


Why ELI8 and not the ubiquitous ELI5?


Funny. Because I was not aware of that acronym and only saw "ELI8" when I prompted "explain like I'm eight years old".


Ask it to create a small sample to reproduce the issue in isolation. If it can't reproduce the performance changes then it drops it.

That might work better. I haven't tried it with SQL but it worked with a few complex UI issues I had. It identified the actual issue after a few false starts.


Apple might be a good counter example of what happens if you don't focus entirely on AI. Right now it seems to be doing ok.


Apple can enjoy because it controls a significant fraction of consumer computing platform so they can simply collect tax from everyone else. This is not true for the rest of big tech. Only Google has Android but it cannot sit and enjoy because they still don't control hardware and AI is an existential problem for their search business.


Supposedly 70% of software projects failed even before AI. So are AI projects better or worse than that?

Also like people have asked about the 70% failure rate, how do you define failure/success.

https://medium.com/@trienpont/why-do-over-70-of-software-pro...


> Supposedly 70% of software projects failed even before AI.

Given the way LLMs are marketed, we should expect a vastly more favorable project success rate, not simply a close parity, and definitely not a decreased rate.

Even if we consider that the number of attempts will rise if development becomes faster, we're told to expect a greater number of projects should also succeed because they're easier. They're supposed to justify the higher costs.

It's reasonable to ask if that's the case.


> Given the way LLMs are marketed, we should expect a vastly more favorable project success rate, not simply a close parity, and definitely not a decreased rate. > Even if we consider that the number of attempts will rise if development becomes faster, we're told to expect a greater number of projects should also succeed because they're easier.

I'm not sure I follow why you would think this. Prior to AI was the reason most projects failed because generating the code was too slow or too labor intensive? That would be surprising to me if it was true.


Generating code is not, and never was, a bottleneck to projects. Understanding the problem, designing a solution, organizing resources, testing, and customer buy-in and moving targets have always represented the real issues.

Now, with LLMs, we're supposed to be able to paper over some or all of these problems.

They're supposed to be able to understand and intuitively fill the assumptions present in vague requirements, then produce working applications. They're supposed to shrink the timelines from years and months to weeks and days. They're supposed to replace human expertise with a reliable service.

Why else would I hire an LLM service over a team of humans?


> They're supposed to be able to understand and intuitively fill the assumptions present in vague requirements, then produce working applications. They're supposed to shrink the timelines from years and months to weeks and days. They're supposed to replace human expertise with a reliable service.

But none of those sound like things that would change how likely any given project is to succeed. Shrinking timelines from years and months to weeks and days just means that you can fail faster and try again sooner (hopefully with lest costs), but nothing about that implies your rate of success is going to get better.


I think the point is that using an LLM is not really going to shrink project timelines by that degree.

Most large software projects I've worked on in a professional environment, "writing the code" was one of the fastest and smallest parts of the project. Maybe 10% of the overall calendar time of any given project was "designing and typing in software." The bulk of time spent tends to be working with customers, researching and refining requirements, reviewing the requirements with execs and leads to get their buy-in and support for staffing the project, performing various non-engineering reviews like legal and privacy, aligning timeframes among multiple contributing teams, seeking approval from Director X to move on to the next project phase, waiting for Key Team Member Y to get back from vacation, conducting QA and field testing, soaking the software through various rollout stages like internal, dogfood, internal staging, external beta, and then incremental percentages in prod, while watching and waiting for any regressions or failures. On a project that takes 6 months from idea to 100% in-production, writing the code might take a few weeks of that.

So why are we so focused on a tool that speeds up the smallest part of this process?


Faster and cheaper.


Hasn't OpenAI being doing it for a while too?

https://news.ycombinator.com/item?id=48465269


The common denominator between "GPT-2 is too dangerous to release" and Anthropic is Dario.


Sam Altman was doing interviews talking about p(doom). They all were requesting regulation just not this opaque ad hoc kind.


Ironically, Google is the company I'd prefer to have the frontier models.


Just as a counter example, Midjourney is completely self funded and profitable. But they are images, LLMs might be more expensive to train but their inference is cheaper.

So the frontier model companies might have crazy valuations and they might never reach that. But that might not mean they are actually unprofitable.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: