How do you onboard a new engineer to a project when most of what they need to know is not checked into the code at all? It’s the agent configuration. It’s the rules about commands, the conventions the agent applies automatically because it’s stored in your memory. That isn’t shared.
\nI think we’re still figuring out the answers to this. I’m not sure that we should be sharing the context file. I don’t think we should be sharing subagents. I could see skills being a shared resource.
\nI think it’s more important that you don’t share everything. The things that should be shared, share cleanly. Set it up like you would set up linting rules on your pipeline.
\nUnderstanding how the other person intends to be productive will impact what items need to be shared. Having access to a good memory system is way more important than checking in your context file.
\nWhen a new person joins, of course, give them access to the code. Of course, give them access to things that you’ve agreed upon should be shared. But you should also talk with them and understand what their expectations are of a real workflow from end to end. Do they have the tools that they need in order to build reliable and repeatable workflows that will get results?
\nAccess to the tools that they need is more important than sharing every single tiny detail.
\nPeople responsible for making changes to a system can learn a lot by just doing. You need to understand the tools before you can understand the system.
\n\n\n", "date_published": "2026-08-11T10:00:00-05:00", "url": "https://llbbl.blog/2026/08/11/onboarding-a-second-engineer-to.html", "tags": ["Developer-tools","Documentation","Agentic-coding","Engineering-teams","Onboarding"] } ] }I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.
\n