I really love the idea of "View source" for base prompts.
If we simply treat the prompts as frontend / client-side (one could even argue that it can be harder to get the original code from a JS bundle than extract a prompt using prompt injection), then function calling (the backend API) could be where folks add additional value, and if reasonable, charge for it.
As long as you can audit the function calls and see what's sent and received, same as you can do with a browser, then I think it becomes closer to a familiar and well-tested model.
The core value of code reviews is knowledge transfer and increased harmony across the codebase.
You certainly don't want to work in a codebase riddled with different ways of doing the same thing. Code reviews help with making the patterns more structured and more widely adopted. It also helps everyone at all skill levels to learn something from their peers, through reading their code and sharing thoughts.
It also makes more people in the team familiar with the codebase, such that more people are capable of changing and improving the related parts rather than just the original author.
The potential benefit of finding defects is only a nice to have!
My thoughts exactly. It's impressive that despite relying on BFS, the tool manages to be so fast on a tiny node on google cloud. Even when there's a depth of >= 5 !
As you say, a big win by text is that you can quickly skim it, ignore parts of it that you don't deem to be relevant, and essentially only use the working/short-term memory for the information you are interested the most in the context. Therefore, if the device responds back to you in voice, even if it's entirely a human-like experience, that's still inferior (at least in terms of speed) compared to the text-based experience.
Even for using voice as an input-only mechanism, it's still going to contain lots of redundant/useless information and verbosity.
Compare "OK google, what is the price of bitcoin today?" vs goolging "bitcoin price".
Really happy for GitLab and wish you guys all the best (and luck).
We've been using Gitlab for all our company's development, however, one major issue that is pushing us to switch over to GitHub is the fact that GitLab goes down almost every other day (or sometimes every day) due to deployments. Although during this often the site remains available, when CI is not executed or triggers are not performed, it is still extremely disruptive. I really hope that you prioritise having disruption-free deployments.
Is it possible to present a resized version of the route to each path underneath each target? (or perhaps show that on hover)
I understand that this would mean having overlapping map snippets of different sizes (with different centres), but some visual representation of the route to take could be nice.
Currently, the UX of having to click each target to see the path reduces the usability (having to go back and forth between the suggestions is tedious).
Just installed Nightly thinking "how can it be any different from the Developer Edition?" ... Wow, I couldn't be more wrong!
It is indeed a night and day experience! More approachable UI, and much faster performance... Big well-done to everyone working hard to keep Firefox competitive :-)
Still, as far as I understand it, it comes down to how good/competent the IT dept is at log-keeping, and how complicit they are in the forgery.
In a more broader way, how can one prove innocence if their company use the employee's credentials (ID/email/etc.) to drop the blame on them? Wouldn't it be the employees words against the employer, while at the same time the employer has the control over the data/evidence?
Nevertheless, it does pose a more general question. Given that in many workplaces the employer has access to your work email/account, how can one prove that he/she did not send a particular email?
I think, while it may not be out of the goodness of Zuckerberg's heart, it's the cost of keeping the Facebook monopoly. That, and the $19B they initially had to fork out.