Stack Overflow: AI coding tool use is up, trust is down

A Stack Overflow blog essay revisits a debate the outlet ran about six years ago over whether IDEs had made tools like Vim and Emacs obsolete, and uses it to argue that developer attachment to a tool comes from trust built through years of familiarity and predictable behavior, not from raw capability. Vim and Emacs, endlessly customizable, become an extension of an experienced user's hand; a great IDE lets developers build the same kind of unconscious competence. AI coding agents break that pattern. They are terminals a developer talks to in natural language rather than precise code, they can output whole applications in a fraction of the time a person would take, and they keep changing shape and behavior, so the muscle memory a developer would normally build with a tool never has time to form. That leaves an open question the essay keeps returning to: whether the agent's output can be trusted.

The essay backs the point with a number from Stack Overflow's own 2025 Developer Survey, linked in the piece: developer usage of AI rose from 76% to 84%, while developer trust in AI fell from 40% to 29% over the same period, moving in opposite directions. The author compares an AI coding tool to a kitchen knife that keeps changing shape, weight and edge: relearning it every time makes it hard to trust, and the instability also exposes a weaker underlying process rather than being the whole problem itself.

The essay's central claim is that tools encode a development process but are never the process itself: a great CI/CD tool did not by itself mean an org shipped faster, a great IDE did not by itself mean developers wrote better code, and an issue tracker with story points did not by itself mean effort was estimated well. Culture, the norms and behaviors of the people building software, filled the rest, and adopting a genuinely new tool like an agent means changing that culture, not just swapping the tool.

Agentic coding exposed cracks the essay says were already there. Because code is now nearly free to produce, solving a problem requires precisely defining what "problem" and "solve" mean up front, something requirements had always been sloppy about. Code review has become the new bottleneck: the old industry joke was that a pull request gets approved quickly only if it changes about 100 lines, and coding agents instead produce massive diffs in an instant that get sent to humans to review, or rubberstamp. Running the resulting code is not free either, the essay adds, once infrastructure, hosted dependencies and the cost of failures such as downtime and security breaches are counted.

Tricia Gee, described as a developer productivity advocate, said her own reluctance to embrace AI programming comes from being faster in an IDE she already knows deeply, the same resistance she has seen in developers who know Vim and Emacs well: refactoring tools in IntelliJ IDEA are available, but adopting them means a new learning curve on top of fingers that already know what to do. Bjarne Stroustrup, the creator of C++ (rendered as "Stoustrup" in the source article), is quoted making the contrast explicit: "Code is a precise statement of a solution. English is a lousy language for expressing things that have to be unambiguous."

On rebuilding trust, the essay argues an AI-enabled software development lifecycle needs the same ingredients as the old one: people who are responsible and accountable, shared processes that get iterated on, and fewer chances for mistakes to slip through. Charity Majors, CTO of Honeycomb, pushed back on the phrase "human-in-the-loop": "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!" Her point, echoed by the author, is that the person who pushes a commit or approves a pull request still owns it; a production outage traces to the person between keyboard and chair, not to the agent. Jaime DeLanghe, chief product officer at Slack, warned that agents let a developer skip checking in with a designer or another engineer and go straight to a massive pull request, risking a developer becoming "a silo of one." Dane Knecht, chief technology officer at Cloudflare, said visibility into an agent's prompting transcript inside a pull request is valuable because it shows how the developer was thinking and problem-solving. Scott Hanselman, VP of Developer Community at Microsoft, argued for removing chance before code gets written rather than after: building a ring light app, he had to explicitly tell the agent to target ARM as well as x64, because "if you leave anything up to chance, it will be left up to chance." The essay closes by urging teams to capture tacit, senior-level context for agents to draw on and, once a working component clears review and reaches production, to reuse it rather than have an agent build it again from scratch.

Key facts

Stack Overflow's own Developer Survey found AI usage among developers rose from 76% to 84% while developer trust in AI fell from 40% to 29% over the same period.
The essay's core argument: tools like a CI/CD system, an IDE or an issue tracker encode a development process but are never the process itself, so adopting an AI coding agent requires changing culture, not just swapping tools.
Coding agents can turn out massive diffs instantly, making code review the new bottleneck; the essay cites the old joke that a pull request gets approved quickly only if it changes about 100 lines.
Charity Majors, CTO of Honeycomb, argued that responsibility for AI-assisted code still sits with the person who commits and approves it, not with the agent, pushing back on the phrase "human-in-the-loop."
Scott Hanselman, VP of Developer Community at Microsoft, said he had to explicitly tell an agent to build an ARM version of a ring light app or it would not have happened, illustrating the essay's advice to remove chance from prompts before code is written.

Why it matters

The essay reframes a familiar complaint (developers don't fully trust AI-written code) as a trust problem rather than a capability problem. Its own Developer Survey shows usage and trust moving in opposite directions, 76% to 84% on usage against 40% to 29% on trust, which argues that better models alone will not close the gap: agents change too fast for developers to build the muscle memory that makes an IDE or an editor feel trustworthy, and that instability also surfaces process weaknesses that predate AI.

Who it affects

Software developers and the wider engineering organization around them: product managers who used to gather requirements, architects who used to spec systems, the engineers reviewing pull requests, QA, and DevOps or SRE teams monitoring what ships. The essay singles out code review specifically, since reviewers now face diffs sized for an agent's output speed rather than a human's.

How to use it

The essay's practical advice is about process, not a specific product: state everything the code needs to do explicitly in the prompt, since anything left unspecified may be built or skipped at random, as in Hanselman's ARM example; capture tacit, senior-level context so agents can draw on it and verify it rather than re-deriving it; keep humans named as the owners of every commit and every approved pull request; and once a working component has cleared review, reuse it instead of asking an agent to rebuild it.

How solid is it

The piece is an opinion essay on the Stack Overflow blog, not an empirical study, built around one quantitative data point (the company's own 2025 Developer Survey, linked in the piece) and quotes gathered from named industry figures: Tricia Gee, Bjarne Stroustrup, Charity Majors of Honeycomb, Jaime DeLanghe of Slack, Dane Knecht of Cloudflare and Scott Hanselman of Microsoft. The argument rests on their general commentary and the author's own reasoning rather than additional data.

Risks and caveats

The earlier "IDEs vs. Vim/Emacs" article the essay opens with is referenced and linked, though not named outright in the text. The quotes from Majors, DeLanghe, Knecht and Hanselman are general commentary, not tied to a specific company incident or project. The source spells the C++ creator's name "Bjarne Stoustrup"; this retelling uses the standard spelling, Stroustrup.

“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!”

— Charity Majors, CTO of Honeycomb