Developers are not attached to tools such as Vim, Emacs, or integrated development environments merely because they are accustomed to them, but because these tools become part of the way they think about, write, and review code. As users gain long-term experience, commands and procedures become implicit knowledge and muscle memory, making the tool seem like a natural extension of their hand. This relationship explains some of the hesitation toward agentic coding tools, which can produce complete applications quickly but are less precise, clear, and predictable.
The article connects tools with trust and the process surrounding them. A trustworthy tool is not merely one that performs a task, but one that enables developers to understand its limits and behavior and anticipate its results. AI agentic tools, however, continually change in capability and rely on natural-language instructions that can be ambiguous. According to the latest developer survey data referenced by the article, AI usage rose from 76% to 84%, while trust in it declined from 40% to 29%.
The Tool Is Part of the Development Process
Learning to work in a terminal, inside a text editor, or in an integrated development environment does not mean learning only a separate program; it means building an entire process for writing, understanding, and improving code. Therefore, moving from the terminal to an integrated development environment may require rethinking how one works, while moving from either of them to an agentic coding tool represents a larger transformation.
Tricia Gee, a developer productivity advocate, explains that a developer may be faster using the development environment they know because their fingers have become accustomed to what needs to be done. The same applies to experienced Vim and Emacs users. Over time, unconscious proficiency develops, helping developers trust the tool and use it to produce and improve code.
Traditional tools, such as integrated development environments, container tools, and static analyzers, give users a clear view of their limits and roles. AI, however, permeates multiple parts of the software development life-cycle toolchain, making declining trust in it affect the entire process. Writing code may become faster, but verifying it and ensuring that it will not cause costly failures in production may take longer.
Tools Do Not Fix Broken Processes
Agentic coding tools have changed the nature of the development process, which may make tools built around the previous process—such as static analysis tools, unit testing, integration, and continuous deployment—less suitable in their current form. But the article distinguishes between a tool and the process it embodies: a good continuous integration and deployment tool does not guarantee faster shipping, a powerful integrated development environment does not guarantee better code, and an issue-tracking system does not guarantee accurate effort estimates.
Part of the process takes shape within an organization’s culture and the behavior and standards of its people. For this reason, new tools may fail, no matter how great their promises seem, if they do not align with existing culture and processes or if developers do not understand why they are being used. The article notes that agentic coding tools spread quickly because they help developers solve problems rapidly, but at the same time they exposed longstanding flaws in specifying requirements, defining the problem, and defining what it means to solve it.
Producing code has become nearly free compared with what it once was, but reviewing it has not. Developers may face enormous pull-request changes generated by agents in moments, increasing the burden on reviewers or encouraging superficial reviews. The use of a language model as a judge is being developed to expand the scope of review, but building trust in AI’s ability to review AI-written code requires additional work.
Running code also has its costs. These include infrastructure costs; cloud resources such as compute, memory, and traffic; dependent services and hosted APIs; as well as the cost of failures, such as outages, security breaches, and opportunity costs. Tools that produce code without considering these factors are not necessarily useful and may weaken the process that previously produced reliable software.
Building Trust Through Responsibility and Processes
In the traditional development cycle, trust was distributed across interconnected roles: product managers defined requirements, architects designed solutions, engineers built software and reviewed changes, the quality-assurance team tested failure points, and DevOps and SRE specialists monitored performance and resources after launch. This distribution helped reduce the likelihood that an individual or tool would act outside its boundaries in a way that harmed the system.
The article argues that an AI-supported development cycle needs similar principles: working with people, defining responsibility and accountability, sharing and gradually improving processes, and reducing opportunities for error. Humans should remain the accountable parties, with the places where AI contributed clearly identified.
Responsibility does not shift to the agent merely because it created the change. The person who pushes the change to the repository is responsible for the code, and whoever approves the pull request is responsible for the approval. According to the article’s reasoning, if the change breaks the production environment, blame cannot be placed on the development environment or the tool; responsibility lies with the people and process that allowed the change to pass.
This transformation brings another challenge related to collaboration. An agent may allow a single developer to perform tasks spanning product requirements to DevOps operations, increasing the likelihood that the developer becomes an isolated island that does not communicate with the designer or the engineer specializing in a particular codebase. The article warns that this path may lead to enormous pull requests, even if the tool appears capable of completing the work quickly.
The central conclusion is not that new tools are useless, but that improving tools alone is insufficient to repair a broken development cycle. Organizations need processes that developers understand and accept, clear boundaries for agents’ roles, genuinely accountable human review, and collaboration that prevents development from becoming a closed individual activity. Then tools and culture can work together to build new trust in an AI-driven development environment.