When AI-First Becomes a Loyalty Test
Adoption pressure can teach engineers to perform belief instead of improving the work.
A team is in planning. Someone asks for another engineer, another month, or a narrower scope. A few years ago, the useful questions would have been about the problem, the risk, and the cheapest responsible way to reduce it. Now a different question can become the ritual: did you try it with AI first?
That question can be healthy. Some engineers still underuse tools that would remove boring work, surface options, or force a sharper explanation of the problem. I do not think engineering leaders are wrong to expect people to learn AI. Refusing to build any muscle with these tools is becoming its own professional risk.
The problem starts when “AI-first” becomes a test of seriousness. Once the expected answer is visible, people learn to produce that answer. They mention the tool in planning. They add it to the workflow where it can be seen. They show the demo. They write the performance-review paragraph. The company gets evidence of adoption before it gets evidence that the work improved.
Luiza Jarovsky’s essay, When AI Becomes a Religion, is too broad for the exact piece I want to write, but it names a pattern worth taking seriously inside companies: salvation language, dogma, and the awkward role of the heretic. I would not import the whole religion frame into engineering. It gets noisy quickly. The workplace question is what happens when skepticism starts to carry a social cost. The engineer who asks for evidence, slows a rollout, or says the generated code made review worse can start to look behind the culture, even when they are protecting the feedback loop the organization needs.
Shopify is a useful public example because it turns the cultural pressure into an operating rule. In April 2025, coverage from Business Insider and The Verge described a memo from CEO Tobi Lütke that made AI usage a baseline expectation, asked teams to show why work could not be done with AI before requesting more headcount or resources, and added AI usage questions to performance and peer review. There is a reasonable version of that management instinct. Headcount should not be the default answer when tools and workflow changes can absorb some of the work. A serious organization can expect people to try available leverage before asking for more capacity.
The failure mode starts when proof of trying becomes more important than the quality of the result. If a team knows the safest answer is “yes, we used AI,” then people will learn how to produce that answer. They will add the tool to the workflow, mention it in planning, show a demo, or include it in a review packet. That may be sincere learning. It may also be adoption theater. From the outside, both can look similar unless leaders measure what happened downstream.
When usage becomes safer than judgment
Usage is attractive because it is legible. Licenses activated, prompts submitted, features shipped with AI assistance, agents connected to repositories, demos shown in all-hands meetings. These numbers make the rollout visible. They do not prove that the organization is building better software.
The Stack Overflow 2026 pulse survey is useful precisely because it holds two ideas together. Workplace agent usage had risen: 59% of respondents said they used agents at work, nearly double the 31% Stack Overflow reported from its 2025 Developer Survey. At the same time, 63% of technologists said they rarely or never let agents run fully on autopilot. The survey was self-reported and had 1,100 respondents, so I would treat it as directional. Still, the tension is the one engineering leaders need to understand. Adoption is real, and supervision is still doing a lot of the work.
If leadership celebrates usage while the work still requires supervision, the supervision still has to happen somewhere. It usually lands with senior engineers, reviewers, tech leads, and managers who have to decide whether the generated output is correct enough to ship. The prompt may be faster than writing the first draft of the code. The review can still become slower, especially when the author cannot explain the change, the test is brittle, or the diff is plausible in ways that make mistakes harder to spot.
Moreover, DORA’s 2025 AI-assisted software development report pushes the conversation away from tool access alone and toward the system around the tool. Local productivity gains matter only if they translate into product performance instead of downstream chaos. A team can produce more code-shaped output and still make the engineering system worse.
There is also a social layer. AI tools are not neutral calculators inside a team. OpenAI’s post on sycophancy in GPT-4o is a reminder that model behavior can affect trust: the company rolled back an update after GPT-4o became too flattering and agreeable. A tool that agrees too easily can make a weak plan feel stronger than it is. A company culture that rewards visible AI enthusiasm can do the same thing from the other side. The model says the plan is good. The dashboard says adoption is up. The executive story says the team is modernizing. The reviewer who says “this is not ready” becomes the inconvenience.
What I would measure instead
If I were accountable for an AI rollout, I would not ask teams to prove they are bought in. I would ask where AI made the engineering system measurably better and where it shifted cost out of sight.
For code review, I would look at whether reviewers are catching better issues or just reading more generated diffs. For incident response, I would look at whether AI-assisted summaries improved diagnosis without flattening uncertainty. For onboarding, I would look at whether new engineers reached useful context faster and whether they could still explain the systems they touched. For migrations and maintenance work, I would look at whether generated changes reduced toil without increasing the burden on the people who own the code after the migration lands.
Those questions are slower than adoption dashboards, but they are closer to the work. They also leave room for the honest positive case. Sometimes AI will be the right answer. It can remove blank-page friction, draft tests, summarize unfamiliar code, produce a first pass at support tooling, and make a senior engineer faster when the senior engineer still owns the judgment. The critique is aimed at pressure that creates bad data.
A useful leader should want the bad data. Failed prompts, wrong assumptions, unreviewable patches, brittle generated tests, and moments where the tool made someone faster but less clear about the work are not signs of disloyalty. They are rollout telemetry. If people hide those signals because skepticism sounds like resistance, the organization loses the information it needs to adopt AI well.
Protect the useful skeptic
In an engineering organization, the useful skeptic is often not trying to stop adoption. They are asking the question that keeps adoption honest. What got better? What got worse? Who absorbed the review cost? Which failure mode disappeared, and which one moved to production? Did the team learn a reusable workflow, or did one person get a private boost that nobody else can inspect or improve?
That distinction matters for senior engineers. A senior engineer who pushes back on a shallow AI mandate should not sound anti-tool. The stronger posture is more demanding: show me the outcome, show me the review path, show me what we learned, and show me where the tool made the system less reliable. That is not nostalgia for pre-AI engineering. It is the production discipline we should have been using all along.
It also matters for managers. If “AI-first” becomes a loyalty test, managers will get the answers they trained the organization to produce. People will describe their work in AI-friendly language. They will use the tool where the tool is visible. They will avoid being the person who sounds slow, difficult, or unconvinced. The organization may feel aligned while its feedback loops get worse.
The healthier version starts with the work: the workflow, the risk, the customer outcome, the review burden, and the learning the team needs to keep. Then ask where AI helps and where it creates a new failure mode. Engineers do not need permission to be curious about AI. They need permission to report the truth about it.
That is the line I would want leaders to protect. Push people to learn the tools. Do not punish the people who keep the evidence honest. In a serious engineering organization, the person who refuses to turn usage into faith may be part of the control system that makes adoption work.