Maybe I'm too far gone down the AI rabbit hole, but that seems a really strange take to have. If you replaced 'back and forth with the AI' with 'pair programming' or 'brainstorming' this phrase would be really strange, after all these are all techniques to sharpen your ideas. Even 'rubber ducking' is widely accepted as an effective way to go through a problem, and you can definitely use AI as a rubber duck.

For me the idea of chatting with the AI about a problem/solution is just another tool to help us work. It's not the best solution because it has a lot of downsides you should be aware while using it, but that is true for any technique including 'writing the code yourself'.

While I agree with the intent of this law, I don't think it will be effective. If you have a system capable of jacking prices up you can just multiply this calculated delta by -1 transform that into a discount.

To effectively prevent this practice you probably need to ban any kind of personal discount. I don't think we will ever see such law, nor do I think this would be a good idea.

I think a lot of people don't realize the power of a big enough sample size. With enough samples even something pretty innocent looking like your daily step counter could make you identifiable.

As far as I know we don't have large enough databases to make this happen in practice, but I don't think this is impossible in the future.

I have nothing to back that up, but I wouldn't be surprised if this is a feature. If these luxury items are being used by the society (or at least in some circles) as a proxy for 'success'(ie having enough disposable money) it probably would be better if they we also quite fragile. This way you could distinguish between someone who received a expense gift vs someone that has money to always keep buying new items.

I'm not sure how real it this, but I've read somewhere that part of the appeal of expensive glassware was the fact that it was pretty fragile. Serving someone at your house with expensive glassware was a way to tell 'look how much money I've got'.

Just to be clear, I don't think we should get impressed/try to impress people by how much money someone has. But that is a practice as old as time, and it doesn't seem to be going away any time soon.

Let me put it in another way, imagine we find clay in an asteroid. Does that alone imply the existence of ceramic in other places of the universe?

We need these molecules to build build a DNA strand, but their existence doesn't imply the existence of other life forms. Maybe exists a process that produce these molecules naturally and we just don't know about yet.

And remember that life(self replicating organisms) is way more complex than just DNA/RNA. In another crude analogy you could say that DNA is just the source code, to have life you still need to have all the hardware to run this code on. (fun fact: that is the reason why people argue about virus being something alive or not. Generally it has only the RNA necessary for the replication, and this is why it can only reproduce if it is able to take over another cell. In this analogy it has the source code but not the hardware, so how do we classify it?)

I don't think this conclusion is correct. The abiogenesis/panspermia debate is about where life formed. This article only says "we found all the DNA/RNA bases in an asteroid," but there is a HUGE gap between DNA bases and life(ie self-replicating organisms).

Making a crude analogy you could say they found Lego pieces in the asteroid, but that doesn't imply that the first 'Lego kits' on earth came pre-assembled. They might, or might not. We don't really have enough information to get a definitive conclusion. What we know is that we can't discard the panspermia idea yet.

But with each passing day we see the opposite, more and more people are converging in one of a few opinions about each topic. This is great if you want to move the world in a specific direction, but I think it demonstrates that people are exercising less their critical thinking abilities.

AI definitely made this worse, but I think it started long before that.

Another factor that I think contributes negatively to this effect is that our society doesn't really like when someone is wrong, or changes ideas. If we want to encourage to use their critical thinking skills we also need to tell them that arriving at bad conclusions is ok, the important thing is to always keep improving.

And the chance of losing at least once in a 99% sure bet after 100 rounds is around 60%. Even if you reduce to 30 rounds it still is around 30%.

This may seem smart at first glance, but the math doesn't really checks out.

I've been thinking about it lately and I think you are right. LLMs haven't changed what is 'good software'. But they changed some proxies I used to have for what is 'good software'.

In the past I've always loved projects that had good documentation, and many times I've used this metric to select a project/library to use. But LLMs transformed something that was (IMHO) a good indicator for "care"/"software quality" into something that is becoming irrelevant (see Goodhart's law).

Pressing C-z on neovim puts me back in the terminal so I can do whatever I need to do and when that is done I just type 'fg' in the terminal and it opens up my neovim again, exactly as it was.

What I do is to use the LLM to ask a lot of questions to help me better understand to problem. After I have a good understanding I jump into the code and code by hand the core of the solution. With this core work finished(keep in mind that at this point the code doesn't even need to compile) I fire up my LLM and say something like "I need to do X, uncommited in this repo we have a POC for how we want to do it. Create and implement a plan on what we need to do to finish this feature."

I think this is a good model because I'm using the LLM for the thing it is good at: "reading through code and explaining what it does" and "doing the grunt work". While I do the hard part of actually selecting the right way of solving a problem.

But I agree with you, when reading PR descriptions and code comments I want a "why" not a "what". And that is why I think most LLM-generated documentation is bad.

I don't think it is practical because it means for every new chunk you embed into your database you need to first compare it with every other chunk you ever indexed. This means the larger your repository gets, the slower it becomes to add new data.

And in general it doesn't seems like a good approach because I have a feeling that in the real work is pretty common to have quite significant overlap between documents. Let me give one example, imagine you create a database with all the interviews rms (Richard Stallman) ever gave out. In this database you will have a lot of chunks that talk about how "Linux is actually GNU/Linux"[0], but this doesn't mean there is anything wrong with these chunks.

I've been thinking about this problem while writing this response and I think there is another way to apply the idea you brought. First, instead of doing this while you are adding data you can have a 'self-healing' that is continuously running against you database and finding bad data. And second you could automate with a LLM, the approach would be send several similar chunks in a prompt like "Given the following chunks do you see anything that may break the $security_rules ? $similar_chunks". With this you can have grounding rules like "corrections of financial results need to be available at $URL"

[0] - https://www.gnu.org/gnu/incorrect-quotation.html

Comments URL: https://news.ycombinator.com/item?id=47362277

Points: 3

# Comments: 0

I think you should consider putting this information in your site. I always read "we don't support Firefox" as "we are lazy", but that's not always the case.

In my experience receiving e-mails is easy, you just need to deal with some spam. But reliable e-mail delivery can be tricky, especially if you don't send a lot of e-mails regularly.

No, I don't think this is compelling enough to try it at work.

> By the way, if you don't mind, how often do you have to run that type of recovery?

I would say we use this feature once every 3 months.

I don't really see what problem this solves. If you have proper timeouts and circuit breakers in your service this shouldn't really matter. This solution will save a few hundred requests, but I don't think this really matters. If this is a pain point its easier to adjust the circuit-breaker settings (reduce the error rate, increase the window, ...) than introduce a whole new level of complexity.

> Curious how you handle the recovery side

We have a feature flag provider built in-house. But it doesn't support this use-case, so what we done is to create flag where we put the % value we want to bring back and handle the logic inside the service. Example: if you want to bring back 6,25% (1/16) of our users this means we should switch back every user that has an account-id ending in 'a'. For 12.5% (2/16) we want users with account-id ending either in 'a' or 'b'. This is a pretty hacky solution, but it solves our problem when we need to transition from our fallback to our main flow.