Developers are attached to tools because tools encode trust - Stack Overflow<br>Stack Overflow Business<br>Stack Internal : the knowledge intelligence layer that powers enterprise AI.<br>Stack Data Licensing : decades of verified, technical knowledge to boost AI performance and trust.<br>Stack Ads : engage developers where it matters — in their daily workflow.

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.<br>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.<br>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%.<br>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.<br>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.<br>Tools are part of the process<br>Developer 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.<br>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.”<br>Building that muscle memory, that tacit knowledge of how software operates on a code level, lets developers trust their tools to help produce and improve their code. AI agents, meanwhile, are faster, more opaque, and less predictable. You use ambiguous language to create software instead of code. “Code is a precise statement of a solution,” said Bjarne Stoustrup, the creator of C++. “English is a lousy language for expressing things that have to be unambiguous.” A trusty tool is predictable, reliable. You don’t have to iterate repeatedly with Emacs or Vim.<br>With most developer tools, like an IDE, containerization tool, or static analyzer, you know where the boundaries are. They have their role and don’t step outside it. But AI is finding its way into all parts of the SDLC toolchain. Which means the reduced trust developers have in AI applies to the entirety of the process. Code may be faster to produce, but validating it, getting it to a point where developers can trust that it won’t cause expensive production failures, often takes longer.<br>Tools encode processes, but won’t fix them<br>Agentic coding tools change the nature of the...