From resistance to results: Why agentic coding requires a new mindset

The universal struggle

Every software team seems to be grappling with the same questions right now: How do we actually make sense of AI coding tools? Why do some developers swear by them while others find them more hindrance than help? What separates the teams getting dramatic productivity gains from those still fighting with "junior dev AI" output?

These aren't abstract questions anymore—they're daily realities shaping how we work, what we deliver, and how we think about the craft of software development.

When one of our engineers, Rian, posted this honest admission in our team Slack, it sparked exactly the kind of conversation happening in engineering teams everywhere:

"I keep trying agentic coding but enjoy (aka am more productive) coding myself than shoehorning my junior dev AI's code into my PR."

The replies came fast. He'd captured something many of us were feeling but hadn't quite articulated: AI coding tools promised productivity gains, but the reality felt clunky and frustrating.

What followed was one of those rare conversations that shifts perspective in real time. By the end, we'd collectively worked through not just how to make agentic coding productive, but why our initial approach was fundamentally wrong.

The problem wasn't the AI tool

Dustin's response cut straight to the heart of it: "I felt this way for a bit but continued to take the approach of 'what am I doing wrong?'"

His breakthrough came from recognizing that the issue wasn't the AI's capability—it was the level of direction he was providing. "I found that my prompts were too high level, that my settings for the Agents weren't good, and all of this was leading to way too much freedom in the Agent."

The solution was counterintuitive for many of us who'd been trained to give human developers broad problems to solve. With AI agents, specificity wins: "I'm not letting the agent decide how to solve X, rather I'm a couple layers down saying, 'Do this this and this for me.'"

The results speak for themselves. Dustin reported getting "close to the exact code I want out of the machine about 80% of the time, completing in an hour what would normally take me a day, with the exact same output."

Abstraction, not replacement

Aaron framed this shift in terms that resonated across our team: "To me it feels very much like another layer of abstraction over the code. In a lot of ways Ruby is 'just' a nice abstraction over C or machine code. Agentic coding to me feels like abstracting away minor implementation details and getting to focus on the larger project."

This perspective helped us see agentic coding not as a threat to craftsmanship, but as the next evolution in how we work at higher levels of abstraction. Just as we moved from assembly to high-level languages, we're now moving from line-by-line coding to system-level direction.

But Aaron also captured the practical reality: "It will 100% try to turn your code into junior dev spaghetti as much as it can. It still absolutely needs that experienced guidance to work towards design patterns and to refactor in a nice direction."

The tool is powerful, not intelligent. Experience still matters—perhaps more than ever.

The satisfaction question

This led us to examine something deeper: what actually drives satisfaction in software development?

"Writing beautiful, maintainable code that solves a problem is an art form," Aaron noted. "Agentic coding feels more like using a photo printer vs drawing/painting by hand."

For some, this analogy might feel like a loss. But as our conversation evolved, a different perspective emerged.

"The most satisfying part of 'coding' is the journey; I care much less about the destination (the written code)," I shared. Looking back over time, the real satisfaction comes from "the problem that was solved, how elegantly it solved it (from a users perspective first), and how much of a positive impact I've had on changing the way people do their jobs."

Rob captured the reality many of us face when reviewing our own code: "when I look back at code I've written, I start thinking 'hmm, why did I do that? Oh, that's now a legacy pattern. What does this one thing even do??'"

The code itself is ephemeral. What endures is the solved problem, the working system, the user who can now do their job better.

The business reality check

This philosophical shift has practical implications. There's a real trap developers fall into where we become obsessed with details that don't matter to outcomes. When we prioritize "purity" or "beauty" in code over solving business problems, we miss opportunities to create real value.

Nothing teaches this lesson faster than working in environments where survival depends on results. As Mavrick noted about his current client, who has embraced agentic coding: "the software is basically disposable and treated as such, their focus is on the outcome."

This isn't anti-craftsmanship—it's about choosing your battles. Sometimes the perfectly architected solution matters. Often, the working solution delivered faster matters more.

The evolution of judgment

Perhaps the most honest reflection came from examining how our own practices have evolved. Dave shared his journey with TDD as an example:

• 2010: "highly skeptical, felt it was hand wavy"
• 2015: "a true believer, I swung that TDD golden hammer like you wouldn't believe"
• 2020: "somewhat jaded, having seen it been used for good and for evil"
• 2025: "it depends™ — I'm fully on board with throwing away all previous testing rigidity if that makes sense for the particular business I'm working for"

The pattern here isn't about TDD specifically—it's about moving from dogma to context-dependent judgment. Agentic coding accelerates this evolution by forcing us to articulate why certain practices matter, not just what those practices are.

What this means for teams

For software leaders, this conversation reveals several key insights:

Expect initial resistance. Even experienced developers will struggle with agentic coding if they approach it like managing human junior developers. The interaction model is fundamentally different.

Invest in prompt engineering skills. The ability to break down problems into specific, actionable instructions becomes a core competency. This isn't just about using AI tools—it's about thinking more systematically about problem decomposition.

Redefine productivity metrics. If your team can deliver working features in hours instead of days, what does that mean for sprint planning, estimation, and resource allocation?

Focus on outcomes over process. The teams that thrive with agentic coding are those already oriented toward business results rather than engineering purity.

The new developer value proposition

As Aaron posed the crucial question: "What value do WE add in a world where someone can vibe-code their way to an acceptable result without us?"

The answer emerged from our conversation: judgment, systems thinking, and hard-won experience. It's knowing when to accept AI output and when to throw it out. It's knowing what good looks like and then understanding how to engineer our prompts to get there. It's choosing which battles to fight and understanding what level of polish actually matters.

Most importantly, it's recognizing that our role is shifting from writing every line of code to ensuring the entire system—human and artificial—delivers valuable outcomes.

The craft isn't disappearing. It's evolving. And for teams willing to embrace that evolution, the productivity gains are substantial enough to change how we think about what's possible.

This post emerged from a real conversation among Test Double team members who are experienced software developers. Sometimes the best insights come not from individual reflection, but from working through challenges together in real time. Aaron Gough is a Senior Software Consultant, Dave Mosher is a Staff Software Consultant, Dustin Tinney is an Engagement Partner, Mavrick Laakso is a Senior Software Consultant, Rian Rainey is a Senior Software Consultant, and Robert Komaromi is a Senior Software Consultant.