I suspect the first case worked as intended, and VS Code is greasing the wheels. I'm sure there's a way to get it working in iTerm 2, though I wouldn't be surprised if the solution was some Goldbergian chain of forwarded unix sockets and a helper daemon living inside the sandbox.
Thanks for mentioning yoloAI, though. I started off sandboxing via devcontainers using kata & cloud hypervisor set up as a custom docker runtime. It worked well enough, but nested docker was super slow due to virtio-fs limitations. I recently moved to sysbox and it's a bit quicker. It's probably not as airtight as kata/chv, but good enough to keep Claude from writing a security test that deletes my whole filesystem [1].
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.
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.
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.
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.
> to actually make a transaction on the blockchain
On which blockchain, exactly? On the Ethereum Mainnet you can transact for a fraction of a cent USD and it'll typically be verified (mined into a block) within a minute (often faster).
On the Bitcoin chain you choose your own transaction fee, but if you're not keeping up with market rates your transaction might take quite a long time to be verified (again, mined into a block).
FWIW, most of what you're saying here is my rationale for the first half of the sentence you quoted. Specifically, there are times when it makes sense to speak up, and being able to do so anonymously definitely quashes fear-driven self censorship.
While generally I'd agree that self censorship is a bad thing, I'd also agree that an ability to control one's impulsiveness is just the opposite. Impulse control is what I was referring to above as my general reasoning for why I default to using my real identity online, not self censorship.
I don't disagree that anonymity offers protection against situations like this, but bear in mind that anonymity is very much a factor in the lack of civil discourse online. I'm not suggesting for a second that stripping anonymity is a solution to any of these problems, but personally I feel like I'm less likely to engage in the sort of behavior which might invite an angry mob while posting under my real name.
I agree that those who participate in a process like this shouldn't circumvent its rules -- that just makes the whole problem much more difficult to manage. However, I think you could just as easily argue that the process itself is scummy for requiring the job posting when a well-qualified candidate has already been identified.
Why is a candidate's country of citizenship the test for whether a role must be posted publicly before it can be filled? Wouldn't it be best for both the economy and the company if this rule were followed (without circumvention) for 100% of job openings? If your answer to that is "no," then why require it in any circumstance?
I strongly agree that this is true in a lot of cases, and the ahead-of-time rationalization of limiting liability helps to perpetuate the lack of necessity of a clear, defensible reason for rejection.
I say this as a hiring manager, by the way, knowing full well that nothing involving the hiring process is as clean and straightforward as anyone involved wants it to be.
Thanks for mentioning yoloAI, though. I started off sandboxing via devcontainers using kata & cloud hypervisor set up as a custom docker runtime. It worked well enough, but nested docker was super slow due to virtio-fs limitations. I recently moved to sysbox and it's a bit quicker. It's probably not as airtight as kata/chv, but good enough to keep Claude from writing a security test that deletes my whole filesystem [1].
1: https://github.com/anthropics/claude-code/issues/28521