Developers are attached to tools because tools encode trust

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
                                                    ^

For example, I use Codex and Claude Code by default, but when I need to look at the API surface, read tests, etc I have those tools setup to open Zed. Zed is also rapidly evolving in the other direction, where it's closer to the tools that are opening it. It won't be long, I think, until I can continue my prompt from inside Zed.

This is ridiculously complex to just type a few paragraphs. Nobody in their right mind would invest this amount of yak shaving... and yet I do so because I get, rather confidently, that in few years, heck few decades, all those tools will be different (or maybe not, I still use Vim on my server, desktop but even mobile phone) but the lessons will remain practical.

IMHO the trust comes from trust yes but also more directly plain ownership.

This makes it unreliable and preferences are things I need to assume are treated as exactly that, preferences, not hard settings.

It is an area where it is more like working with an unreliable human than I would prefer.

> "Developers become attached to tools like Vim, Emacs, or an IDE because years of experience make those tools predictable extensions of their thinking. The attachment is less about features and more about accumulated trust, muscle memory, and a workflow built around known boundaries.

> AI coding agents disrupt that trust because they are fast but probabilistic, opaque, constantly changing, and capable of producing more code than humans can realistically review. This shifts the bottleneck from writing code to specifying, reviewing, validating, and operating it safely."

(Note the > is paraphrasing)

Trust is a big problem I'm having with these tools so far. What I've been running into a lot is, I'll get the equivalent 40 hours of work done in 8 hours, and I'm like, wow, that really was quick. Then I'll start using the application I'm making more directly (a tool for writing), and I'll start to see that it's broken all over the place in very surprising ways (ie, updating this menu item broke something on the other side of the app, etc.). So then I spend another 40 hours of real wall clock time kind of fixing everything that was broken, and at the end of those two weeks I'm like, did I actually go much faster or was that all kind of a wash? Because if I'm not going faster in overall terms, then the loss of deep understanding of the code base might not be worth it if my pace is the same.

I'm sure someone is going to be like "BRUH AUTOMATED TESTS" or "BRUH MODEL CHOICE". I have a LOT of automated tests, and I don't like fussing with models so I pretty much use Opus on high reasoning for most things (or the equivalent from other providers). Code review also doesn't help that much, for much of the same reason it doesn't tend to help find bugs in human written code either.. you're reading the happy path usually.

Anyway I wouldn't say these tools aren't useful, but, I'm deeply skeptical of all the productivity claims because I think people just look at one dimension of it while ignoring all the other important dimensions. Yeah you can generate a lot of crap fast, but most of it is not shippable and making it shippable does take time.

I update my toolset all the time. It always results in discomfort and backlash but people don't understand that the goal isn't their perception or trust. It's about skill, ability, and execution. This idea probably won't get me promoted but it will get me paid. I am not attached to tools because I learned the hard way that they will always find a way to take them from me.

Zero trust is a better alternative for people like me. In terms of cybersecurity, being attached to a tool is crutch because fatal flaws in every design are frequently found. As it relates to agentic AI, I never select the "Yes, trust the AI and let Claude execute arbitrary commands in a non-sandboxed environment" option. However, I frequently utilize agents, but I'm not going to have the "Jesus, take the wheel" moment with them right now. That being said, AI is a very helpful tool that helps me create boilerplate code, brainstorm ideas, and review my work. I also anticipate when AI can, in fact, take the wheel and I'm looking forward to it.

Parallel to this, I also know that developers often disagree, and I'm not casting judgement on anyone for being attached. If it's Turing-complete, then I have the background to complete the task. In these scenarios, I just adopt whatever tools work best in team building because, in my own words, I'm not too attached to the way I do things.

Stack overflow was really attractive to me once but gave me a really hard time. Literally for years I really wanted SO to like me and did what I could to that aim, but always in vain. There were moments but you had to be a sucker in love to value those feeble crumbs, man and boy was I. Pretty sad.

These days I barely think about SO since agentism opened up the world -- nay -- universe to me. I've got new and rather impressive homies now; some, like Claude, I've yet to meet.

Life is good. And I honestly wish SO well, no hard feelings.