Vacay Mode

"Do I still know how to code?"

I'm fortunate enough to have a vacation for so long that I eventually stopped thinking about AI, LLMs, Python, Work or even emacs. Traveled with the family by Train to nice places in Europe.

Our first stop was Berlin, and we arrived with the Night Train from Stockholm. We spent two days in the City with so much modern history. Then, a fast train (299 km/h was the fastest I noted) from Berlin towards Garmisch-Partenkirchen. A lovely village in south Germany with amazing surroundings!

Next stop was our main destination: Lago di Garda, Italy. We got there by traveling through Austria and the Brenner Pass. We spent a week in this wonderful place. Instead of Models or Prompting, there was Magnificent views and Pizza.

When traveling back home, we took a similar route going towards München (Munich). We spent one night there and continued to Hamburg the next day with the nice and fast Deutsche Bahn InterCity Express Train. Just a few hours in Hamburg before getting on the Night Train back to Stockholm again.

I don't recall me thinking anything about Python, while strolling the streets of Hamburg or when having a beer in a Munich biergarten.

During this time I have read two great books, unrelated to software or work: Perfection, by Vincenzo Latronico,
and Four stories by Han Kang (a collection of short stories, probably only released in Sweden).

The short stories are some of the most beautiful
and creative things I've ever read.

I'm in Stockholm again. Catching up and slowly getting my mind set for work mode. It is significant how different I feel now, compared to the first days of the vacation. I haven't checked, but I bet my heart rate is slower than before. I still have vacation and there's plenty of time to read another book unrelated to software or work.

A recurring thing, when returning from a vacay is that I worry about if I have forgotten things: What was I doing before? Are the emacs keyboard shortcuts still in my muscle memory, or gone forever?

Do I still know how to code?

That last question feels different this time. 2026 has been the Year of Agentic Engineering for me. This means basically no typing, but instead describing, steering and reviewing. From a human skills perspective, there's something lost here. I think typing is a combination of muscle memory and an enabler of creative thinking. Maybe that's what we developers call getting into the Flow? Eventually, it is a high chance of forgetting about the actual syntax when not using it as before.

Today I developed and released a new version of the Open Source tool that I maintain. It was a small change, mainly a Developer Experience improvement thing, but the implementation meant sorting and reducing nested data structures. A fun problem to solve! I was almost about to prompt my Agent to solve this, out of pure laziness. But I have thought about this before: doing Open Source development on my spare time could be an opportunity to practice, to keep and improve my own skills.

I ended up coding it myself, but used the agent to do the reviewing of the changes. I think this way might be a good balance between Agentic Engineering and not losing useful skills as a human. It's like a workout. So I will continue this workflow. Agentic Engineering at work - coding Open Source on my spare time.

^{Photos by me. Top photo: an early morning in Riva del Garda, Italy. After a workout and a short swim. No one but me and the birds at the beach.}

Practice what you Preach

I'm the maintainer of the Python tools for the Polylith Architecture, that adds useful tooling support for teams having their code organized according to the Polylith Architecture. So far in 2026, I have made seven Feature releases (i.e. minor versions) and a bunch of smaller ones (i.e. patches).

One of the features that was added this year is the possibility to inspect the coupling between individual parts of the code. In Polylith, code is logically grouped into something called bricks. For Python, these are what we know as namespace packages within the same repo.

Each package has an __init__.py, and you can define the interface of the package there. This is optional, and it is perfectly valid Python to access the modules within a package directly. In Polylith, a stricter approach is recommended: explicitly define the things that should be exposed outside of the package (aka brick).

      from my_package import my_function

      __all__ = ["my_function"]
    

The new feature is exactly about this: visualize and validate the usage of brick interfaces across the repository. With a simple command, you will find out if code is bypassing the explicit interface of a brick. This is still optional, and as long as it is valid Python you can safely ignore this. There's benefits of having code that interacts via explicit interfaces, such as refactoring - it's very easy to move code - and low-risk of breaking things when changing the code within the brick.

      # the existing command visualizing coupling between bricks
      poly deps

      # the addition, that will inspect the brick interfaces
      poly deps --interface

      # or inspect a single brick
      poly deps --interface --brick the_brick
    

Vizualize coupling, bypassed interfaces or circular dependencies.

What about circular dependencies between bricks?

Remember, a brick is a namespace package and that means that it is on a level above the individual Python modules. It can be valid Python 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. I would even go so far calling it a Bug. Two packages that import code from each other could be refactored into three, where the shared things are in a separate package. This is how the Polylith tool identifies circular dependencies between the bricks. The same command as for validating interfaces is used for this feature (poly deps) and it will inspect the code in the entire repo, to look for any circular brick dependencies. The interface lookups and the circular dependency checks are both internally using the builtin AST parsing.

Control your Agents

Many teams use agents today during development and knowing that agents can produce a lot of code in a fast pace, these two features are very useful if you want to avoid any unexpected side-effects of importing Python code without clear boundaries. Agents can use the poly tool too, just like when doing linting and testing. Static analysis is a great thing to have in the Agentic Engineering toolbox. The Polylith tool includes agent skills, so your agent will understand how to use it.

Practice what I Preach

I knew from before that the source code of Polylith tool bypassed interfaces in a couple of places, but I thought this is fine since it is valid Python. But I realized that my future self will thank me if these risky parts are fixed now and not later. Also, it is good if I actually practice what I preach being the maintainer of the Polylith tool for Python. So I fixed that. In addition, I also learned that two bricks in the repo had circular dependencies caused by a recently added feature. In this case, it was a circle of several bricks that initially made me worried. But the solution was simple: move the parts that caused the circularity into a different brick. I already had an existing brick that made sense to host the couple of Python functions that caused the circular dependency.

After refactoring: no interface violations, no circular dependencies.

Related posts and resources

• post: An Agent- and Human-friendly Architecture
• repo: the Python tools for the Polylith Architecture
• docs: the Python tools for the Polylith Architecture

^{Top Image generated by Mistral AI with modifications by me.}