That’s an API design question. What is the more common use case.
You seem to suggest they did it for benchmarking reasons only. They could use the option there themselves without changing the default so that is unlikely to be the motivation.
Good, you achieved a 10% speedup for a particular workload that some users said they care about. But how do you find out that was really the feature that should have been built next? How do you prevent adding badly factored code? How to make sure you don't pile on top of existing tech debt in the codebase, that you are solving the most fundamental issues first?
I think a sufficiently smart non-competent developer can still do this to great effect, but it definitely helps if someone is both a competent developer, smart, and a seasoned user of LLMs.
Just because AI is not yet a god that is better than all humans at creativity and product decisions and design does not mean it is not a huge accelerant right now.
I went to VB.NET first using a previous generation of LLM's (that was quite manual back then) and then from VB.NET to C# or just keeping the VB.NET around worked very well. The code was not highly complex but more than just CRUD. The porting from VB6 to VB.NET included building tests which helped.
I'm still managing to add more features, such as multithreading. The LLM's do make mistakes but they have gotten better and they tend to self correct these days. I'm also comparing results to mature products such as Polars and DuckDB and the results match.
Zero. I don’t think that implies the product is bad though. I haven’t marketed it much yet and I’m not great at it either. Even if it is marketed well, integrating the tool into existing workflows would take some effort. This has nothing to do with the suitability of LLMs though.
reply