The task and the goal was to be more productive, to be able to reach targets in impossible timeframes. To use modern technologies at a competitive pace without losing quality along the way, and without ceasing to build solid, scalable solutions. Do more with less. High cohesion and low coupling.

On top of that, for my part, there was the challenge of keeping the attitude of the craftsman, the blacksmith, even when industrial machinery is at hand. A task that turns into a paradox: how to see beyond what merely “works” thanks to sheer mass production and keep the passion for the craft. How to transfer this intrinsic concern for the work to a stochastic model.

First month

To resolve this paradox, in the first few weeks I had to learn in detail what I was dealing with. And maybe this is the best moment to get into the subject and tell you about Claude Code. A programming agent used through the terminal, which has access to different actions inside your computer.

At its core, “Claudito” works with the concept of context. Imagine a room with defined walls and square meters, where light comes in, along with the furniture, table and chairs, people and pets: like a finite space of information that gives meaning and limits to our reality. And this is important: you have to keep in mind the limitations and how many things fit in the room. The context must contain everything needed for the solutions Claude delivers to be valid and accurate. MCPs, for example (the tools or extended functions, for instance to simulate a browser or access Google Drive), take up a significant amount of space in your context, and can leave you without enough room to give the agent the key background of the problem, inevitably making it lose track of the solution.

I started using it with these concepts in mind, the way its own creators suggest. A sequence of explore - plan - code - commit, but as the weeks went by I felt I was repeating my own flows. So I looked for the other ways people were using this tool. And I discovered the concept of the harness and how to customize it.

Second month

The harness comes by default, and although it isn’t the most optimal for every problem or technology, it works. The agentic harness is defined as the set of tools, context management and execution environment that turns a language model into an agent.

In other words, it could be translated as the harness that holds a climber on the mountain. In climbing (unless it’s free solo), you need gear. Otherwise, you have nothing to hold on to; you have no protection. The harness is the safety equipment that connects you to the mountain. It gives you the ability to act, to be there and to move forward. And what better than having your own tools and adjusting them day by day.

Without this, the solution takes a bit longer, or you find yourself telling it the same things over and over. So, from the second month on, I added dedicated skills and commands for the patterns and technologies I use, taking inspiration from a repository (ECC, winner of Anthropic’s hackathon). All of this always implemented from a TDD (Test-Driven Development) perspective from day one. Tests here are vital, both to validate your code and to serve as a path for the models to understand it as the solution keeps growing. They are path and validation. Having the right patterns in every new plan secures my solution, but it isn’t free: there is a context and token cost attached to every plan. Although, in my opinion, it’s completely worth it.

And to make this harness work without running out of space, I leaned on persistent context, or memory. Since the session space is limited, per project you can have a CLAUDE.md file and various other .md files. These work as a usage guide; base instructions that Claude reads when starting inside a folder so it knows, beforehand, what the rules of your project are. The interplay between context and these files when working with Claudito also makes the difference.

In my opinion

With these techniques, Claude has become a snowball of productivity. It’s what it promises: things that once took me weeks now take me a couple of minutes. Analyses that might take me months, Claude solves in one well-run session with the right questions. It’s hard to look competitive in this industry without Claude as a copilot. Now, Claude doesn’t get distracted and doesn’t doubt. And it’s at your command like an army of one. Army of one.

I know I can still apply techniques to reduce token spend, and even use that crazy learning skill where Claude recognizes my workflows. I dream of the day when you just talk to the computer and interact with a machine of peculiar personality; as of today, this is the closest thing to what I once imagined. And I also know how different Claude is working on existing code and its tendency to create rather than maintain. That its way of maintaining is adding and adding code. That it has strong preferences and that if you get careless you end up creating a swarm. Its swarm, one you don’t understand. So my advice is to be careful and always keep understanding the moves toward the summit.

On the other hand, and with all that said, it’s hard to keep seeing myself as the craftsman forging the rings of power, devoted to one single, specific and spectacular task. The day-to-day shifted more toward that of a strategist, drawing routes and plans, swapping weapon types and pulling the king’s tokens as if it were war. Using the terminal and writing natural language to get what I want instead of flowing through logic gates.

Docker is a platform for developing, packaging and running containers. Important word: containers, which are isolated environments that include everything your software needs to work. These containers are created from images, immutable and reusable templates defined through a Dockerfile. Thanks to this, the same image can be used in development, testing and production, becoming a consistent unit of work in a distributed world.

There are also other concepts that tend to be overlooked: volumes, which let you persist data, and networks, which connect containers to each other. All of this within an ecosystem like Docker Hub, which offers thousands of ready-to-use images.

I think knowing that, you could already start working and integrating containers into your workflow. But we don’t stop here, let’s go a little further.

Before the whales

Before Docker there were virtual machines (VMs), which are, in essence, a complete emulation of a physical computer inside another one. Each VM acts as an independent machine, with its own virtual CPU, RAM and storage, which lets you run operating systems and applications in an isolated and secure way.

We could ask ourselves: why not keep using virtual machines? But there’s an architectural drawback: the weight and volume of the box exceed those of its contents; that is, the system is wasting resources.

Each instance has to load and run a full operating system (Ubuntu, Debian, Windows or another), which takes a lot of resources. VM disk images usually take up gigabytes, and the boot process can take several minutes, even for simple applications. This creates overhead that affects both performance and system efficiency.

Using the kernel

Containers, unlike VMs, don’t emulate a complete computer or require a separate operating system. Instead, they share the host operating system’s kernel and isolate only the processes and resources needed to run an application. It’s operating-system-level virtualization. This removes much of the overhead, allowing more efficient use of resources and near-instant deployment.

A good way to picture it is to imagine a VM as a detached house: it has its own foundations, pillars, electrical system and plumbing. Containers, on the other hand, are like apartments in a modern building. Each apartment shares the main structure, the electrical system and the plumbing. And yet each apartment has everything it needs to live comfortably and independently.

Thanks to this we get Docker’s key values, particularly efficiency and resource optimization versus virtual machines:

• Portability: it works everywhere.
• Efficiency and resource optimization: lots of containers.
• Isolation and standardization: unit of work.

Namespaces and cgroups

Containers work on top of the kernel in an isolated way through two mechanisms: namespaces and cgroups.

A namespace abstracts global system resources so that processes believe they have their own isolated instance. Changes made to a resource are visible only to the processes that belong to the same namespace, remaining invisible to the rest.

Currently, the Linux kernel has 8 types:

If namespaces decide what you can see, cgroups decide how much you can use.

Cgroups let you allocate system resources (CPU, memory, network bandwidth or a combination) among user-defined groups of tasks (processes). And they go further, letting you monitor the consumption of the configured groups, restrict access to certain resources or set limits. They even let us adjust limits and priorities dynamically. With these mechanisms we achieve isolation.

Docker operates on immutable layers

An immutable layer is a set of read-only files that records a specific state change in the image. Since they can’t be altered, Docker reuses them across multiple containers without duplicating disk space, guaranteeing that the environment is always identical and predictable (determinism). Any later modification doesn’t edit the base layer, but generates a new one on top of it, protecting the integrity of the original source.

Working across layers is possible thanks to the concept of UnionFS. This engine takes folders in different layers and “merges” them virtually so they look like a traditional filesystem. This way we get immutable layers working in harmony, making it possible to spin up disposable infrastructure that is completely replicable.

Communication and networking

The network namespace is what isolates the network. Each container operates as if it had its own network card and its own IP. Based on this, to connect containers we need a “switch”, a bridge that allows interaction, as if it were a physical network, creating virtual cabling through a subnet.

But there’s a problem: IPs are ephemeral and, so we don’t have to configure IPs all the time, the internal DNS server steps in, intercepting the request and returning the current IP, or rather the service name. These 3 mechanisms let us keep communication fast, secure and reliable.

Docker and its friends

However, Docker is just the unit of work. In modern professional applications (like those using Django or FastAPI), we rarely work with a single container; we usually need a database, a backend, a worker and a frontend working together. This is where Docker Compose comes in as the orchestra conductor. With a single configuration file, you can define a complete infrastructure for a digital product.

Other technologies like Kubernetes or Docker Swarm let us orchestrate at a larger scale.

With that, I think that’s enough whales for one day, maybe for a week, maybe for a good while. I hope it taught you something, and remember that all of these technologies draw heavily from others like operating systems, virtualization and networking… and remember: if you’re out there working with Docker, don’t forget to create your .dockerignore.

Note:

Docker Compose is great for development and testing, but in production you shouldn’t put the database in a container. A database needs real persistence, high availability and good performance tuning. For production, it’s safer to use managed services (AWS RDS, Cloud SQL) or dedicated VMs with backups, replicas and serious monitoring.

Resources

• How containers works
• Understanding image layers (Docker Docs)
• Layers of Docker image 101

For the last few weeks I’ve been mulling over how operations and concurrency work. What guarantees that a critical operation won’t break the system?

Transaction Fundamentals

Nothing. There is no configuration that’s right for every case. What does exist is understanding how transaction states behave when they work together. A transaction is a consistency contract. When we don’t understand what happens at the levels below, we leave the system’s integrity to chance.

This becomes obvious when we have to work on financial services, cryptocurrencies, inventory management, reservations or distributed systems.

ACID Transactions

When databases started being used in critical systems, failures left data in inconsistent states, causing costly errors. In the 80s, Jim Gray and other researchers defined the ACID properties: Atomicity, Consistency, Isolation and Durability. Four rules that guarantee that, even in the face of failures, data stays correct.

Atomicity

It’s the “all or nothing” idea. A transaction can have 10 steps, but if step 9 fails, the other 8 are undone as if they had never existed. This is achieved through logs (Write-Ahead Logging). The database writes down what it’s going to do before touching the actual data. If there’s an error, it uses that log to apply a Rollback and return to the initial state.

Consistency

It guarantees that a transaction only takes the database from one valid state to another. The core of this property is enforcing business rules. The tools involved are Triggers, Foreign Keys, Check Constraints and data types. For example. If you try to set a negative volume and there’s a rule forbidding it, the transaction bounces.

Isolation

This is where things get interesting. When several transactions try to access and modify the same resource at the same time, they can’t simply run in parallel without coordination. If they did, we’d end up with inconsistent states. That’s why a transaction has to wait its turn while another one finishes its operation on that same data.

Concurrency happens when the execution of two or more pieces of code behaves as if they were running at the same time.

To deal with concurrency, coordination is achieved with mutual exclusion primitives. At a low level we’re talking about mutexes: mechanisms that guarantee that only one thread or process accesses a critical resource at a time (if you want to know more). In databases, the concept translates into locks, which apply that exclusion on rows, pages or tables. It’s not optional cooperation; the engine enforces these rules to protect integrity.

Now then, when and how are these locks applied? That’s where isolation levels come in: settings that define how strict the database will be when applying locks between concurrent transactions. Each level makes different trade-offs between consistency and performance:

Durability

It’s the promise that, once the system tells you “OK, saved”, that information won’t be lost even if the power goes out or the server blows up right afterwards.

Changes are written to non-volatile storage (hard drive/SSD) and confirmed in the transaction log. Even after a catastrophic failure, on restart the database reads the log and finishes applying whatever was left pending.

Beyond ACID

Nowadays, these concepts are the foundation of relational databases. However, understanding this is just the first step. When you make the jump to modern architectures with microservices and NoSQL databases, the engine can no longer guarantee ACID across the whole system, because your data now lives on separate servers and the rules of the game change.

When distributing information, ACID’s rigidity is often traded for a more flexible approach that prioritizes the system never going down. We call this new paradigm BASE:

Going from ACID to BASE means accepting that your system will live with some temporary inconsistency in exchange for being incredibly fast and resilient to massive outages. At this point data integrity stops coming from the engine’s configuration and becomes design patterns you have to implement in code (like the Saga pattern or Two-Phase Commit) to tie up the loose ends.

But that… is a story for another post.