Jim Douglas is the Chief Executive Officer of Luciq, a leading agentic observability platform built exclusively for mobile.gettyThe problem is not the skepticism or resistance. The problem is what most organizations do with it.Every CEO I know has issued some version of the same mandate in the last 18 months: "We are an AI-first company now. Adopt it, integrate it, report back on progress."And in almost every engineering organization I talk to, that mandate has run headfirst into the same quiet wall. The developers are skeptical, not despite understanding AI, but often precisely because they do. The most resistant engineers tend to be the most senior: people who have mastered the current abstraction; built hard-won instincts about edge cases; and can articulate exactly why the AI output falls short. From a leadership perspective, this looks like resistance. From where they are sitting, it is a completely rational response to being asked to trust a system still imperfect in measurable ways.The problem is not the skepticism or resistance. The problem is what most organizations do with it.The Appeasement TrapWhen a top-down AI mandate meets bottom-up skepticism, most organizations find a middle path satisfying neither goal. They layer a code completion assistant on top of existing sprint mechanics. They automate an hour-long report. They point to adoption metrics and check a box. What they do not do is rethink the process itself.The distinction matters, especially in mobile engineering, where the maintenance burden is structural, not incidental. Across the mobile teams we work with at Luciq, we consistently see Dabble's engineers were spending up to 20 hours a week per engineer on reactive triage before making the shift to agentic workflows. Not because those teams are inefficient, but because their processes were built around the assumption that humans would handle detection, diagnosis and resolution. Giving those humans a better AI assistant does not change the underlying assumption. Replacing the workflow changes the assumption.The leaders getting this right are not asking their teams to adopt AI. They are asking a different question entirely: If agents handled everything reactive, what would this team build instead?Engineers Are Right To Be Skeptical, And Wrong To Stop ThereThe engineers who are skeptical are not wrong. AI-generated code requires review. A person who has spent five years mastering a codebase will produce better output in specific ways than a model working from context alone.The problem begins when accurate skepticism about today's limitations becomes a permanent verdict on tomorrow's capability. The models are improving, and the rate of improvement is not linear. Twelve months ago the best models were solving a third (registration required) of real-world engineering problems. Today that figure has more than doubled. The right question is not "is this better than what I can do right now?" It is "where is this good enough today to start building and expanding from there?"The goal isn't full autonomy on day one. It's a deliberate, evidence-based progression toward it, in the areas where the evidence supports it. It is a progression already being mapped in detail by the mobile engineering leaders thinking most seriously about this shift—moving detect, triage, resolve and prevent from human-owned to agentic workflows, stage by deliberate stage.The organizations making the most progress are the ones that gave their teams a clear framework for extending trust and then held them accountable to actually doing it.The Cost Of Indefinite EvaluationThere is a specific failure mode I want to name, because I see it constantly: the perpetual pilot.A team evaluates an AI tool, finds limitations, documents them and continues evaluating. Six months later the limitations are slightly smaller and the evaluation continues. The tool never gets operationalized. The workflow never gets redesigned.The cost is the compound opportunity cost of every sprint where your best engineers are doing triage instead of building. Google's 2025 DORA "State of AI-Assisted Software Development" report found that 30% of developers report little or no trust in AI-generated code, yet 90% are using AI daily. Engineers are using tools they do not fully trust, in workflows they have not redesigned, and organizations are calling it AI adoption. When our team asks prospects how they manage issue routing, how a bug surfacing in production gets to the right team, the answers range from manual spreadsheets to workflows only marginally better. These are large enterprises spending real human time on coordination work entirely automatable today. When teams make the shift, the results are concrete: agentic mobile observability adopters have already cut mean time to resolution by 50% to 60%, as seen with Dabble.The reason this has not been automated is not a technology problem. It is a prioritization problem, because making that change means acknowledging the current process is broken, and that is a harder conversation than running another pilot.What Leaders Actually Need To DoThree things change the outcome.1. Make the cost of the current process explicit. How many senior engineering hours per week go to triage, reproduction and incident response? When leaders make that opportunity cost visible in concrete terms, the conversation shifts from "is AI ready?" to "how fast can we redesign the workflow?"2. Separate the trust question from the quality question. "I do not fully trust the AI output" is not the same conclusion as "therefore we should not change the process." Define the workflows where AI performs reliably enough to own the outcome—let it own them and expand from there. The goal is not to replace engineering judgment. It is to eliminate the work that does not require engineering judgment at all.3. Hold the redesign to the same standard as any other strategic initiative. The organizations capturing AI value are not the ones with the most tools. They are the ones treating workflow redesign as a leadership priority with owners, timelines and accountability, not as a cultural shift happening organically when people feel ready.Five years from now, the gap won't be between companies that used AI and those that didn't. It'll be between the ones who redesigned around it and the ones who just gave their engineers a better autocomplete.Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
Your Engineers Are Resisting AI; Here's Why That's Actually Rational
The problem is not the skepticism or resistance. The problem is what most organizations do with it.









