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
                                                    ^

▲ bob1029 23 minutes ago | parent | next [-]

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.

▲ hahahaa 2 hours ago | parent | prev [-]

MCP is the answer to not using bash, right?

Bash is a great control surface anyway for LLMs as it is wordy and powerful.

▲ firasd an hour ago | parent | next [-]

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

  --- sample 1/20 char 0 line 1 col 1 range 0:60
  Before college the two main things I worked on, outside of s

  --- sample 2/20 char 3946 line 19 col 237 range 3886:4006
  d an intelligent computer called Mike, and a PBS documentary that showed Terry Winograd using SHRDLU. I haven't tried re

▲ LelouBil an hour ago | parent | prev | next [-]

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.

▲ ElectricalUnion 2 hours ago | parent | prev [-]

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.

	▲	applfanboysbgon an hour ago \| parent [-]
		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.