I’ve recently started working on a client project that is using Agentic AI to develop a sizable mobile application with a medium sized team. There are a couple of lessons I’m learning about how AI and architecture fit together.
We have found the number of lines of code each developer generates is far more than they normally would generate on their own. This means we run a higher risk of merge conflicts. To mitigate this, we are ensuring we are working on different areas of the application, spreading ourselves out, to ensure we aren’t undoing each others work. Our architecture is helping us, as much as our careful prioritization of the work to be done.
Good Fences Make Good Neighbors
The core principle we are using is Bounded Contexts. Bounded contexts are a means of using modules, namespaces, compilation units, and other isolation techniques to ensure similar sounding but subtly different concepts aren’t causing more headaches by ensuring they have clear boundaries and contracts between them. it also means that work inside of one context should not just manipulate code inside of another. Inside of any given context, a team of agents are free to coordinate themselves to ensure they` don’t collide, usually with good planning and task ordering.
Nowadays, it seems like most developers are using this to talk about micro services, as independently deployed services speaking over wire protocols have hard boundaries and published contracts. But we’re a mobile application, so we make do with interfaces and DTOs when we need to cross boundaries. In practical terms, the bank account object and services you use to check your balance aren’t the same objects you use to determine which tax documents you’re downloading.
When Every Developer is a One-Man-Army
Each developer on our team is doing the equivalent of a small team’s worth of work each week. This means we can’t just coordinate like we have historically. I’ve managed to get some of our SEPeers to read Team Topologies and our initial take-away was it was useful when discussing how we interface with our customers and their teams of teams. But now, inside of this team of 5 developers we are using the concepts of value-stream separation, platform teams, and expert teams to enable us to work more independently, with fewer collaboration costs. Don’t get me wrong, we are collaborating more than we would per calendar day on a traditional engagement, but we are collaborating far less per KLOC (Thousand Lines of Code).
When we are interacting, we are focusing on clarity of the three interaction models from Team Topologies:
- Collaboration – a temporary high bandwidth and high friction interaction to understand and clarify boundaries.
- X-as-a-service – much lower touch interaction once the initial collaboration is finished where an api or library is provided to other developers
- Facilitating – Pairing or other high communication work to help one team member learn techniques or knowledge from others.
Now in Pocket-Sized!
I would recommend teams using agentic development to take a look at architecture technologies and techniques meant for larger projects and teams of teams and see if they make sense as a means of streamlining their work. Some of these were developed for 100+ developer teams and would be far too heavy weight for a traditional 3 person team. I’m not suggesting that each project needs a fleet of micro services, but that spending time outlining the value streams and bounded contexts to ensure each team of agents have plenty of elbow room without causing issues bumping in to each other.
