Developers trust tools that encode trust
Developers are attached to tools because tools encode trust
Developers stick with tools like Vim and Emacs because they encode trust through familiarity and predictability. As AI coding agents gain adoption, trust drops—usage rose from 76% to 84%, but trust fell from 40% to 29%. The article explores how new tools disrupt established processes, why AI's opacity and unpredictability hinder trust, and how organizations can rebuild trust by keeping humans accountable and capturing tacit knowledge.
If you leave anything up to chance, it will be left up to chance.
- MiddleEndian
This article is a bit rambly so I'll just focus on some things from the beginning:
>If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in.
This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates.
To use one product as an example: When Windows ME and Windows Vista came out, people hated them even more than they usually hated Windows, so they did not use them. Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP and a pretty good OS in Windows 7 respectively. No longer is that an option, your workflow will simply be interrupted by automatic updates.
>Vim and Emacs, in their infinite customizability, can be molded to fit your exact hand and workflow
Vim is one major exception to the automatic update problem. I trust vim not just because it can do a ton of shit (although that is certainly nice), but because unlike most other software, its UI doesn't change unless I tell it to change. Aside from switching from vim to neovim (my decision, not a forced update), my muscle memory from a couple decades ago still works today.
- ThePhysicist
There's this great blog post by Joel Spolsky from 2000 [1], where he essentially argues that controlling your environment makes you happy. He writes about his summer job in a bakery and how the dough mixers would be so unpredictable and how frustrating that was. I think AI agents are quite similar to a lot of folks, they change significantly with each major model update and even every day as the vendor tweaks the system prompts and settings, so you never feel "in control", it's more like pushing buttons on some blackbox and hoping the right stuff happens inside. Most people are unhappy about that as it takes away the mastery and craft aspect of software development and makes them managers of unpredictable AI tools. I certainly get this feeling even though I like AI in general, but having days where everything goes so well working with the agent and then days where nothing really seems to work and not knowing why is quite frustrating.
1: https://www.joelonsoftware.com/2000/04/10/controlling-your-e...
- firasd
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
^
- inigyou
This is a lot of words to say absolutely nothing. Seems apropos for Stack Overflow though.
- groundzeros2015
When I see “stack overflow blog” the brand encodes distrust. I remember when they removed links to meta and replaced them with the corporate blog with low quality PR and political agitation.
- Avery29
Trust in tools often comes from predictability and shared context
- alexpotato
There is a great article called "Manual Work is a Bug: Always be Automating" [0] that was written in the pre LLM era for technical operations teams. I would argue that it is just as relevant today as it was then.
To summarize:
- start making a list of the manual tasks you do
- if those tasks involve running command line tools, add an item with the commands you run
- if they are manual tasks, add those too
- over time, keep automating one portion of the list at a time e.g. the commands can become a script, the manual tasks can become tickets to another team to automate etc
At the end of the above process you have a series of automated steps that become a system instead of a bunch of items in someone's head.
In my mind, the only thing that changed with LLMs is that it's faster to create the scripts and some of the manual tasks can be done by the LLM until you get a script to do that too.
We invented code to help do "mechanical" tasks over and over again in the same way. Why replace that with agentic systems??
P.S. This is also why the whole "just commit the prompt, bro" is such utter hogwash
- utopiah
Im typing this in GVim thanks to Tridactyl using my new mechanical keyboard running a ZMK firmware I just built via Github actions (or directly via ZMK Studio).
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 bet, 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.