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 actually looks like
It is not refusal. Nobody has told me they will not use it. The pattern is subtler and more durable than that, and it shows up in three recognisable forms.
Confidence. Most of my colleagues are genuinely 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 generalises.
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 behaviour, 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. So 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 simply 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 actually lives.
Every developer I have ever worked with looks things up. Stack Overflow. Reddit. Slashdot, for those of us who go back that far. Vendor documentation, forum threads, a colleague at the next desk, a conference talk, 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 simply 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 then have to evaluate, adapt, and verify, exactly as you would with an answer from a forum thread. The obligation to check it is identical. The answer is wrong sometimes in both cases.
So why 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 programme that worked.
Shared, version-controlled conventions rather than individual habits, so the practice is documented and reviewable rather than 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 two of my own documented conclusions in the model evaluation were wrong and are corrected in place rather than 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 rather than 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 particular area produces exactly the shallow, unverified use that gives the sceptics 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 rather than 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 properly yet.
An open request
I would genuinely like better ideas here.
If you have led a team through this, or been on the receiving end of it and can articulate what actually 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.
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 rather than a list of open problems.
I have included it because the adoption problem is the one that actually determines whether any of this matters at an organisational level. A single person delivering ten projects with AI assistance is a useful data point. A department where the practice is normal, governed, and reviewable is a different thing entirely, and I am considerably closer to the first than the second.
That gap is the work I am most interested in now.