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.
can't agree more, I now run my agents in parallel with "agentbox claude", "agentbox opencode" and it teleport my project and settings to an hetzner VPS
The "vt100 teletype emulation" only concerns the protocol in which the program describes what to draw on the display. It might be inconvenient for the programmer, but for the user it is kinda irrelevant.
> Such statements can only be voiced by those that never experienced what using a proper REPL actually feels like.
Maybe. What do you mean with proper REPL? SBCL just runs fine in my terminal emulator. As do all other kind of programming languages, like Prolog.
When I interface with the OS, I want to start programs, control the processes, setup communication channels (pipes) and tell to computer to combine multiple programs to filter, combine, split stuff and redirect it to files and other programs. These should be also be able to run several times with slight differences. All of that works just fine in my shell. What are you missing?
SBCL REPL cannot do this on xterm, it needs a proper hosting REPL environment like SLIME, which is no wonder, given how Emacs came to be and the interaction with genera.
You are missing integration with live debugging, calling anything on the OS during a REPL session, e.g. OS APIs, calling into automation points of the OS,
Can try out directly on the browser, courtesy of WebAssembly and recovery of Xerox PARC software, https://interlisp.org.
Or get either Squeak or Pharo, and see how using the Transcript integrates with the whole platform
Windows, with either PowerShell ISE, or its new VSCode integration, are the closest to these kind of experiences.
To finalise with Xerox PARC view on UNIX, from 1989
"UNIX Needs A True Integrated Environment: CASE Closed"
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 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].
Haha yup. yoloAI is to scratch my own itch. I'm getting close to taking it out of beta, but first I'm putting it through a significant architectural overhaul in a feature branch. Normally I'd balk at doing something so heavy, but AI makes it so damn easy to do major mechanical changes (provided you guide it properly and have good tests). So far, so good! And it feels nice to fix the architectural warts before I lock in the interface.
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.
If it's 100%, I'd rather the noncompete not go away. If I am able to live off the salary, why not take the free paid vacation if it's offered? I can spend the time doing and learning things for myself, rather than the company.
In principle, if you are changing jobs, it's because you found one with something like a raise or better working conditions. Being unable to look for those has a cost.
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.
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.