Developers are attached to tools because tools encode trust

July 29, 2026Developers are attached to tools because tools encode trustThe tools themselves are new and their capabilities are in constant flux. 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. But it also points to a flaw in how you use that tool, the process around it, and the way the tool reinforces the process.About six years ago, we ran a piece about IDEs where the gist was that IDEs were getting to be so powerful and capable that it was a marvel that anybody used Vim or Emacs like a caveman. While yes, it was a provocative article, it got a lot of developers pretty riled up. Comments came from both sides, both from folks trashing the article for not understanding how developers work and from those developers who preach the good news of Emacs all day. But mostly there was a great discussion about why these tools were actually useful.For a novice, Vim and Emacs can seem like unintuitive terminal programs that require memorization of secret keystrokes to use (and escape). But for the experienced user, it can feel as natural as thinking. One comment pointed to The Pragmatic Programmer by David Thomas and Andrew Hunt, which explained that developers—craftsmen that they are (or were)—need “sharp tools” that feel like an extension of their hand. Vim and Emacs, in their infinite customizability, can be molded to fit your exact hand and workflow. Taking the time to build proficiency and trust in your tools, and well as hacking them to fit you, pays deep dividends.In this age of agentic engineering, the new tools are terminals you talk to in natural language. A coding agent lacks the precision and specificity of a developer writing well-crafted code, but it can output whole applications in a fraction of the time. The question that still echoes today is whether those outputs can be trusted. Our last Developer Survey found that the more developers used AI, the less they trusted it—usage rose from 76% to 84%, but trust fell from 40% to 29%.The tools themselves are new and their capabilities are in constant flux. 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. But it also points to a flaw in how you use that tool, the process around it, and the way the tool reinforces the process. You trust your favorite knife, IDE, paintbrush, or whatever because of the trust you’ve built with it, and the process around it.In this article, we’ll look at how tools build trustworthy processes, the ways that tool changes highlight but can’t fix broken processes, and where tooling and culture can work together to build new trust.Tools are part of the processDeveloper tooling operates and evolves alongside software development as a whole, but also with individual developers. If you start working and learning in a terminal, perhaps in a day when IDEs or graphic interfaces didn’t exist, then the way that you understand creating code includes those terminals and terminal text editors. Adding in an IDE would require not just learning a new tool, but refactoring your process of writing code.If moving from the terminal to the IDE is a hard process shift (or as some would say, unnecessary), then moving from either to an agentic coding tool is harder. “One of my reticences for embracing some of the AI programming is because I'm faster with my IDE because I know how that works,” said Tricia Gee, a developer productivity advocate. “I've seen the same thing when I've worked with people who know Vim and Emacs very well. You could use the refactoring tools in IntelliJ IDEA. They're like, yes, but that requires a learning curve. I've spent so long using whatever tool it is. My fingers know what to do. Understanding a tool very well, no matter what it is, becomes a lot of unconscious competence.”Building that muscle memory, that tacit knowledge of how software operates on a code level, lets develo