Coaching a Predominantly Junior Team Through a Greenfield Aspire Build

The team I joined was around nine developers spread across three workstreams. Roughly two-thirds of them were junior, including bootcamp graduates and developers who were new to the languages they were working in. A senior teammate from the partner organisation, who had been the obvious source of domain depth, left shortly after I started. A junior teammate later went off sick for an extended period mid-project. The remaining team was capable and willing, but the bench depth was thin.

The other complication was the surface area the team had to cover. Greenfield project, three unfamiliar third-party platforms, two new languages or frameworks for parts of the team, .NET Aspire (which nobody on the wider team had used in earnest), and partway through the engagement the client adopted Claude Code internally as well. The inspection-driven programme meant there was no luxury of dedicated training time before delivery started. Mentoring had to happen alongside the build, not before it.

The risk this set up was the standard one for a senior-led greenfield. If I built the architecture in front of the team without bringing them with me, the patterns would not survive my departure. The team would either reach for what they knew and quietly drift the codebase off the architecture, or they would freeze on changes that touched anything I had built. Neither outcome was acceptable for a platform the in-house team would own afterwards.

My main mentoring channel was code review, not separate training sessions. There was no time for a parallel curriculum, and the work itself was a more honest teacher than any slide deck. Every pull request became a chance to surface the reasoning behind a pattern: not just "this is how we do it" but "this is why we do it, and here is what would go wrong if we did not". The reviews were deliberately slower and more written than fast-moving teams usually run them. That cost was paid back many times over in the rate at which the juniors absorbed the patterns.

I also led the build in a way that made the patterns easy to follow. The Vue.js component library had clear, named patterns for the common shapes the team would need. The C# back end was structured so that a new endpoint had an obvious template to follow. The progress engine had explicit boundaries between integration code, calculation code, and persistence code, with each separated cleanly enough that a junior developer could work in one without having to understand all three. The patterns earned their keep by being copyable rather than by being clever.

Aspire mentoring went through the IDE rather than through documentation. Because the app host was a typed C# project rather than a YAML file, I could walk people through configuration changes the same way I walked them through any other code change. That made Aspire an easier first encounter for the juniors than docker-compose would have been for the same group.

When the client adopted Claude Code internally mid-engagement, I extended the same pattern to AI-augmented development. The principle I taught was simple and load-bearing: verify, do not trust. Every Claude Code output is a draft. The team's job is to read it, push back on it, and feed corrections back. I demonstrated this with the actual outputs from my own discovery work, including the ones that had been wrong. Showing the team where AI had been wrong on this exact codebase was more useful than any general guidance about AI's limits.

In parallel I made sure the architectural decisions were made in front of the team rather than handed down. Trade-offs were verbalised. Alternatives I had considered and rejected were explained, including why. That meant when the team had to make their own architectural calls after I left, they had a worked example of what an architectural argument actually looks like, not just a finished position.