AI & Repository Strategy
For many years, there has been an ongoing debate between monorepo and polyrepo fans (I'm on the monorepo side, by the way, but that's not the topic today). Today, I'd like to look at these approaches from a slightly different angle: the speed of introducing changes.
Over the past year, our industry has gone through a significant transformation. We changed harnesses, introduced skills, built agents, engineered loops, adopted SDD, and so on. And it seems we're still far from the end.
All of this requires a very high speed of adoption and adaptation at the team level. This means that everyone should use the same SDD framework and approach to specs, the same set of skills and their versions, and the same agents built into the workflow. Across all repositories in use.
And that's where I see a huge difference.
With a monorepo, you just need to bring the required set of skills or CI steps into the repository, commit them, and that's it. Whether the team wants it or not, the agent starts using the required skills, the required automation steps start running for everyone, and the team learns faster because they can't bypass the new rules committed to the repository.
With polyrepos, everything is much more complicated (the problems start with tens of repos and become much more complicated with hundreds). Not only is the context fragmented and needs to be assembled into a virtual monorepo, but you also need to bring the same set of skills into all repositories, control the process of updating them, figure out where and how to store SDD specs, and deal with other problems.
From what I see in practice, everyone invents their own wheel to somehow solve this problem. But it takes time and resources. It's slow.
So it turns out that when it comes to the speed of introducing changes across a team, monorepos definitely win.
#ai #engineering #ci #leadership
For many years, there has been an ongoing debate between monorepo and polyrepo fans (I'm on the monorepo side, by the way, but that's not the topic today). Today, I'd like to look at these approaches from a slightly different angle: the speed of introducing changes.
Over the past year, our industry has gone through a significant transformation. We changed harnesses, introduced skills, built agents, engineered loops, adopted SDD, and so on. And it seems we're still far from the end.
All of this requires a very high speed of adoption and adaptation at the team level. This means that everyone should use the same SDD framework and approach to specs, the same set of skills and their versions, and the same agents built into the workflow. Across all repositories in use.
And that's where I see a huge difference.
With a monorepo, you just need to bring the required set of skills or CI steps into the repository, commit them, and that's it. Whether the team wants it or not, the agent starts using the required skills, the required automation steps start running for everyone, and the team learns faster because they can't bypass the new rules committed to the repository.
With polyrepos, everything is much more complicated (the problems start with tens of repos and become much more complicated with hundreds). Not only is the context fragmented and needs to be assembled into a virtual monorepo, but you also need to bring the same set of skills into all repositories, control the process of updating them, figure out where and how to store SDD specs, and deal with other problems.
From what I see in practice, everyone invents their own wheel to somehow solve this problem. But it takes time and resources. It's slow.
So it turns out that when it comes to the speed of introducing changes across a team, monorepos definitely win.
#ai #engineering #ci #leadership