Every Robot should have a REPL

Remember before AI, LLMs and Agentic Engineering? Since going all-in agentic, I have felt that something useful was lost. I had a pretty effective and joyful workflow back then, practicing REPL Driven Development with almost instant feedback loops. I have written about this workflow before.

Today: when steering and monitoring the work my agents do, I've often wondered why it think it needs to construct these complex shell commands, and huge chunks of temporary Python scripts - sometimes entire programs - to try things out. Have you also noticed this? Sometimes, the agent copies entire folders of code into a /tmp folder just to verify something. It is very difficult to understand what I am actually approving.

That's why I have developed a way for the agent to send small pieces of Python code to a Live running REPL, so it can verify things step-by-step without losing context.

The Open Source Agent REPL MCP gives your agents a persistent Python REPL. Each agent session gets its own Jupyter kernel per project that stays alive across calls. Edits to real source files are picked up automatically on the next run, using the built-in features of the kernel. Having a persistent REPL will make the REPL Driven Development workflow possible for your agent. The agent can try out and run small portions of code when it need to verify or figure out things, instead of running complex bash calls.

The Agent and the REPL MCP in action. I'm just approving.

Your agents will know when to use the REPL with the help from skills:

• Use it when the behavior of a function, library call, or data shape is unclear, and running code with representative inputs answers it faster than reading.
• When you are about to edit project code and want to try a change and verify it in a live process first.
• Skip it when reading the code already answers the question and for trivial changes.

You will find the Agent REPL MCP here.
With setup instructions for You, and skills for your Agents.

^{Top photo by Emilipothèse on Unsplash}

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.}

Reflections: 6 months of Agentic Engineering

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.

Not perfect, not 10x, but well and the shift was surprisingly easy. I quickly found that good coding practices are still applicable and relevant. I’m not into that vibe coding stuff, I care too much about the output. What has been occasionally overwhelming is the uncertainty about The Next Step - just like many developers out there I have thought about how we, the Humans, will keep up with the speed of the Agents?

Here's some reflections after about six months of developing software according to Agentic Engineering.

Human reviews have not become the bottleneck. From my experience, human reviews was a bigger bottleneck before Agentic Engineering. We have made efforts in our Team to improve the review flow, to avoid the need of constantly reminding people to review and approve changes. We have made the review process itself more efficient than before.

For me, the ratio of Development time vs Planning and Reviewing is about the same as before. I find myself designing and developing solutions the same amount of time as before the agentic era. In the beginning, I thought it would be the opposite!

I haven't run into the problem of having my agents produce hundreds of pull requests on a daily basis. I know there are people out there doing amazing stuff over the weekends with agents, but I'm not one of them. I haven't yet found a need to rebuild an existing SaaS tool from scratch with AI.

Quality is important. I think it is even more important than before, because an agent will be confused by complex code. Not only that, it will likely produce code that is equally complex (there's research about this available). This will be a downward spiral. Here's where Agentic Engineering is different from Vibe coding. A vibe coder treats the code, the output, as a black box. The risk with that is software that is very difficult to maintain. An agentic engineer keeps their eyes on the incremental result, and steer the agent during the process. The Human decides what Quality is, what is Readable code and what is Simple code (just like before).

Static analysis tools are a great to have in the agentic toolkit. Linters and Unit Tests are as important as before. I have added tooling that reports on complexity and readability issues, and use the Code Health MCP for that. Without the need of human interaction, the agent will verify its result while working and adjust it until the score is healthy before it reaches my eyes. Having static analysis tools doing this kind of work instead of an AI will reduce token spend. Reducing spend will be important in the future as the cost of tokens likely will increase.

Always bet on Open Source. Back in the days, as a .NET developer (when it was closed source and Windows only), developers were heavily dependent on Microsoft. Not only for the framework, but also for most of the tooling. I don't want to go back to that era, and see the same kind of vendor lock-in pattern with the AI providers of today. My tooling of choice is Emacs and the provider-agnostic tool Eca. When Anthropic has its downtime issues, I just switch to Gemini and can seamlessly continue while my colleagues at work are frustrated and post Claude is Down memes.

After six months, I still have a skeptic view on agents and LLMs in general. I simply don't trust the output. But at the same time, Agentic Engineering has made my workflow more efficient and I can more confidently step in to developing things outside of my comfort zone.

Related posts

• Agile and Agentic Engineering
• The tools of an Agentic Engineer
• A workflow for Agentic Engineering
• An Agent- and Human-friendly Architecture

^{Top Photo by me from Hoburgen, Gotland in Sweden.}

An Agent- and Human-Friendly Architecture

"Software Architecture in the agentic era?"

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 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 more easily 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 bricks 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 do. 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.

Link to the Python tools for the Polylith Architecture repo.

^{Top Photo by Mitchell Hartley on Unsplash}