As someone who’s relatively new to working in the software realm, agentic coding was really challenging for me at the start. At the time it really took off, I was surrounded by incredibly talented senior devs. They were able to leverage agents so much bc of their years of experience, but I struggled bc I was still relatively new. It was challenging to articulate this to them due to the curse of knowledge, and likely their own excitement about being able to build instead of manage.
I’ve gotten better with agents since then, but there’s still a ton I need to learn. It’s difficult, especially with the external pressure to set a higher pace of business. Hackathons can be helpful, but the participants need to have autonomy in their ideas. I was at an org where one year they let groups pick their projects, and the next it was assigned from the product roadmap; that sucked all the fun out of the hackathon for me.
It’s challenging to learn given a tool that can seemingly do anything you need it to. For instance, I started learning a new programming language recently, and I’m trying to use LLMs to help expedite the process. I still am working thru leaning the syntax and patterns manually, but I know I could just have an LLM write the code for me. It takes effort and willingness to learn, sounds like your juniors have that, so they probably need the opportunity/time.
Spending time on something that doesn’t move the needle for the business is always a challenge, but I suspect that’s what’s needed. Give them small challenges (1-2 hours max) and tell them they’re not allowed to use any AI tools. If/When they get stuck completely, they should ask someone for help, not an LLM. Struggling thru problems is how I learn best, and from experience it’s the same for many others.
I also wonder if group PR reviews should come back? I never participated in one but I did hear about them before I got into software. Again, it can be rough bc it’s a time sink and people don’t generally like reviewing PRs (plus it’s another meeting). Despite those aspects, I could see a group PR as beneficial since it would give senior devs a chance to teach the juniors, even without trying. An offhanded comment or question about changes, can really make a difference, but an online review is unlikely to be seen by others if they’re not reviewing or responsible. I’m sure that’s not a popular idea, but it’s an idea I think is worth trying. I go out of my way to read/review PRs that have nothing to do with me bc I learn a lot. One company I worked for did weekly “system review” calls where someone shared what they were working on, kinda like a group review but more sharing than reviewing.
You might also suggest they add some lines to their AGENTS.md to challenge them about why or how a decision was made, or to explain (always concisely) why it makes more sense to pick a certain path (when the LLM chooses the direction). The tools that make learning harder, bc we end up doing less, can absolutely be made into useful learning tools (assuming the outputs are read). I have my agents write a “lessons learned” document for every project. It helps the agent avoid making the same mistakes, but it’s also useful for me, and sometimes I ask the LLM questions about its entries so I can gain the knowledge from its mistakes (forking the sessions to continue the work while asking questions helps a lot here).
Regardless of AI tools, I think the biggest thing that can help people learn and grow, is an environment that permits failures. Be clear about what type and where failures are “safe” and let the juniors make mistakes there. Fear of failure holds people back and can prevent people from leaning. Confidence generally comes from the mindset of, “I can figure that out,” but without working thru failures, that confidence can’t be built. This is something I haven’t seen at many larger orgs, but smaller startups tend to accept mistakes will be made, it’s important to be clear about what’s a ‘safe’ mistake tho.
I also find that environments that encourage questions and challenges can help me grow. I do it everywhere, but I often have to tell people that I’m doing it bc I want to learn and not bc I’m trying to be a jerk. Not everyone is like that, but fear of failure or looking “dumb” can hold people back from asking questions. I’m the idiot who will ask the “obvious” or “silly” questions bc I don’t have that fear, but I know others do. I think having an environment where failures and asking questions are allowed is absolutely key.
One last idea that’s more stick than carrot, is to simulate a Claude outage, or early limit overage. Have them try to do at least one step without an agent, this is especially difficult when mid “vibe” on a project. It’s a real problem they’ll have to face and learning how they can tackle that is likely to be a huge help. Might be tough to avoid using the tools, but it’s a great learning opportunity. Maybe during the next outage, check in with them to see what they have going on and how you can help them get unstuck (if they are).
I assume most of not all of them got into software development for a reason. That’s probably something to ask about too. Knowing their “why” might help you understand what it is they’re most interested to learn about. The fact they want to learn is great, hopefully these ideas give you some ideas on how to help that. Personally I’m the most excited when I leaning something new, and especially when I get to use or share that knowledge. I suspect that for most, learning is the means to some end, for me it’s what I love, so asking about their interests will probably help figure out what they’re most interested in learning.
.