I don’t work at a dating company, but I do work in machine learning applications.
My best guess is this: they are not optimizing for good vs great matches, and they are probably not even building a model of what that would even mean, not even trying to represent the concept in their algorithms.
Most likely they are optimizing for one or more metrics that are easy to measure and hence optimize, and these metrics have the side effect of producing an excitement for the user without actually pairing them up.
I think this problem existed before AI. At least in my current job, there is constant, unrelenting demand for fast results. “Multi-day deep thinking” sounds like an outrageous luxury, at least in my current job.
My feeling is that AI-generated code is disposable code.
It’s great if you can quickly stand up a tool that scratches an itch for you, but there is minimal value in it for other people, and it probably doesn’t make sense to share it in a repo.
Other people could just quickly vibe-code something of equal quality.
- Is the work easier to do? I feel like the work is harder.
- Is the work faster? It sounds like it’s not faster.
- Is the resulting code more reliable? This seems plausible given the extensive testing, but it’s unclear if that testing is actually making the code more reliable than human-written code, or simply ruling out bugs an LLM makes but a human would never make.
I feel like this does not look like a viable path forward. I’m not saying LLMs can’t be used for coding, but I suspect that either they will get better, to the point that this extensive harness is unnecessary, or they will not be commonly used in this way.
Don’t automation technologies improve the productivity of labor?
If I can make one widget per hour, and some new tool lets me make 10 widgets per hour?
Conventional economic theory suggests the gain will be split between the widget-maker and the widget-consumer, in proportions determined by the relative slopes of the supply-demand curves, but definitely the product will become somewhat cheaper.
At my work we have a jit compiler that requires type hints under some conditions.
Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess.
For example a common failure mode in my work’s codebase is that some function will take something that is indexable by ints. The type could be anything, it could be List, Tuple, Dict[int, Any], torch.Size, torch.Tensor, nn.Sequential, np.ndarray, or a huge host of custom types! And you better believe that every single admissible type will eventually be fed to this function. Sometimes people will try to keep up, annotating it with a Union of the (growing) list of admissible types, but eventually the list will become silly and the function will earn a # pyre-ignore annotation. This defeats the whole point of the pointless exercise.
So, if the jit compiler needs the annotation I am happy to provide it, but otherwise I will proactively not provide any, and I will sometimes even delete existing annotations when they are devolving into silliness.