Skip to content
Agentic Engineering

Overcoming Adoption Blockers

Adoption doesn’t fail because of technology. It fails because of people, process, and organizational friction. Here are the common blockers and how to address them.

Resistance patterns

Section titled “Resistance patterns”

”It’s going to take my job”

Section titled “”It’s going to take my job””

The concern: Engineers fear obsolescence.

The reality: Tools change what engineers do, not whether engineers are needed. But the fear is real and affects adoption.

What to do:

  • Be honest: roles will evolve, not disappear
  • Reframe: these tools amplify your value
  • Invest in upskilling so engineers feel empowered, not threatened
  • Avoid automation-replacement language

”The output quality isn’t good enough”

Section titled “”The output quality isn’t good enough””

The concern: Code quality will suffer. Technical debt will accumulate.

The reality: Valid concern. AI output needs review. But quality depends on usage, not just tools.

What to do:

  • Establish review standards for AI-generated code
  • Start with low-risk applications
  • Track quality metrics to show actual impact (positive or negative)
  • Empower teams to reject agents where they don’t help

”It’s too slow / disrupts my flow”

Section titled “”It’s too slow / disrupts my flow””

The concern: Context switching to an agent breaks concentration.

The reality: For some developers and some tasks, this is true. Workflow fit matters.

What to do:

  • Don’t mandate universal usage
  • Let developers find their own integration points
  • Recognize that optimal usage varies by person
  • Share techniques that minimize disruption

”Security and IP risk is too high”

Section titled “”Security and IP risk is too high””

The concern: Sending code to external APIs exposes proprietary information.

The reality: This is a legitimate concern for some organizations and some code.

What to do:

  • Understand exactly what data flows where
  • Use enterprise plans with appropriate data handling
  • Consider self-hosted or local models for sensitive work
  • Define clear policies about what can/cannot be shared

”We don’t have time to learn new tools”

Section titled “”We don’t have time to learn new tools””

The concern: Learning curve is a distraction from real work.

The reality: There’s always “real work.” But capability investments compound.

What to do:

  • Acknowledge the short-term cost
  • Start with volunteers, not mandates
  • Build in dedicated learning time
  • Show early wins to build momentum

Process mismatches

Section titled “Process mismatches”

Change control resistance

Section titled “Change control resistance”

The problem: Existing change processes weren’t designed for AI-assisted development.

Solution: Adapt processes rather than abandoning them. Define how AI code fits existing controls.

Toolchain integration

Section titled “Toolchain integration”

The problem: AI tools don’t integrate cleanly with existing IDE, CI/CD, review systems.

Solution: Accept some friction initially. Prioritize integration investments based on pain.

Metrics disruption

Section titled “Metrics disruption”

The problem: Existing metrics (lines of code, commit frequency) become misleading.

Solution: Update metrics to reflect outcomes, not activity. Accept a metrics gap during transition.

Undefined success criteria

Section titled “Undefined success criteria”

The problem: No one agrees on what “successful adoption” means.

What happens: Different stakeholders judge success differently. Same data, different conclusions.

Solution: Define success criteria before rolling out:

  • What adoption rate do we expect at 3/6/12 months?
  • What productivity indicators would show value?
  • How will we measure quality impact?
  • What developer satisfaction target matters?

The adoption playbook

Section titled “The adoption playbook”

Phase 1: Enable (Months 1-2)

Section titled “Phase 1: Enable (Months 1-2)”
  • Make tools available to volunteers
  • Provide basic training (2-4 hours)
  • Gather feedback actively
  • No pressure, no mandates

Phase 2: Learn (Months 2-4)

Section titled “Phase 2: Learn (Months 2-4)”
  • Expand access based on demand
  • Identify internal champions
  • Document what works in your context
  • Address concerns as they surface

Phase 3: Integrate (Months 4-8)

Section titled “Phase 3: Integrate (Months 4-8)”
  • Update processes to accommodate AI workflows
  • Train more deeply on advanced techniques
  • Measure outcomes against baseline
  • Scale support resources

Phase 4: Optimize (Ongoing)

Section titled “Phase 4: Optimize (Ongoing)”
  • Refine practices based on experience
  • Track evolving tools and capabilities
  • Share learnings across teams
  • Plan next integration level

Resources

Section titled “Resources”

Essential

Section titled “Essential”

Videos

Section titled “Videos”