benjamincburns

I'd be shocked if it wasn't a shotgun strategy learned during RLHF or RLVR post-training.

A short response that's wrong is going to be punished, whereas a long answer that contains the correct information, and then a whole bunch of other stuff surrounding that info, is more likely to be rewarded. Even if you discount the reward by answer length, when there's ambiguity involved it's still going to be a better strategy on average to hedge by saying too much vs risking saying too little.

I wasn't alive in the 70s, but I still prefer a terminal.

I can string together a complex series of text-related tasks far more effectively as a shell pipeline than I can by pointing and clicking in a UI. I can scale that sequence of tasks out to operate on every file on the filesystem if I want, or down to a single character in a single file.

Claude Code being a full-featured TUI is also helpful because I can quickly/easily use it remotely via SSH without having to deal with setting up X forwarding, VNC, Parsec, etc. The remote host doesn't even need to have a window manager. Sure, it'd be nice if it also had an elegant multi-page GUI so I could more easily drill into the actions its performing and make better use of my large screen to watch it do multi-agent things, but if I have to choose between the two, I prefer the TUI.

That said, I'd much rather use a GUI to do things that are actually visual/spatial in nature.

But can you paste an image into it?

I have a similar setup, but I access it directly via iTerm2 instead of VS Code's terminal. I've figured out the right terminal settings to get copying/pasting text to work (including with neovim's + register), but not images. Would be nice to paste images, though. Currently I have to SCP them over.

I don't think it's factually correct.

There are context pruning strategies that will prune old messages that are no longer relevant, and context compaction from summaries, etc. But to say "most" do this on "every turn" is overstating things. I think it's more correct to say that "many" do this "occasionally."

I'm also not sure what they mean about injecting fresh timestamps. I could see why you'd prepend/append a timestamp to the user's messages to make the model aware of the current time, and the passage of time, but I can't think of any good reason to edit timestamps in prior messages. I'm sure someone can come up with one, but I'd be very surprised if this was a thing that most agent loops do, let along doing it on every turn.

IIRC Anthropic's API produces cryptographic signatures for thinking blocks. If you try to submit a set of messages that include thinking blocks with missing/invalid signatures, it'll refuse.

They do this to mitigate jailbreak attempts that rely on fabricated message history (e.g. making it look like the model was compliant in previous messages, increasing the likelihood that it'll continue to be compliant in future messages).

I generally ask for 150% - usually on the expectation that it’ll make the non-compete go away.

It’s not at all a ridiculous ask, either. I’ve made a career out of going after high-impact roles in whatever is the fastest growing area of technology at the time. The non-compete isn’t just asking me to sacrifice the income from my next role, it’s asking me to sacrifice the experience as well. It also limits my ability to renegotiate comp while on the job, because they know your BATNA isn’t to just go get a better offer from a competitor.

If a company wants me to give all of that up, I’m sure as shit not doing it just for the privilege of working for them.

Disclosure: I'm an engineer at LangChain, primarily focused on LangGraph. I'm new to the team, though - and I'd really like to understand your perspective a bit better. If we're gritting the wheels for you rather than greasing them, I _really_ want to know about it!

> Every time I've tried to apply general purpose RAG tools to specific types of documents like medical records, internal knowledge base, case law, datasheets, and legislation, it's been a mess.

Would it be fair to paraphrase you as saying that people should avoid using _any_ library's ready-made components for a RAG pipeline, or do you think there's something specific to LangChain that is making it harder for people to achieve their goals when they use it? Either way, is there more detail that you can share on this? Even if it's _any_ library - what are we all getting wrong?

Not trying to correct you here - rather stating my perspective in hopes that you'll correct it (pretty please) - but my take as someone who was a user before joining the company is that LangChain is a good starting point because of the _structure_ it provides, rather than the specific components.

I don't know what the specific design intent was (again, new to the team!) but just candidly as a user I tend to look at the components as stand-ins that'll help me get something up and running super quickly so I can start building out evals. I might be very unique in this, but I tend to think that until I have evals, I don't really have any idea if my changes are actually improvements or not. Once I have evals running against something that does _roughly_ what I want it to do, I can start optimizing the end-to-end workflow. I suspect in 99.9% of cases that'll involve replacing some (many?) of our prebuilt components with custom ones that are more tailored to your specific task.

Complete side note, but for anyone looking at LangChain to build out RAG stuff today, I'd advise using LangGraph for structuring your end-to-end process. You can still pull in components for individual process steps from LangChain (or any other library you prefer) as needed, and you can still use LangChain pipelines as individual workflow steps if you want to, but I think you'll find that LangGraph is a more flexible foundation to build upon when it comes to defining the structure of your overall workflow.

Kaggle or HuggingFace

A lot of the other responses here are too complicated and specific. Here's my attempt to put it into easier-to-digest terms:

In a traditional web stack you have a backend and a frontend. The frontend is the stuff the browser runs, and, simplifying a bit, the backend is everything else.

Ethereum smart contracts basically let you replace your backend logic and database with code that runs on the Ethereum blockchain network. Depending on your application can decide to run only a few parts of your backend on Ethereum, or the entire backend.

It's very slow when compared to traditional backends like nodejs, etc, but it has the benefits of censorship resistance and excellent availability. Better still, you don't need to run or maintain servers to support it if you don't want to (although there are benefits to doing so).

In this case, they're using Ethereum's replacement for DNS, ENS.

Amazon is becoming more and more like AliExpress with respect to product accuracy and quality. As an example, I recently bought tomato seeds for my garden. I searched for rainbow tomatoes, and the bulk of the results were clearly photoshopped photos made to look like they'd grow tomatoes with colors that'd get lost in a ball pit.

It's easy to evaluate on things like that, but on stuff where corners can be cut I definitely worry.