Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> The biggest problem with all current codegen systems is the speed of generation

I don't see this complained about nearly as much as I'd expect. Groq has been out for over a year, I'm surprised OpenAI not acquired them and figured out how to 10x to 20x their speed on gpt4.



Yeah I don't agree. I'm building a product in the space, and the number one problem is correctness, not latency.

People are very happy to sit there for minutes if the correctness is high and the quality is high. It's still 100x or 1000x faster than finding 3rd party developers to work for you.

I wish the models were getting better but recently they've felt very stuck and this is it, so agent architectures will be the answer in the short term. That's what's working for us at srcbook rn.


I think the logic behind faster inference is that the LLM is unlikely to get it right the first time regardless of its intelligence simply due to the inherent ambiguity of human language. The faster it spits out a semi-functional bit of code the faster the iteration loop and the faster the user gets what they want.

Plus if you’re dealing with things like syntax errors, a really really fast llm + interpreter could report and fix the error in less than a minute with no user input.


Also building something in this space. I think it’s a mistake to compare the speed of LLMs to humans. People don’t like to sit and wait. The more context you can give the better but at some point (>30 seconds) people grow tired of waiting.


yes, people are used to clicks / actions taking < 200ms, when something takes 20s+, it feels broken even if the results are good.




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

Search: