Language is really powerful, I think it's a huge part of our intelligence.
The interesting part of the article to me is the focus on fluency. I have not seen anything that LLMs do well that isn't related to powerful utilization of fluency.
I don't think changeable code is the number one priority. The goal is to solve a problem and code that solves a problem without needing to change is sufficient.
Code that doesn't need to change is a really good sign that you've got something good.
In the article the author mentions wanting to benchmark a GPU and using ChatGPT to write CUDA. Benchmarks are easy to mess up and to interpret incorrectly without understanding. I see this as an example where a subtly-wrong idea could cause cascading problems.
Who is doing this and where can I read more? What are the tradeoffs?
I imagine that you get a a dataset that is significantly smaller but it is much trickier to keep a dataset in memory the way you could with MySQL.
It's like having a free implicit index on the customer (because you had to lookup the sqlite db file before you could start querying).
I spend a lot of time thinking about tenancy and how to handle it. Tenancy is such a common problem.
Performance is the number one reason tickets are hard to estimate. The second in my experience is security.
Time and tenancy are the number one opportunities for SQL to just be better (I always need tenancy and my Order By or at least one constraint can typically be satisfied with time).
Whenever I am in that expedient hack mode I've started commenting to explain my dilemma. My most valuable comments typically come out at that time.
Such and such can't be done right now because of such and such.
Often it doesn't matter if I ever resolve those comments or solve that problem I hacked through. The value comes from avoiding the rabbit hole next time.
It just depends on the business, b2b can be very consistent. Some workloads just have predictable behavior.
I worked at a medium sized place where we had plans in place to handle the workload for our entire market on-prem (if we were ever to capture that market).
We realized that horizontal scalability wasn't important to us because we had enough of the market to know that the other half of the market could be supported on our existing solution.