The observation about AI being more useful as a "thinking partner" than a code generator matches my experience exactly. The flip moment for me was when I stopped asking the AI to write code and started asking it to explain unfamiliar codebases, review my architecture decisions, and suggest approaches I had not considered.

The other thing that made a massive difference was investing in project context files. Most teams use AI tools with zero project-specific context — the AI knows nothing about their conventions, patterns, or architecture decisions. It is essentially a smart stranger every session.

When you give the AI a well-written .cursorrules or similar context file that encodes your team's actual patterns — naming conventions, preferred libraries, error handling approach, testing philosophy — the output quality jumps dramatically. Instead of generating generic React code, it generates code that looks like YOUR team wrote it.

I have been maintaining cursor rules across 16 frameworks and the pattern is consistent: teams that invest 30 minutes upfront writing good context files get maybe 3-5x more useful output from AI tools than teams using them out of the box. That initial setup cost is what makes the difference between "neat toy" and "actually changed my workflow."

The social contagion effect you describe (one engineer starts, others follow quickly) is real too. In my experience it usually starts with someone sharing a particularly impressive AI-assisted debug session or refactor, and then everyone wants to know how they set it up.