AI: InnerSource Usurper or Superpower? #InnerSourceSummit2025  So, it's kind of a strange time to be an inner sourcing enthusiast, right? Because in the past, the inner source journey has looked something like this. I have to go find a solution that works for my use case, read the documentation and figure out how I can leverage it, likely contribute back to that solution so that it meets my needs. Probably talk to the maintainers along the way and then stay up to date with any changes to the solution that I adopted. But now the equation has changed. I can just ask AI to build exactly what I need. Give it my requirements, get some real-time suggestions, and get a solution that I maintain full control over. That seems a lot faster and easier than the journey on the left. So, has AI usurped inner source? Or are the problems that inner sourcing solves exacerbated by AI? In the past, that inner sourcing journey was worth it because I was saving time by reusing something that another team had built. They had done the heavy lifting and I wasn't wasting time, money, or resources reinventing the wheel. With AI assisted coding, we may be spending less money, time, and resources, but we risk developing those same silos. The answers to these questions are paramount at Booze Allen, where we're building advanced technology and AI solutions for federal government clients. And in the current climate, efficiency and cost savings are key. I'm Lizzie Celita. I'm a senior software engineer and developer experience strategist. I'm currently in a customer success engineering role for Booze Allen's platform engineering product team and I've also worked on our internal developer portal and some of our early inner sourced projects in the past. So yes, sometimes it will be faster and easier to ask an LLM to build exactly what you need, but each step of the inner sourcing journey relates to a principle that's healthy for our organizations. And if we give up on inner source, we risk losing ground on the things that make our organizations innovative and resilient. Transparency powers the discovery and adoption phase. Communitydriven development sharpens those reusable solutions through contributions. And the collaboration between adopters, maintainer and maintainers underpins the ecosystem. Today we'll look at each of these three areas and consider one how these principles can actually help in the development of AI solutions themselves and two how AI can actually be a superpower and accelerate the inner sourcing journey. We'll also look at examples of this at Boo Allen where we're embracing the intersection between AI and inner source. In the transparency, adoption and discovery phase, well doumented and discoverable code is the norm in inner source. You may even have a catalog that's pointing to vetted and governed solutions. And that same level of highquality documentation and accessibility is critical for building up a organizational context for LLMs to be able to learn from it and agents to interact with it. If like me you dream of an a secure all- knowing chatbot that understands how your company builds software, what libraries are available and how to integrate with them. the same transparency and accessibility uh is necessary to have that knowledge written down so that agents can interact with it and LLM can learn from it. On the flip side, how can AI help with the discovery and adoption of those reusable solutions? One example of this at Booze Allen is our platform engineering team has an AWS cloud development kit constructs library. You can think of the AWS CDK constructs as Lego blocks for cloud infrastructure. And this library is inner sourced because it's intended to be used by multiple teams including the core platform engineering team for multiple instantiations of the platform and also for tenants of the platform itself. And this library is made up of internal booze Allen IP. So an AI assisted coding tool like cursor wouldn't know about it because you can't find information about this on say Google or Stack Overflow. So the team added an MCP server for the construct library so that developers can install it in their AI assisted coding tool and then cursor or whatever their tool of choice is has access to what constructs are available and how to use them. A couple of things to note about how this works. The documentation that powers the MCP server is autogenerated based on comments which are enforced by a llinter. So that ensures that the documentation stays up to date when new constructs are added or existing ones are modified. And we also chose to create an MCP server rather than just giving AI assisted coding tools access to the documentation itself because the documentation is already over 10,000 lines of code long. Another caveat is that a developer would have to know that the constructs library and this MCP server exists in the first place in order to install it in their coding agent and take advantage of it. Which leads me to our next example. The second principle is communitydriven development. And I believe that the code underlying AI solutions will better reflect the collective ingenuity of your organization when it's sharpened by feedback and contributions from developers outside just the team that's developing it. We want to reduce risk by concentrating our efforts around security and compliance on a reusable solution so that we're not having to go and update uh generic AI generated solutions in multiple places. So I believe that the principles of communitydriven development are even more important in an AI enabled world. How can AI be a superpower for communitydriven development? You can think about AI agents and tools helping with some of the drudgery and non-creative elements of contributing. Doing things like helping to write unit tests, generate documentation or fix linting errors, the things that aren't core to the value of a contribution, but can take hours of maintainers and contributors time. So, where do these agents and other agents that your company may be developing come from? One thing we're developing at Boo Allen is an agent studio. I love this example because we're applying the concepts of inner source to the development of agents themselves. There's an agent marketplace where you'll find templates and boilerplate code for how to start building agents and some examples that are already pre-trained for specific purposes. Similar to a micros service or a UI component, we're enabling the discovery, adoption, and contribution to different elements of agent orchestration and single agent construction. In many cases, multiple agents will be necessary for a use case. So, it's helpful to have standardized documentation and some baselines around how agents can talk to each other. Going back to our previous example, one of the elements is an MCP server catalog. So this is where a developer could find and discover the m uh AWS construct library MCP server and start building an agent that could integrate with it. The agent studio is helping us to scale knowledge in the rapidly evolving field of agentic AI and upskill our engineers. The final principle I'll cover today is collaboration. and developers talking to each other builds trust helps improve job satisfaction and create a sense of belonging that AI cannot replace. However, I do believe that AI can elevate collaboration especially when it comes to handoffs between crossf functional teams. One program that we work on at Booze Allen has an inner sourced design kit and corresponding UI component library. These were created to help facilitate the handoff between designers and developers uh and make that handoff process more seamless. And the team that maintains the inner source component library added two elements recently. Um, one is a Figma MCP server which allows developers to pull uh Figma design elements directly into their code editor and another is a set of specific GitHub copilot instructions which added the component libraries TypeScript TypeScript definitions to the context in C-pilot. By doing this, developers can now point to a design and based on Copilot's knowledge of the component library, it can autogenerate front-end code um based on the components and that design it was given, making that handoff basically automatic. And this would be really cool and provide a lot of acceleration for just one development team. But the fact that these libraries were inner sourced and used across lots of smaller autonomous development teams on the program means that the acceleration that AI is providing here gets multiplied across all of those teams. So as we've seen in the examples, the combination of AI tools and governed proven inner source solutions helps to combat some of the non-deterministic behavior of AI which is critical when developing missionritical systems. So back to the original question is AI usurping inner source? I hope I've convinced you the answer is no. I know I'm preaching to the choir a little bit here and I couldn't resist uh using AI to generate our inner source hero uh which you'll see on the screen. But I just would like to say in conclusion, inner source, it encourages us to stay curious about what other teams are building, to contribute back to what other teams are building, to continually make it better, and to build bridges and connections between development teams and individuals. On that note, I'd like to thank uh some of my teammates who provided the examples that you saw today. Steven Toronto, Jennifer Shepard, and Connor Youngland and their teams. And thank you, and I look forward to connecting throughout the rest of the summit., AI: InnerSource Usurper or Superpower? #InnerSourceSummit2025, YouTube, 01kchg8exkbs5gcwgtmr73yswb.