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.

Architecture today

For a while now, microservices seem to dominate everything, and with them, FastAPI in Python. The adoption of the cloud as infrastructure in almost every company points in that direction. However, the most obvious downside of this approach is managing and orchestrating those microservices; you have to be very careful with the dependencies between them so you don’t “cross the wires”. You need highly skilled people to keep these operations running.

That said, microservices have become the standard. Tools have emerged to make them easier to use, like containers, Kubernetes or Prometheus, and they offer a ton of advantages that can leave a technology like Django behind. It’s slow, or at least on the surface, whereas FastAPI is fast, both when processing requests and when developing with it. It also includes typing almost “for free” (something Python really benefits from, like JavaScript needed it) and has an extremely robust dependency system.

On the other hand, Django has been around since 2005; it’s almost as old as Facebook. It stays relevant thanks to a well-organized community that is passionate about web development. As a result, a large share of the usual problems of programming for the web are already thought through and solved. It comes with “batteries included”, a term that means a big part of your solution is ready from the start (authentication, admin panel, ORM, security, templates and routing). The problem is that its philosophy doesn’t align as well with this microservices trend, since it comes from an era when the monolith shined: the application as a centralized whole, with a server-side orientation.

Still, Django has important downsides. It looks slow and, back in the day, there was no way to make asynchronous calls (something that would seem crazy today). In terms of scalability it can fall behind, even with its modular monolith structure and per-app deployment. Also, Django has a strict, opinionated way of working. It can be overkill for small projects. All of this leads us to its learning curve, which is steeper than that of its alternative.

With that said, I’d like to dig deeper and analyze the different dimensions from the business perspective, which are what will ultimately lead us to decide between one tool or the other.

Time To Market

We need to be clear about the business priority when launching the MVP: What is the product about? Does it need to manage users, roles or some kind of common administration? Or, on the contrary, is the execution speed of each call in a specific service more important? These questions guide us. If the solution requires managing users, passwords, moderating content or having some kind of administrative support, with FastAPI you’ll have to build all of this from scratch and timelines will increase significantly.

On the other hand, if you need to stay in sync with frontend or mobile teams, FastAPI will give you the smoothness. Its interactive documentation and how quickly you can prototype routes ready for the frontend team to consume speed things up incredibly.

It’s also ideal for validating ideas and exploring markets with a very specific tech service. We’re talking about something so concise that Django’s robust infrastructure would only get in the way.

Budget and Team

With no team and no budget, Django shines. With very little, we can do a lot. And if you add AI agents on top of that… in the same codebase and practically natively. A single developer can handle a big solution, moving from the database all the way to the visualization and the interface.

However, we have to remember: jack of all trades, master of none.

The story changes if you have a structured development department, with at least one team dedicated purely to the frontend, several developers and the resources to invest the time it takes to “reinvent the wheel” again. Although, let’s be honest, it will be a much more specific and faster wheel. At the end of the day, if we’re competing in Formula 1, I wouldn’t recommend driving a pickup truck.

Product vision

Are we building a heavy, centralized platform, or a product that will be part of an ecosystem of services? If the business value lies in convoluted rules and in managing structured data, Django is most likely the right direction. On the other hand, if the value lies in processing speed, concurrency and independence, maybe it isn’t. You have to stop and think: how do I see this solution in 2 or 3 years? Things to keep in mind:

• Relational complexity
• Centralization
• Technical specialization
• Interface independence

Scalability

At first glance, this fight comes down to synchronous vs. asynchronous. FastAPI is async by default, and microservices grow much better than monoliths. However, in reality, giants like Instagram, Pinterest and Patreon started (and to a large extent still operate) with Django. Saying that Django can’t handle large numbers of users is simply not true.

The real question is: does that massive traffic happen at exactly the same moment? If the challenge goes beyond just “holding up” under more users and centers on real-time interaction between them (like a live chat or a multiplayer game), FastAPI is the right call so the architecture doesn’t wobble.

Agility

In these terms, a few years ago Django was an undisputed star; it saved us a lot of time by letting us do more with less code. Today, with AI agents spitting out code like machines, this “batteries included” feature loses a bit of weight. Now we can achieve the same thing using smaller tools.

However, Django has evolved and found a new niche of value: standardization and keeping chaos under control.

A less experienced engineer is much more likely to end up with a chaotic, incomprehensible codebase using a tool like FastAPI than using Django, since the latter tells you step by step how to structure things. Many frameworks do this (like Ruby on Rails or NestJS): they put up “guardrails” so you don’t go off the road. Writing code with AI means that today, more than ever, we have to care about maintainability and technical debt.

KISS

At the end of the day, to choose correctly we can narrow it down to knowing where we are, who we are and where we’re headed.