u/david-vujic

During this year I have made seven feature releases and a bunch of smaller fixes to the Open Source project that I maintain. The project adds useful tooling support for Python Teams that develop things according to the Polylith Architecture. One new feature is the possibility to inspect the coupling between code. In Polylith, code is logically grouped into smaller reusable parts with clear boundaries between them. Those are called Bricks. In Python, a brick would be a package within the same repo.

The feature is about visualization and validation of the package interfaces across the repository. With a simple command, you will find out if code is bypassing the explicit interface of a package. In Python, the interface of a package can be defined in the __init__.py, but it is an optional feature.

There's benefits of having code that interacts via explicit interfaces: from an Architecture/Software Design point of view but also from a practical point of view. Such as refactoring: code will be very easy to move and rearrange when having the interface defined clearly. There’s also a lower risk of breaking things when changing the code within a package. Circular dependencies is another thing that might cause unwanted side-effects. It can be valid to have two packages depend on each other, if the imports are for different modules in the packages. But this is an indication that something might be wrong with the design.

When developing the visualization and validation of these things, I discovered that the Open Source tool itself bypassed the explicit interfaces in a couple of places and also had a package-level circular dependency. Better practice what you preach, right?

So I fixed that and wrote a short post about it:

https://davidvujic.blogspot.com/2026/07/practice-what-you-preach.html

As many developers today, I'm using agents on a daily basis for software development. At work, we went all-in Agentic Engineering in early 2026 and for me it has worked well. I haven't yet found a need to rebuild an existing SaaS tool from scratch with AI, though.

In this post, there's some reflections after about six months of developing software according to Agentic Engineering.

https://davidvujic.blogspot.com/2026/06/reflections-6-months-of-agentic-engineering.html

What’s needed for an architecture to fit well in the agentic era? Probably many things, but I would say at least simplicity and available context as two very important things to consider.

Even if it for sure was not the purpose from the beginning (it was born many years ago), Polylith is about that and is a good choice for Agentic Engineering. That’s a nice side-effect of keeping things simple and having all necessary context at your fingertips, which is the guiding star for this software architecture. A year ago, agent-friendly architectures was not something I had thought about at all. Today, a lot of things has changed. But many ideas about good software remains valid.

If you haven’t heard about Polylith, here's an elevator pitch: the main use case is having Microservices in a Monorepo, and share code between the services.

It’s an architecture with useful tooling support and great development experience for both humans and agents. All of it is Open Source. I’m the maintainer of the tooling support for Python, and teams can use it with their favorite existing tools (such as uv, poetry, pdm, pixi, maturin, hatch …). The Polylith tool also includes a set of agent skills, that will add knowledge about Polylith in general and the available commands to your agent. Recently, I also added skills that are specific for migrating a single-repo Python project into a monorepo. I hope that this will help teams to start using this way of structuring code.

The code in a Polylith monorepo is basically building blocks, just like LEGO bricks. Some bricks are small, some are bigger and some are a combination of other bricks. All code lives in a well-structured Monorepo (without symlinks or complex custom setups). The code is organized into smaller reusable parts with clear boundaries between them. The tooling will notify if these boundaries are bypassed or if references are circular.

LEGO brick and code, what’s the connection? In Python, a file is a module. One or more modules in a folder is a package. One or more packages can be combined into a feature. In Polylith, this is called bricks. There are two types of them: components and bases. Components are the main building blocks in Polylith. This is where the business logic lives, the actual features and functionality. Bases are the entry points to your apps or services. A base should ideally be thin, and delegate the business logic to components.

Microservices are great, but the standard setup can introduce new problems: code in many places, duplications, shared code as libraries (that means even more repositories) and different versions of everything. That can be a lot of things to maintain, for agents too.

With a monorepo structured as a Polylith, the agents will have all the necessary context in one single place. It’s right there! Agents perform better when things are simple, very much like us humans. Besides having all needed context, an agent can also use the Polylith tool just like a human would. This will save tokens, and likely speed up the development process even more. The agent skills of the tool will tell the agent how and when to use it. Having all code there at your fingertips is also great for Test & REPL Driven Development, making coding both joyful and interactive.

Repo: https://github.com/DavidVujic/python-polylith

With Agentic Engineering there's an opportunity to refactor legacy code, but this aspect of AI isn't that that much talked about and seems to be overlooked by teams out there.

I’ve been focusing on this lately, and have added agent skills to the Open Source project that I maintain: the Python tools for the Polylith Architecture. The skills are for migrating and refactoring an entire Python project into a well-structured and agent-friendly Monorepo.

But agents are unpredictable and different models behave differently. I have test-run the skills with Claude Opus and Mistral. If you will try this thing out, please share your feedback how the skills worked for you.

My post about this subject:
https://davidvujic.blogspot.com/2026/06/refactoring-with-ai.html

The Open Source project:
https://github.com/DavidVujic/python-polylith