I feel like these abstractions like "CI might not work well in the era of agentic tooling" are fine for thought-leadership posts but there's so much hands-on work to be done. The last word on AI computer use shouldn't be bash utils that were already feature-complete before MJ recorded Thriller.
There is some movement in this direction--there is a new 'gh' subcommand called repo read-file for example, that lets agents view a file without cloning a repo. And I made something called venetianblinds that shows equidistant samples of a file. In combo they work pretty well:
gh repo read-file sqlite3.c --repo clibs/sqlite --output sqlite3.c && npx github:firasd/venetianblinds sqlite3.c
--- sample 2/20 char 283427 line 5855 col 53 range 283367:283487
le].
**
** ^Closing a BLOB shall cause the current transaction to commit
** if there are no other BLOBs, no pending prep
^
I've found the process of building good reliable CI that thoroughly covers everything has been greatly improved by LLMs. There's so much tedious plumbing and grunt work involved in building CI and automated testing infrastructure for bespoke products that they can handle just fine while you concentrate on the important bits - I would say it's an area where agentic workflows are even more suited than regular product code.
Hand-crafted, domain-specific tools massively outperform general purpose ones.
Shell execution and raw DOM access are great for a backstop, but you can go so much further with just a little bit of translation and delegation around the environment.
I think browser automation is probably the most apt scenario. Often a human who understands how a page is meant to be perceived can transform a megabyte of raw web content down to a few hundred bytes of plaintext without any reduction in fidelity. This can be achieved using deterministic code that is guaranteed to provide a perfect transform every time.
The performance difference between raw DOM access and curated plaintext is like a step function. With raw access you get maybe 10-15 steps into a complex workflow before the wheels pop off. With curated access I've seen it go 100+ screens without issues.
Simply managing the token bloat is probably the most important objective here. If that's all you focus on it will probably go really well.
Yes exactly. It's almost like there's this expectation that if the LLM GPU-Maxxes enough it can do anything but like... why. There's no reason to wade through a million HTML tags if you can slice out the exact div you want to check
MCP is the answer to not using bash, right?
Bash is a great control surface anyway for LLMs as it is wordy and powerful.
Yeah as far as what I'm talking about bash CLI vs MCP doesn't matter (there could be a file_sample MCP tool)---I'm saying that by default Windows, Linux etc don't have this venetianblinds affordance of seeing equally spaced samples. It's a trivial algo but it's very handy these days cause LLMs can't really just be like 'okay I'm gonna open this file at random and scroll around'--the file itself is an unknown blob (JSON data, Python, Typescript, a log file etc) without coordinates. So they fall back to thinking they've gotten a good sense of the file from head/grep or they write ad-hoc Python to manipulate the file.
Another venetianblinds survey, of the Paul Graham 'What I Worked On' article that's used in many LlamaIndex examples:
npx github:firasd/venetianblinds pgworkedon.txt
Also, this is a trivial example but I would rather an LLm call a recursive "grep" than using 1000 read_file MCP calls.
Having a scripting language as a tool is powerfull, and can help remove unnecessary stuff from the LLM's context.
Problem is that bash is too sharp to handle to smart and gullible clankers without a sandbox - That I think everyone should be using anyways, for everything, even things not related to clankers - Android and Qubes are right. The app/vm, and whatever it tries, should not be considered trusted by default.
Qubes is directionally correct, Android is extremely not. Safety must not be obtained by preventing users from controlling their own computing devices, or else we face a dire future.