Forem: Guillermo Fuchter

How to Survive AI as a Developer

Guillermo Fuchter — Sun, 08 Mar 2026 22:31:50 +0000

In his latest sketch comedy, "Shipping a button in 2026", the YouTuber Kai Lentit depicts a software engineer debating with ghostly caricatures of different software developer archetypes, on how he should go about implementing a new feature for his software. Each one convincing him to pick a certain programming language, framework, and or technology to implement his basic software feature. In the end, after a lot of back-and-forth, and frustrated by the amount of choice and how the scope has expanded, he finally decides to open his AI code editor and let an AI model take care of it instead.

The punchline resonates with many developers, because it mirrors our new reality where we can have AI write code in programming language and frameworks we are not familiar with. AI has created a new layer in the software development process, where natural language can be compiled into working software code, and with the latest models and tools, it can debug, refactor and iterate. This has lead many people to prophesy that human programmers will be replaced by AI.

What these supposed prophets miss is the most important step of software engineering; modeling the domain using meaningful and consistent natural language. modeling and language developing is the key step that will determine if the code that AI produces will result in a codebase that becomes a nightmare to work with, even for very capable AI models, or if it becomes a legible codebase, where code changes integrate smoothly, without churning millions of AI tokens.

Modeling the domain is a process in which developers and domain experts collaborate to create a mental model of a domain that is to be translated into code. In his book "Domain Driven Design", Eric Evans Eric Evans also calls this process 'knowledge crunching', and describes how language is cultivated based on the model of a domain. As an example of the importance of modeling a domain, think of trying to build an e-commerce website. We, as programmers, will find ourselves having to define core concepts such as 'order', 'shopping cart', 'receipt', 'shipment', and 'purchase'. A person who does not have context about this domain might use the terms 'order' and 'shipment' interchangeably, given that a shipment is always linked to an order. But a good software model must define and differentiate these terms, otherwise developing the software for the domain becomes hard, and the resulting codebase ends up being a confusing mess riddle with bugs.

Coming back to AI, you can imagine how even the most advanced and sophisticated models would have difficulty fulfilling a request to develop a new feature, or update an existing one when the language used to prompt it is based on a poor domain model, or a non-existing one. Picture asking AI to 'fix your ordering system' on a codebase where the term 'order' is being used interchangeably with 'shipment'. You should not be surprised if the AI model ends up making assumptions and changing the behavior you did not expect, or even worse, breaking how the 'shipment' logic works. Maybe you get the expected result after tweaking your prompts and giving the AI enough context on your poorly defined domain model. But once you submit your code changes and close the session with the AI agent, all the gained context is flushed away down the toilet, and the only thing remaining is a confusing mess in the form of "working "code. You might be able to repeat this process many times, but with time you will notice that the process will start taking longer. The AI model will require you to provide more context every time, and you will find yourself nudging it more often to get it to produce your desired behavior while it burns through your budget in tokens.

In conclusion, this advancement of AI for software development has made writing code easier and accessible, to the point where deep knowledge of programming languages, frameworks, and libraries are no longer requisites. On the other hand, it has highlighted the importance for developers to collaboratively model the domain before attempting to write any code. With a good domain model, prompts become easier and more meaningful. Codebases better reflect the domain models and become simpler for developers and AI models to change it. For the developers looking to survive in the age of AI, my advice is to start focusing on how you model your domain, and how you can more effectively do it in collaboration with domain experts. Here are some resources that can help you with that:

My First Experiences With Test-Driven Development

Guillermo Fuchter — Mon, 15 Dec 2025 16:43:12 +0000

Love it or hate it, Test-Driven Development (TDD) is a very popular software development method used within the industry. Here I share my experiences with TDD and some neat ideas I learned along the way.

Introduction

I was aware of TDD, mostly from people talking about it negatively, claiming that TDD does not leave space for design. Popular software developer streamer, The Primeagen, talked on his podcast about trying out TDD for his game and finding it difficult to integrate his Test-Driven developed module to the game he was developing. On the other hand, well-known software developers like Kent Beck have written extensively about TDD's positive effects on the software development process.

With this in mind, I decided to give TDD a go for my day-to-day coding tasks. At first I found it frustrating, feeling the friction of writing tests before the code itself. But when I got through the initial phase, and I started to see my test pass, it gave me a great feeling of accomplishment and satisfaction. I noticed that because of the initial friction, I did end up spending more time on the task that I would normally have, but that extra time spent was reflected in the higher quality tests. Not only did the tests cover more edge-cases, but they were easier to read. When I used to write tests after writing the code, I found myself rushing them to get my code deployed sooner. This led to lower-quality tests, that did not test many edge cases, and were difficult for other developers to read and understand. Funnily enough, in some rare cases, the test cases were so badly written that they would succeed when ran, even when the module they were testing failed! I managed to catch those scenarios accidentally when I was updating the module weeks later. This could have been avoided if I had used TDD sooner.

Applying TDD has been beneficial for me, and it has led me to discover ideas, practices, tricks, and tips for writing more maintainable code that complement TDD. In this post I would like to share those with you.

Tests as Documentation

The well-known manifesto for agile web development is composed of 4 values, one of them being valuing "working software before comprehensive documentation". The main idea is that we are in the business to create software, not comprehensive documentation, therefore working software should take main stage. The main reason is that documentation can only work if it gets constantly updated, so it reflects the source of truth, and maintaining documentation is work intensive. Maintaining an up-to-date documentation would require developers to update the documentation every time that they change their code. On the other hand, documenting what your software does is beneficial because the more your software grows, and the more people get involved in the maintenance and construction of such software, the need to have some kind of software documentation gets stronger.

Some developers may claim that "well-written code is self-documenting", but this kind of idealism is unrealistic. Tech debt builds up quite quickly and naming software modules is very easy to get wrong. Fortunately, I found that well-written test make for great documentation. Tests are supposed to convey how a code module behaves, and that makes for great documentation, provided that tests are written with a good structure and using descriptive test cases' names. Additionally, writing tests as if they were documentation results in more maintainable and readable test code. To achieve this I found useful following these tips:

1. Make use of nested test cases (if you framework allows it)

Many testing frameworks allow for nesting your test cases. This makes it easier to write a permutation of test scenarios without repeating yourself. It also allows you to organize all your test case's setup code, so it is kept lean and descriptive. Here is an example written with the jest framework for a user deletion use case:

describe('Given a user with the admin role', () => {
  beforeEach(() => {
    UserFactory.create({id: 123, role: 'admin'})
  })
  it('should not be able to get deleted', () => {
    const useCase = new UserDeletionUseCase()
    await expect(() => { useCase.execute({id: 123}) }).toReject()
  })
})

2. Keep your test cases focused on behavior rather than implementation

Test cases that describe how a module should work from the point of view of a consumer, are the easiest to read and understand. When you create and describe your test cases with a focus on implementation, then it is easily understandable only for the person who wrote the module. With this in mind, I like to try to write my test cases as if my product owner were the one reading the tests themselves.

Keeping tests focused on the functionality has additional advantages that I will describe below

Gray Box Testing

Black box testing is the method of testing where you evaluate the functionality of a module without knowledge of its internal structure or implementation. White box testing is the opposite, where the internal structure is known and used to derive test cases. While black boxing can only be done with high-level tests such as end-to-end tests, or certain integration tests, I believe that unit tests should be approached with a gray box testing method. This means that we mock as little as we need to, and we try to avoid assertion on a module's internal workings. By doing this, we are focusing on the function of the module rather than its implementation.

Tests that are focused too much on the implementation are brittle and harder to read for the person not writing the module. One of the biggest advantages of writing tests is that it is supposed to make refactoring easier by reassuring the developer that the refactoring does not change the behavior in an unexpected way. By having brittle tests, that advantage is lost. This is because the developer refactoring code is forced to change 20 different test cases, and it becomes difficult to distinguish if the failing test is due to an unexpected result of the test, or due to a test that is too coupled with a specific implementation. Focusing on the behavior make tests more robust to small changes, and makes the test failure more meaningful.

London Style: Outside-In Testing

Described in many places as the "London Style" of TDD, I like to start my tests from the "outside-in". This means I start writing tests for the higher level modules, mocking interfaces for modules that don't exist yet, and work myself down to the lower modules. For this to work, I need to define my interfaces beforehand, which adds to the friction, but this prevents me from building the wrong interfaces by forcing a consumer-first view. If I start the other way around, I risk running into the same issue that the Primeagen complained about. Writing interfaces that are good for testing but don't integrate well with other modules.

My website: https://www.fuchter.dev

Lessons From "Dependency Injection Principles, Practices, and Patterns"

Guillermo Fuchter — Sun, 07 Dec 2025 22:22:08 +0000

Book review of "Dependency Injection Principles, Practices, and Patterns" and lessons I learned from reading it.

Introduction

My first job as a software developer was writing C# for a software development agency that worked very closely with Microsoft. As a junior engineer, I had a basic notion of object-oriented programming and SOLID principles, but I was puzzled every time I opened a project that used .NET dependency injector container. Why are we writing an interface for everything? Why aren't we instantiating instances inside of classes? Why are we passing all instances through the constructor? It all seemed very bureaucratic. I didn't understand why we were following these strict rules that added so much code, when we could keep the code lean and simple by getting rid of those boiler-plate interfaces, and instantiating the instances of a class inside where they were going to be used.

Fast-forward a couple of years, while working for another company, I decided to pick up "Dependency Injection Principles, Practices, and Patterns". I remember the book showing up in the background of a Youtuber's video. At the time, I thought that reading it could help me introduce some more structure and order to our projects. Part of me was curious to know if the book could answer the questions that plague me all the way back to my C# days. After reading the book, I can say it did answer all of my questions and more. It has helped me have a much better understanding of object-oriented programming and software design as a whole.

The book authors, Steven van Deursen and Mark Seeman, do a great job of explaining central concepts to dependency injection such as "decoupling", "cohesion", and how they relate to the SOLID principles. They provide examples of dependency injection pattern,s common "anti-patterns", and "code smells", all of which help illustrate their main advantages of dependency injection to the reader. The book is very well written, and I highly recommend it to anyone working with object oriented programming.

Having introduced the book, I would like to share with you 3 ideas from this book that have had the biggest impact on how I approach software development. Beware, I am not aiming to boil down the book, or dependency injection to 3 ideas. If you look to understand dependency injection, and all of its benefits, I would encourage you to read the book.

Low Coupling

The book introduces the concept of coupling with an analogy to a hotel's hair dryer. Many hotels' hair dryer's are wired directly into the socket. Like code that is highly coupled together, it is a pain to fix or change. When the hair dryer breaks, an electrician has to come, switch off the electricity in the room, and de-solder the cabling before they can start replacing the hair dryer. With highly coupled code, the process can be very similar; having to change other modules before you can replace the module that needs fixing or refactoring.

In contrast to the direct-wired hair dryer, a hair dryer with a plug is easier to replace; all you have to do is unplug it from the wall socket. Loosely coupled software behaves the same; it is easier to replace, remove, and maintain.

Maintainability is a very important aspect of software development. A software solution that is not maintainable means that it has a very high cost to change, and for business that means software features being released less often. Loosely coupled code improves a project's maintainability which enables the development of new features at a faster pace.

High Cohesion

The authors touch upon the SOLID principles, and the principle that gets mentioned the most is the "Single Responsibility Principle", which they define it in the following way:

The Single Responsibility Principle (SRP) states that each class should have only one reason to change.

In relation to the Single Responsibility Principle (SRP), the authors define cohesion and how cohesion allow us to determine if a module violates SRP.

Cohesion is defined as the functional relatedness of the elements of a class or module. The lower the amount of relatedness, the lower the cohesion; and the lower the cohesion, the greater the possibility a class violates the SRP.

When aiming to write loosely coupled code, the Single Responsibility Principle becomes an invaluable guideline that helps us achieve that. The loose coupling has to take place with modules that have a high level of cohesion. Otherwise you have a difficult to understand software solution, and that impacts the maintainability negatively.

Volatile and Stable Dependencies

Although loosely coupled code contributes to a more maintainable code base, it also has a cost. That cost is having more "seams" in your code.

Everywhere you decide to program against an Abstraction instead of a concrete type, you introduce a Seam into the application. A Seam is a place where an application is assembled from its constituent parts, similar to the way a piece of clothing is sewn together at its seams.

Because of this cost, it is important to introduce seams only where they are necessary, like for volatile dependencies. A volatile dependency, as opposed to a stable one, is a dependency that meets one of the following criteria:

The dependency runs in a different environment, like in a different machine or different process within a machine. An example would be a database.
The dependency does not exist or is under development.
The dependency contains nondeterministic behavior.
New versions may contain breaking changes.

Conclusion

There are so many other concepts I've learned from reading this book that I haven't added here. It is an easy read thanks to its structure, explanations, and analogies. I would recommend everyone to buy it, read it at least once, and find a space in your bookshelf to have it at hand for whenever a question pops up.

DDD CRUD-Like Repository

Guillermo Fuchter — Mon, 24 Nov 2025 16:38:06 +0000

The repository pattern is an essential part of object-oriented software development. It has become the most popular abstraction to retrieve data from the database and map them into business objects (Aggregates).

Lately I have noticed that many developers choose to restrict their repository to follow a CRUD (Create, Read, Update, and Delete) pattern, where the methods' names are generic and contain a verb associated with CRUD such as get or delete. The methods are highly versatile by accepting a object parameter with many properties so the consumer ca re-use the method in many different scenarios.

Example of a User repository interface (typescript):

export interface IUserRepository {
  getUser({ id?: number, email?: string, role?: string }): Promise<User>
}

This pattern seem to be loosely inspired by Eric Evan's description of a specification-based repository.

A SPECIFICATION is a way of allowing a client to describe (specify) what it wants without concern for how it
will be obtained in the process creating an object that can actually carry out the selection

The issue comes when constraining repositories to only follow a specification / CRUD interface. Methods suddenly have to cover many cases and they become bloated. Additionally, the method names do not convey the same intent as compared to "hard-coded" methods

await playerRepository.getPlayer({ location: 'USA', highScore: 500 })

await playerRepository.getPlayerFromUSAWithHighScore(500)

In the example above, we can see the two different approaches. The "Specification-Based" does not convey the intent very well. It is not obvious if it is retrieving a Player from the USA and with a high score of 500, or if it is retrieving a Player from the USA or with a high score of 500.

Additionally, Eric Evans pointed out that we should allow for repositories to contain hardcoded methods, so as to maintain clarity in the domain design.

Even a REPOSITORY design with flexible queries should allow for the addition of specialized hard-coded
queries. These might be convenience methods that encapsulate an often-used query, or a non-object query
such as mathematical summaries of selected objects. Frameworks that don’t allow for such contingencies
tend to distort the domain design or get bypassed by developers.

Having said that, it is important for hardcoded methods not to encapsulate the definition of domain terms. For example:

interface IArticleRepository {
  getMostPopularArticles(limit: number)
}

In this example, we are defining what a "Popular" article is within the implementation of a repository, which should belong as an infrastructure concern. We are violating the segregation of concern.

Finally, I would like to point out that the specification-based example given here does not follow Eric Evan's example of what a specification-based query should look like. It just happens to be the most common repository structure I come across.

If you're curious, this is an example of a specification-based repository query given by Eric Evans in his book:

const criteria = new Criteria();
criteria.equal(TradeOrder.SECURITY, "WCOM");
criteria.equal(TradeOrder.ACCOUNT, "123");

const order = tradeOrderRepository.matching(criteria);

Domain-Driven Design by Eric Evans
My website

How to Add MinIO as a Service in a GitLab CI Job

Guillermo Fuchter — Mon, 09 Sep 2024 17:09:45 +0000

You recently added MinIO to your back-end web API to store the invoices for your ground-breaking app. You write the the smoke test for it locally, executing it with no error, but when the time comes for the GitLab CI Job to execute the smoke test, it fails. You have forgotten to add the MinIO to your GitLab CI job, so the app can't connect to any bucket. Don't worry, I'll show you how to add MinIO server as a service to your GitLab CI smoke test job, so it can pass with flying colors.

MinIO Image

For our service, we will be using bitnami/minio docker image, since it implements the MINIO_DEFAULT_BUCKETS environment variable. This variable will allow us to create default buckets without having to execute any scripts, or download any clients to create those buckets. If your smoke tests / CI Job does not rely on buckets, then you can use another image.

Setting up Service

Beside the MINIO_DEFAULT_BUCKETS, you will have to set the following environment variables within the service:

MINIO_ROOT_USER
- Previously known as MINIO_ACCESS_KEY_ID, but it was changed with the newest versions of MinIO. Do not use MINIO_ACCESS_KEY_ID as a variable since it is deprecated.
MINIO_ROOT_PASSWORD
- Previously known as MINIO_SECRET_ACCESS_KEY and it also has been deprecated
MINIO_DOMAIN
- Domain where you MinIO is being hosted. In this case, it should be localhost, since we are accessing it within the job. Additionally, don't forget to add an alias to your service, so it can be accessible with the endpoint.

Final Result

Your .gitlab-ci.yml file should look something like this:

smoke:
  image: $YOUR_IMAGE
  variables:
    S3_ACCESS_KEY: admin
    S3_SECRET_KEY: test-password
    S3_ENDPOINT: "http://minio:9000"
  services:
    - name: bitnami/minio:latest
      alias: minio
      variables:
        MINIO_ROOT_USER: $S3_ACCESS_KEY
        MINIO_ROOT_PASSWORD: $S3_SECRET_KEY
        MINIO_DOMAIN: localhost
        MINIO_DEFAULT_BUCKETS: my-bucket
  stage: test
  timeout: 5m
  interruptible: true
  allow_failure: true
  script:
    - npm run test:smoke

My Linkedin Profile
My Github

Should Domain Models Have Interfaces?

Guillermo Fuchter — Mon, 02 Sep 2024 23:23:18 +0000

When developing a project following Domain-Driven Design and clean architecture, one might ask themselves the following question: Should my domain models implement interfaces? After all, a good programmer should program against abstraction, not concretions. But then why don't most public examples of domain-driven design projects on the internet create interfaces for their entities? This is one of the questions I came across while implementing a DDD project, and it made me think of reasons for and against implementing interfaces for models that I'd like to share with you.

Why You Might Want to Create an Interface for Your Models

Domain models encapsulate a rich understanding of the processes and rules of a domain 1 and depending on the programming language you use, you might find yourself encapsulating the properties behind getters and setters. If that is the case, you will have an object that only exposes methods, which means that it could be abstracted by an interface, given that no properties are publicly exposed.

SOLID

Since we aspire to be great programmers, we want to apply SOLID principles pervasively through our project so as to build upon a good foundation. The 'I' in SOLID stands for Interface segregation principle and it states:

No code should be forced to depend on methods it does not use.

The idea is for "consumers" of the entity to rely on interfaces offering the methods they need, so as to decouple the consumers from the entity itself. Decoupled code is much easier to replace, refactor, and work with than coupled code.

Unit Tests

Having interfaces helps with unit testing. When creating an unit test for a module that depends on a model's interface, there is no need to instantiate complex domain models just to test a path of the service. Creating a mock model that complies with the model's interface can be easier than instantiating a real one.

The Case Against Interfaces For Domain Models

The theory might suggest that domain models should be kept behind interfaces, but there are good reasons why not to do that.

Adding Unnecessary Complexity and Abstraction

The idea of having decoupled layers is to be able to replace them eventually. Perhaps one day you will be using a relational database, and the next day you will need to use a non-relational one. But unless you're designing a framework, the reality is that you will never have to replace the domain layer. Your domain is the most stable dependency you will have in your other layers. It is the core of the application, and replacing it would mean creating an entire different application. Additionally, adding seams into your application just to follow a design principle blindly can add complexity without any benefits.

Domain Models Should Be Simple

Domain models tend to encapsulate simple domain behavior. This is because domain services are the ones responsible for carrying out the complex business behavior that include more than one model. Given this, and the fact that model contain deterministic behavior, it can be argued that a domain model interfaces would not provide a big benefit when it came to writing unit tests for modules that rely on domain models. If you find yourself working with complex models, that is a sign that the domain should go through a distillation process to simplify it.

Conclusion

It is not a white-black issue. I would consider both of them to be valid interpretations of DDD, clean architecture, and SOLID. Personally, I side more with not implementing since adding extra abstractions has a cost, and as long as the models stay simple, unit testing modules that depend on domain models should not be a problem.

My Linkedin Profile
My Github