Ha thanks, it was pink a while ago

Extreme programming in a nutshell. I like doing this to features: build it, then take it down and rebuild but better.

"Plan to throw one away. You will anyway."

Thanks! This is very similar indeed. Related: I see a lot of “drive-by” PRs by agents, who obviously have no intent of ever maintaining the code they wrote.

Puppy cannons. Puppy carpet bombing.

A new definition of "puppy mill."

Puppy slush automatically pushed through vents into your codebase

I’m not sure I share your view of PRs. I still see submitting PRs as something that puts pressure on maintainers. Even incorrect PRs take time to verify and review.

I also don’t see how this differs between the “gap” and the “fence” part of the metaphor. Whether someone submits a rewrite/removal (fence) or a new feature (gap) for PR review, it’s still going to cost me attention.

It's only pressure if you believe the social contract in a PR is that everything that is written is something you're obligated to read / respond to. If you flip that a bit to a PR being the first step in a way of saying "I tried a thing and it worked, what's necessary to make that an actual thing that other can use", then you will sort of land here.

Previously I wrote https://news.ycombinator.com/item?id=48517931

Saying your quoted words is a request for someone to read and respond; it's still pressure and a burden.

It’s an interesting question: I’d say this is more of a vulnerability creator than the actual vulnerability.

Similar to how using very difficult technologies makes you more likely to create code with vulnerabilities: the technologies are not the vulnerability, but it’s easier to cause them.

This paper oversells on the title. Like, what is chronos, which embedding model was used, which reranker, how was the reranking done, why is chronos much better than claude code

Because it destroys the economics of scraping. It’s too expensive with proof of work, or at least not as economically viable

Depends on what type of scraping you're trying to stop. For the dumb scrapers that would try to scrape every page on a git forge (for which there are a bazillion pages for a modest project, because of how the site works), yeah it might deter them enough to stop. For anything high value (eg. reddit comments or retail prices), 10s of cpu time isn't going to stop them.

It will not scare away bots but 10 seconds of wait (CPU or only a sleep) will turn away many real users. "This site is so slow, I'll use something else." A kind of reverse captcha.

Maybe, the proof of work can run in the background.

Or it can run as part of a checkout wizard's "verifying your browser and processing your payment, don't close your tab" step.

At which point it exists solely to punish real human users? What scraper bot is going through checkout?

The credit card tester bots go through the checkout process.

PoW wouldn't be a big issue for them though since their volume is much lower.

Sure, the whole premise is exactly that proof of work reduces the value of scraping, while having negligible impact on users. If the data is so valuable that bot operators are willing to pay 10s of cpu, then other measures are necessary.

Nevertheless even for these high value cases, you can still argue that it disincentivizes the business model, it becomes less efficient.

If it's high value, there isn't really much you can do that will be completely effective. Traditional captchas can often be beaten by AI, or by "captcha farms" where impoverished people are paid pennies to complete captchas. Fingerprinting can be beaten by using a full browser to make the requests. Basically anything you do is just a matter of making it more expensive for bots to access it.

Beating fingerprinting and beating traditional captcha is far more expensive than solving pow. Pow doesn't stop anyone, not even the most novice bot operators

You can just download all of Reddit from torrent sites

5W load for 2 seconds is 0.002Wh, I think we'll be fine

Except it doesn't

I was also at the event and was pretty disappointed. Most of the talks were pretty low on information. I was at the “build” stage, which supposedly was the technical stage, but the talks there didn’t really go into technical specifics.

The papyrus talk was awesome though.

It's not probabilistic, and exact matches will always be preferred over non-exact. So if you search for a function name this will surface it.

This is a bit rude.

We didn't generate this project, we wrote it, a lot of it manually, and trained custom models. We'd been working in the real-time retrieval space for a while, and we thought coding was a good fit for this specific technology.

My comment above wasn't meant to be rude. And you do have extensive benchmarks against grep etc so it's clear you understand the importance of that.

But I still think you're missing the harder but more important proof which is agent evals. Have you done any of that?

I would personally love to find tools in this space which can make agents more efficient and I do believe there's a scope for massive improvements compared to default workflows. But my evals with RTK and Headroom have made me wary that a tool can look like it should work, conceptually make sense, pass non-agentic benchmarks, and still make an actual agentic workflow worse.

It was directed at the parent who implied that we didn’t think about this.

I agree with your point about the evals and how you can get discontinuities: good search can be worse than bad search when agents can do many searches. We’re working on it

When you share them, please also share the setup for people to easily rerun them. Nearly every eval I've seen shares the llm session transcript but not the actual harness setup etc. that they used.