Well because your provider assumes you are not using all your bandwidth constantly. Cloud bandwidth is only billed for you actually use
535 karma · joined April 5, 2022
Well because your provider assumes you are not using all your bandwidth constantly. Cloud bandwidth is only billed for you actually use
"Review quality and fix" doesn't mean a lot without context.
Does it mean to remove unused features and simplify the underlaying code? Does it mean changing the data structures to better support future development? Does it mean improving performance because of bottlenecks?
You are supposed to tell an LLM what your codebase needs, but if you just vibe code without knowing the code, "review quality and fix" will have unexpected results
If in 10 years the ratio moves from 70/6 to 50/26, the situation will be vastly different.
The options are not black and white
Which is a bummer because it is a complete different point of view from the more typical user experience
The discussion about building European alternatives had never been so mainstream. If and once they emerge, I think the shift will happen. But let's see
Single prompting a very complex tasks is rare even on frontier models, because it can be done successfully only for specific situations (e.g. you have a very strong verification step the model can iterate on).
Most of my everyday usage is for smaller takes, were you don't really get the benefit of the most expensive models, and my guess is that is the case for the most users
To me the most probable explanation is that they automated a way to find (and fix) existing vulnerabilities in a way that was not possible before.
Some holes were probably very small, some were probably almost impossible to actually exploit, I don't doubt it. But still, I find it very hard to not consider this a strong security improvement overall (unless they made those numbers up)
If, in the amount of data they ingested, there was a clear pattern of responding in an hasty and carefree way to frenetic questions, LLMs will try more hasty and carefree solutions to a frenetic prompt.
You can decide whether you can say that they "feel" the urgency or not, but the outcome is very much the same
Of course it is an advantage. I tend to access most of my apps and services from both the PC and the smartphone, having data shared across the two is a deal breaker for the very vast majority of them.
Code exploration tends to burn a ton of tokens and do not require frontier knowledge. It then returns a compact overview of the findings to the better model, that can therefore perform its task with less tokens.
Anyone else has a similar approach?
Is it at least comparable to the $10k of cost?
That aspect is probably more important for an open model then the source materials
Compared to some available Chinese model I guess. For most common tasks the additional intelligence is marginal and the cost is around an order of magnitude higher.
It is very different with plaintext
You also open the gates to many edge cases where I don't know what it is supposed to happen.
What if I never paste the cut text? Does it stay faded?
What if I copy some other text, maybe on another app, before pasting? Do I paste the faded text or the new copied one?
Also, as you mention, I hate that you can't paste on a different program given the fact that the clipboard is untouched when you press ctrl-x
The gain is so minimal for a lot of headaches if you don't follow the happy path
It is the reinforcement learning that produces more tangible results with less data, but it is something that the AI labs specifically selects and it is not picked up unknowingly
> Yeah if I'm not mistaken the ticketing service is deployed on t56kl-293d1-5gqp7, do you think we should move it to iwi49-oaqq0-492fa?
I believe this is the key difference, because it doesn't make sense to learn such a complicated tool for a simple use case.
If you already know it sure, it may make sense. But you are removing a huge initial effort required otherwise.
There are two clearly demarcations both north and south
Isn't this solved if you squash the commits when merging the PR? I personally don't care that much about the commits inside a PR, the are just temporary because when a PR is merged they are squashed and you only get one commit for the whole feature on the main branches