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.

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.

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 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.

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.

Agentic coding tools change the nature of the software development process. The tools that arose around the previous process—linters, automated unit tests, CI/CD, etc.—may not work in their current form with this changed process.

Those tools encoded the process, but they weren’t the process itself. A great CI/CD tool didn’t mean you shipped faster. A great IDE didn’t mean you wrote better code. An issue tracking system with story points didn’t mean you estimated effort well. Some part of the process existed as culture, as the behaviors and norms of the people building software. New tools often mean changing the organizational culture.

This story will be familiar to anyone who works in sizable engineering orgs. New tools, whatever their promise, can fail when they don’t fit into existing cultures and processes. Successful tools require shifting the culture and processes in a way that developers accept and understand. Y’all love building things and solving problems, so tools that don’t help you do that better get ignored.

Agentic coding gained rapid adoption because it let developers solve problems faster. But it exposed a lot of flaws in existing processes when code became nearly trivial to create. There had always been an issue with unclear and shifting requirements, but now solving a problem requires tightly defining what both “problem” and “solve” mean.

Code may be (nearly) free, but validating it isn’t. The new bottleneck has become code review. The old joke was that if you want a PR approved quickly, change 100 lines. Coding agents change hundreds of lines of code in an instant, and send massive diffs across to humans to review (or rubberstamp). LLM-as-a-judge is evolving as a scalable solution here, but engineering ways to trust that an AI can review code that an AI wrote takes work.

In that same light, running code is also not free. You’ve got the cost of infrastructure, which in the cloud-native era is a factor of the compute, memory, and traffic volumes your application incurs. You’ve got the cost of your hosted dependencies and APIs. And, you’ve got the cost of failures, the hardest thing to budget for: downtime, security breaches, and opportunity costs. Tools that produce software that doesn’t (or can’t) consider these costs might not be worth it. And they put a strain on the process you built that used to produce trustworthy, reliable software.

For a lot of folks, the SDLC has started to look broken thanks to agentic coding. Naturally, these folks are looking to new tooling to repair those cracks: AI SREs, automated code review, memory and context managers, control plane and harness improvements, and so on. These are all solid additions to the tooling in an AI-enabled software organization. But tooling alone will not fix things, especially if the culture and process stay the same. A broken process with better tools (that folks may not use) is still broken.

In the old SDLC, product managers would come up with feature and function requirements based on their research, customer conversations, and competitor understanding. Architects would spec out the software based on their years of experience and understanding of the existing tech stack. Engineers would build it and review commits based on their knowledge of code logic and the existing codebase. QA would review and try to break the software based on their experience with how software breaks. Once the software was deployed to production, DevOps and SREs would monitor and manage the performance and resources used based on their previous experience.

You built trust in this system by working with people, understanding how they thought, and limiting the ways that any one individual or tool could go rogue and devastate the system. Building trust in an AI-enabled SDLC needs these same things: working with people and ensuring they are responsible and accountable, sharing working processes and iterating on them, and minimizing the chance for mistakes.

The first step is to ensure that we enshrine humans as the responsible parties and flag where AI made contributions. Everybody talks about “human-in-the-loop,” but as Charity Majors, CTO of Honeycomb, pointed out, “Human-in-the-loop sounds like a pity invite. I made the loop, I own the loop, I'm the only reason that loop exists. It is MY f***ing loop!” The person pushing the commit owns that code. The people approving those PRs own that approval. If you broke prod on a Friday before AI, you didn’t blame your IDE. If you break it now, the problem doesn’t lie with the agent; it lies between the keyboard and chair.

Collaboration in the age of AI can be a harder and stranger thing. Agents let you expand the idea of what a fullstack developer is, doing everything from product requirements to DevOps in a coding agent. Developers can very easily become a silo of one. “You don't have to, say, check in with your designer about the design because you just got an agent to build the design,” said Jaime DeLanghe, chief product officer at Slack, “and you don't have to work with another engineer in a specific domain to understand their code base because you just ask the agent the question. You could go way down this path and create a massive PR.”

Some folks have suggested prompting agents in a shared room, so everyone can comment and modify the process. Others have suggested that every PR include transcripts of the prompting process. This view into the conversation with an agent might even give greater insight into how that code came about. “It's so cool to be able to open up a PR and actually see how the developer was thinking and how they were problem solving,” said Dane Knecht, chief technology officer at Cloudflare.

Where the old process used access controls, audit trails and diffs, and CI/CD checks to limit the blast radius of any mistake, the new process needs to remove chance before the code is written. That means ensuring everything you want the code to do is explicitly stated in the prompt. You can use spec.md files for this, but anything not specified might now get built. “If you leave anything up to chance, it will be left up to chance,” said Scott Hanselman, VP of Developer Community at Microsoft. “I got this little ring light app to build, and I'm on x64. I wanted it to work on ARM, so I needed to tell it, 'Make me an ARM version.' If I didn't do it, it wouldn't have happened.”

Of course, you can’t cram everything you need into a clever prompt (nor should you). You’d end up repeating yourself a lot and almost certainly missing a few things that exist as tacit company knowledge. Lots of smart people are out there thinking about providing better context to your agents and giving them long-term and short-term memories. The trick is giving your agents the right context that your code needs. Normally, this would be the seasoning that senior devs get over time. But agents need you to capture that knowledge somewhere (like Stack Internal), verify it, and serve the right bits up as context when needed.

So you’ve got the world’s best prompt. You gave your agent the right context, and it built something that passed peer review and got pushed to prod. Your next check on the system is to never build that piece of functionality again. You’ve got a perfectly good software component; don’t lose it, reuse it. “The DRY (don’t repeat yourself) principle is our main principle,” said Laly Bar-Ilan, Chief Scientist at Bit. “AI today is inherently WET (write everything twice). This developer tells it, ‘Okay, generate a button,’ and it gladly does so, and then another developer in another team asks it, and then there's another button in the code base.”

The biggest hack to building trust with AI agents, though, might be to know when not to use them. Even with all the above guardrails on your process, there’s still a bit of a dice roll involved with AI by dint of its nature. If you have a perfectly good non-deterministic solution in place, why reinvent the wheel? “We are trying to apply non-deterministic systems to a lot of scenarios where you should have deterministic code,” said Anil Dash. “LLMs are bad at that thing, and so why are we trying to use them as the hammer on all these things that ain’t nails? The humble bash script that has been running for six years is fine.”

We used to have trust built-in thanks to the people and tools we worked with. That trust came from predictability: You knew what they could do, you knew where their strengths and weaknesses were, and could you expect that your experience with them on Monday would match up with your experience with them Tuesday. The probabilistic nature of AI, as well as the speed at which improvements and changes happen, throws all that out the window. Process improvements can help engineer trust back into development.

In the good old days, we built processes around people, and we trusted those processes because we trusted the people we worked with. We built tools that we trusted to manage the process, and they acted as an extension of ourselves and the people we worked with.

With AI, we’re able to automate a lot of those processes. The good news is that work gets done faster. The bad news is that we don’t trust it when it’s done. The tools are new, the people are moving to more high-level roles, and we still need to build trust. With a more deliberate, explicitly-defined workflow that preserves human judgement, we can start to build trust in the new systems.

Successful teams won’t be the ones that generate the most code. They’ll be the ones building feedback loops, gold standard knowledge that provides the best context, and tools that align your process with your workflows.