I recently got introduced to Claude Code by a friend who quit their job to build a new product entirely on their own, by leveraging Claude to maximum effect. So that was kind of an awakening moment for me: The possible gains of productivity when putting it to good use are pretty incredible. I had been following the space closely, but after my experiments with early Cursor half a year ago, I didn't consider really working with coding agents. The last weeks, I did make massive progress on an OSS pet project of mine that has been stalling for years. So at this point, I realised I'll have to onboard my team at work to Claude Code, and finally improve on development velocity—the one, recurring complaint from the rest of the company.
However, I am wondering how to do this properly: I don't want to loose buy-in from a team with very diverse needs, and risk leaving either seniors frustrated with their job changing completely nor juniors playing with a blackbox they have no chance of understanding, or working with effectively. The more time I spend thinking about it, the more I realise how fundamental development processes change now: From setting up Claude to pre-screen GitHub issues and make a plan before we even start, to addressing all those long-standing but tedious tasks that have been laying around forever, rules for what we can do and how we work have changed entirely.
Now I think I am not the only one who experienced some variation of this story, and I want to know how you introduced your engineers to coding agents? Do you have reading recommendations or tips to get people started? I'm grateful for any advice here.
Oras•2w ago
I would start with internal tools, something you want to build fast, but you don't need to deploy or make it public-facing. This will give them time to learn how to collaborate by making AGENTS.md, skills, and MCPs (if required).