Everything else on this site describes something that worked. This page describes the problem I have made the least progress on, and it is not a technical one.
I can demonstrate that these tools produce real systems. I have the projects to point at. What I have not managed to do is get most of the people around me to use them meaningfully, and the reasons are more interesting than simple reluctance.
What the resistance looks like
It is not refusal, since nobody has told me they will not use it. The pattern is subtler and more durable than that, and it shows up in three recognizable forms.
Confidence. Most of my colleagues are good at their jobs, and they know it. When you already know how to solve the problem in front of you, reaching for help looks like a detour rather than a shortcut. The tool gets evaluated against tasks they could already do, judged as unnecessary, and set aside. That judgment is correct on those tasks. The trouble is that it generalizes.
Fear of atrophy. This one comes up more than any other, and usually indirectly. The concern is that if the tool does the things they currently do well, they will lose the ability to do them. It is not an unreasonable worry, and I do not dismiss it, but it produces a specific and costly behavior, described next.
Avoiding the hard problem. This is the consequence I find most concerning. If needing help is evidence of decline, then the safest move is to only take on work you are certain you can finish unaided, and the difficult problem does not get attempted at all. Not because it is beyond anyone, but because attempting it might require assistance, and requiring assistance has been quietly recoded as a signal about competence.
The cost of that is invisible on any dashboard. Nothing fails. Work gets done. The ambitious version of the work never gets proposed.
The inconsistency I keep coming back to
Here is what I cannot make sense of, and it is where I think the argument lives.
Every developer I have ever worked with looks things up, on Stack Overflow, on Reddit, on Slashdot for those of us who go back that far, in vendor documentation and forum threads, from a colleague at the next desk, a conference talk, or a blog post by someone who hit the same error in 2014. Nobody has ever considered this cheating. Nobody worries that reading a forum answer will erode their ability to think. Looking it up is how the work has always been done.
An AI assistant is, for a large share of what people ask it, the same activity with less friction. You describe a problem and get a candidate answer that you must then evaluate, adapt, and verify, as you would with an answer from a forum thread. The obligation to check it is identical, because the answer is wrong sometimes in both cases.
Why, then, does one feel like professional practice and the other feel like dependency? I do not have a satisfying answer. The best I have come up with is that a forum answer arrives with visible human authorship and visible uncertainty, votes, replies, someone disagreeing underneath, while an assistant delivers a single fluent response with no such texture. Fluency reads as authority, and authority is what people feel uneasy about deferring to.
If that is the mechanism, then the fix is not persuasion about capability. It is teaching people to read the output the way they already read a highly upvoted answer from a stranger: useful, probably right, occasionally confidently wrong, and always your responsibility once you act on it.
What I have tried
Several things, with modest results, and I would rather report that honestly than describe a program that worked.
Shared, version-controlled conventions instead of individual habits, so the practice is documented and reviewable, not folklore. This helps the people already using the tools and does not move the people who are not.
Working in the open, publishing the mistakes alongside the results. Every project keeps a lessons file, and three of my own documented conclusions in the model evaluation were wrong and are corrected in place, not quietly replaced. The intent is to make being wrong in public normal, since fear of looking incompetent is clearly part of what is happening here.
Demonstrating on real work, not in demos. The applications exist, they are in production, and colleagues use them. This is more persuasive than any argument, and it has still moved fewer people than I expected.
Not mandating it. I have deliberately not made use of these tools a requirement. A mandate would produce compliance, and compliance in this area produces the shallow, unverified use that gives the skeptics their evidence. I would rather have slow genuine adoption than fast performative adoption, though I hold that position less confidently than I did a year ago.
What I think the real answer might be
My current working theory is that the framing is wrong at the root, mine included. I have been implicitly arguing that the tool makes people more productive. That argument lands badly on someone who is already productive and is worried about their skills.
The better framing might be about ambition, not efficiency: not that you will do the same work faster, but that you can attempt work you would otherwise have declined. That reframes assistance as reaching further rather than compensating for a shortfall, which is a materially different proposition to someone whose real concern is their own capability.
I have not tested that yet.
An open request
I would like better ideas here.
If you have led a team through this or been on the receiving end of it and can articulate what changed your mind, I would like to hear it. Especially if you have found a way to address the atrophy concern that does not require dismissing it, because I do not think it is a silly worry and I do not think telling people it is unfounded works.
The response form comes straight to me, or you can reach me through LinkedIn. I will read anything sent and reply to anything substantive.
Why this page exists
It would be straightforward to leave this out. Every other page here describes something that worked, and a portfolio is normally an argument for competence, not a list of open problems.
I have included it because the adoption problem is the one that determines whether any of this matters at an organizational level. A single person delivering 10 projects with AI assistance is a useful data point. A department where the practice is normal, governed, and reviewable is a different thing, and I am considerably closer to the first than the second.
That gap is the work I am most interested in now.