Forem: Mikael Santilio

The Truth About Vibe Coding: AI Won’t Save You From Debugging

Mikael Santilio — Sun, 03 Aug 2025 17:04:25 +0000

In recent months, the term vibe coding has gained traction — generating code with the help of AI, iterating quickly until you get something that works.

Does it work? Yes, especially for problems that are widely documented on the internet. But like any powerful tool, it must be used consciously — especially in a corporate environment, where the challenges are very different from GitHub tutorials.

This article walks you through a debugging process you can apply to ensure that the code generated (by you, AI, or colleagues) actually works. It also covers where AI shines and where it tends to fail.

1. Where AI Works Well — and Where It Fails

AI is great at solving problems that have already been solved and are widely documented. If you need to create a CRUD with JWT authentication, craft a complex SQL query, or set up an Express server, AI will likely get it right quickly. That’s because the model has seen many similar examples during its training.

But internal company projects are a different story. Here, the codebase is closed, with unique business rules, custom architecture, and specific integrations — things the AI has never seen. In these cases, asking it to solve a complex problem end‑to‑end rarely works.

What works better:
Break big problems into smaller, well‑defined tasks, such as:

Creating utility functions
Suggesting regex patterns for validation
Building data migration scripts
Writing unit tests

2. Debugging Process

When code — whether written by you, others, or AI — misbehaves, follow this simple but effective process:

Check what the error is returning
- Read the stack trace carefully to understand where the problem occurred.
- Example:
```
 NoMethodError: undefined method `map' for nil:NilClass
     from user_service.rb:42:in `get_user_list'
```
Here, you can already tell that .map is being called on something that is not an array, likely nil.

Note: If the application does not store stack traces in logs and you cannot see them easily, you will need to add breakpoints or debug instructions (puts, logger.info, etc.) throughout the flow until you pinpoint exactly where the problem happens.

Reproduce the error in a controlled environment
- Set up a local replica of the project or use an isolated environment (container, VM, etc.).
- In the example above, create a quick test calling get_user_list with the same parameters used in the environment where the error occurred.
- This confirms whether the bug is a real code issue or just an environment/configuration quirk.
Trace the error path
- If the bug is in an endpoint, place strategic breakpoints along that flow to inspect variables.
- In the example, adding a binding.irb right before the .map call revealed that fetch_users_from_db was returning nil instead of an empty array.
- Fixing it:
```
 def get_user_list
   users = fetch_users_from_db || []
   users.map { |u| format_user(u) }
 end
```
removes the error.

Logic Errors

Not all problems throw exceptions. A logic error occurs when code runs without crashing but produces incorrect results.
This can happen, for example:

Incorrect database values
The system stores "Brazil" in the country field when the PRD specifies it should store the ISO code "BR".
Wrong business rule applied
A 15% discount being applied when the requirement was 10%, due to an incorrect backend calculation.
Incomplete or reversed workflow
An API writes to the database before checking permissions, when it should validate first.

These are trickier because they leave no clear traces in the stack trace — you must trace the flow step‑by‑step, inspect variables, analyze SQL queries, and compare the real output against what the PRD defines as correct.

3. The Risk of Context Rot

Just like a human brain can experience brain rot from endless consumption of low‑value content, an AI conversation can suffer from context rot when overloaded with irrelevant information, outdated assumptions, or excessive detail.

In both cases, the “signal” gets buried under too much “noise”, and the output quality drops.

It happens when the AI’s context becomes:

Overly long
Cluttered with noise
Outdated compared to the current problem state

The result? Inaccurate answers or focus on the wrong aspects.

How to avoid it:

Periodically summarize the conversation
Restart the prompt with a clean, concise summary
Avoid dumping large, unfiltered logs

4. Security When Using AI for Development

Regardless of the problem:

Never share credentials or sensitive data.
Do not send private integration code without anonymizing it.
For database access, avoid write permissions when running AI‑generated code unless you’ve audited it.

5. AI as Co‑Pilot, Not Pilot

Using AI to generate code isn’t wrong. But remember:

For public and well‑known problems, it can create fast, high‑quality solutions.
For internal and complex projects, use it for smaller tasks and always review the output.
The developer’s role is to analyze, validate, and debug — that’s what ensures AI‑generated code is truly useful in real‑world environments.

Conclusion

The vibe coding hype doesn’t replace solid knowledge. AI is powerful but works best when guided clearly and used for well‑defined tasks.

In the end, knowing how to debug remains one of the most valuable skills a developer can have — and it’s what makes AI‑generated code truly useful in the real world.

Sources

Essential MongoDB: A Practical Guide to Creating CRUD Operations and Powerful Aggregations

Mikael Santilio — Sun, 19 Jan 2025 14:35:17 +0000

Introduction

MongoDB is a popular NoSQL database, widely used for its flexibility and capacity to handle large volumes of data. In this article, we will explore four crucial operations in MongoDB: insert, find, update, and delete. We will also discuss the stages of an aggregate pipeline that offer powerful functionalities for data analysis and transformation.

MongoDB CRUD Operations

Create/Insert

To insert documents into a MongoDB collection, we use the command insertOne() to add a single document or insertMany() to add multiple documents.

insertOne:

db.collection('users').insertOne({
    name: "John Doe",
    age: 30,
    email: "john.doe@email.com"
});

insertMany:

db.collection('users').insertMany([
    { name: "Ana Doe", age: 25, email: "ana.doe@email.com" },
    { name: "Carlos Mendes", age: 40, email: "carlos.mendes@email.com" }
]);

Read

To read documents, we use the command find(). The first argument is the filter, and the second argument is optional, allowing us to specify which fields will be returned in the query.

find:

db.collection('users').find({ name: "John Doe" }, { name: 1, email: 1 });

Update

Update operations are performed using the methods updateOne() and updateMany(). You can also use operators like $set, $inc and $rename, among others.

updateOne:

db.collection('users').updateOne(
    { email: "john.doe@email.com" },
    { $set: { age: 31 } }
);

updateMany:

const result = db.collection('users').updateMany(
    { age: { $gte: 30 } },
    { $inc: { age: 1 } }
);

Delete

To remove documents, we use the methods deleteOne() and deleteMany().

deleteOne:

db.collection('users').deleteOne({ email: "ana.doe@email.com" });

deleteMany:

db.collection('users').deleteMany({ age: { $lt: 18 } });

Aggregate Pipeline

MongoDB offers an aggregation framework to perform more complex queries that can involve multiple stages linked in a pipeline. Here are some commonly used stages:

1. `$match`

Filters documents based on specified criteria.

db.collection('sales').aggregate([
    { $match: { status: "finished" } }
]);

2. `$group`

Groups documents based on a specific key, which can be a value of a field or a combination of fields. Operations performed inside a $group are called accumulators, some of which include $sum, $addToSet, and $first.

db.collection('sales').aggregate([
    {
        $group: {
            _id: "$category",
            totalSales: { $sum: "$value" },
            sales: { $addToSet: '$$ROOT' }
        }
    }
]);

3. `$project`

Controls which fields are returned. In this stage, you choose which fields will appear and can add new columns with custom values, such as through multiplication. It is important to note that in this stage, you cannot have both projection 0 and 1 for the same field, except for the _id.

db.collection('sales').aggregate([
    {
        $project: {
            _id: 0,
            category: 1,
            priceWithTax: { $multiply: ["$price", 1.2] }
        }
    }
]);

4. `$addFields`

With this stage, you can add new fields or modify existing fields.

db.collection('sales').aggregate([
    {
        $addFields: {
            priceWithTax: { $multiply: ["$price", 1.2] }
        }
    }
]);

5. `$sort`

Orders documents in ascending (1) or descending (-1) order.

db.collection('sales').aggregate([
    { $sort: { price: -1 } }
]);

6. `$limit` and `$skip`

Control the pagination of results.

db.collection('sales').aggregate([
    { $sort: { price: -1 } },
    { $limit: 10 },
    { $skip: 20 }
]);

7. `$unwind`

The $unwind operator decomposes an array field into individual documents, generating one document for each element in the array. For example, if your collection has 5 documents, and each document has an array field with 5 objects, the result will be 25 documents. Example in MongoDB Playground

db.collection('sales').aggregate([
   {
        "$unwind": {
            "path": "$products",
            "preserveNullAndEmptyArrays": true
        }
    }
]);

8. `$switch`

Allows returning results based on conditional evaluations.

db.collection('sales').aggregate([
   {
        "$project": {
            "price_description": {
                $switch: {
                    branches: [
                        { case: { $gt: ["$price", 5] }, then: "greater than 5" },
                        { case: { $lt: ["$price", 5] }, then: "less than 5" },
                    ],
                    default: "unknown price"
                }
            }
        }
    }
]);

9. `$map`, `$filter` e `$reduce`

These are array manipulation operations, generally used inside $project or $addFields. Example in MongoDB Playground

db.collection('sales').aggregate([
  {
    "$project": {
      products: {
        "$map": {
          "input": "$products",
          "as": "product",
          "in": {
            "$concat": [
              "$$product.name",
              " - ",
              {
                "$toString": "$$product.price"
              }
            ]
          }
        }
      },
      products_w_price_gte_10: {
        "$filter": {
          "input": "$products",
          "as": "product",
          "cond": {
            "$gte": [
              "$$product.price",
              10
            ]
          }
        }
      },
      products_values: {
        "$reduce": {
          "input": "$products.price",
          "initialValue": "",
          "in": {
            "$concat": [
              "$$value",
              {
                "$cond": [
                  {
                    "$eq": [
                      "$$value",
                      ""
                    ]
                  },
                  "",
                  ", "
                ]
              },
              {
                "$toString": "$$this"
              }
            ]
          }
        }
      }
    }
  }
]);

10. `$lookup`

The $lookup stage is used to search records in another collection based on a foreign key, similar to a JOIN in SQL. It can be used in a simple way by comparing two keys (localField and foreignField):

db.collection('sales').aggregate([
    {
        "$lookup": {
            "from": "users",
            "localField": "user_id",
            "foreignField": "_id",
            "as": "users"
        }
    }
]);

The $lookup can also use additional comparison fields by utilizing let for variables and a specific pipeline. It is important to remember that if you use a pipeline inside a lookup, it is only possible to compare variables defined in let with the columns of the collection chosen using $expr. Example in MongoDB Playground

db.collection('sales').aggregate([
    {
        "$lookup": {
            "from": "users",
            "let": { "userId": "$user_id" },
            "pipeline": [
                {
                    "$match": {
                        "$expr": {
                            "$and": [
                                { "$eq": ["$user_id", "$$userId"] }
                            ]
                        }
                    }
                },
                {
                    "$project": {
                        "_id": 0,
                        "email": 1
                    }
                },
                {
                    "$limit": 1
                }
            ],
            "as": "users"
        }
    }
]);

Monolith, Modular Monolith, and Microservices: A Comparison

Mikael Santilio — Mon, 06 Jan 2025 14:03:15 +0000

Software architecture plays a pivotal role in the success of any application. Among the most frequently discussed architectural models are monoliths, modular monoliths, and microservices. Choosing the right model depends on factors such as system complexity, scalability requirements, and maintenance considerations. In this article, we gonna view a quick introduction of each concept with some examples.

Monolith

The monolith is the most traditional architectural model, where the entire application is built as a single unit. All components (interface, business logic, and database) are integrated and interact directly within the same project.

A typical example of monolithic architecture is ERP systems used by small businesses or startups. These systems centralize all functionality within a single application, benefiting from simplicity and faster implementation during the initial stages.

Characteristics

Highly coupled: All components have direct dependencies. For example, the authentication logic, requests, and products are integrated, without clear boundaries between responsibilities.
Overlapping responsibilities: It's common to find duplicated or merged code fragments, like validation of products combined with exhibition logic or authentication. Even with some basic organization, generally there is not a robust logical split between the layers.
Example file structure:

- app/
    - controllers/
        - UsersController
        - ProductsController
    - models/
        - User
        - Product
    - services/
        - OrderService
        - EmailService

Common Scenario

In a typical scenario of a monolith, all application components are centralized in a single project:

Server: A virtual machine hosting all application processes.
API: A Rails or Laravel server managing the client interface and business logic.
Background processes: A manager like Sidekiq handles asynchronous tasks, such as sending emails or processing data.
Database: A PostgreSQL server centralized, directly integrated into the application.
Development flow: The API, Sidekiq, and database migration codes are maintained in the same repository, being developed and deployed together.

Advantages:

Simplicity: Ideal for starting a project, because of the ease of project development and deployment.
Performance: Enables fast communication between components since they operate within the same project.
Consolidated tools: Most frameworks were developed to support monolithic applications.

Disadvantages:

Limited Scalability: Horizontal scalability is less efficient because it requires the replication of the entire monolith.
Low flexibility: A minimal modification in a part of the system can affect the entire application, increasing risks.

Modular Monolith

A common example of this approach is SaaS applications in expansion, like a marketplace that splits product lists, payments, and users into internal modules. This format facilitates a future transition to a microservices architecture by establishing clear boundaries between features.

Characteristics

Responsibilities Separation: Each module (e.g., “Users”, “Requests”, “Payments”) wraps its logic and data. Interactions between modules happen using defined interfaces or services (UserService, PaymentService…), avoiding direct access to models, helpers, etc. Here, each application feature is wrapped in its own module, promoting organization and scalability.
Less Dependencies: The internal coupling is reduced because modules have clear boundaries and their interface for communication.
Preparation of Microservices: Internal modularity makes it possible to split modules into independent services in the future if necessary.
Example file structure:

- app/
    - modules/
        - users/
            - controllers/
                - UsersController
            - models/
                - User
            - services/
                - UserService
        - products/
            - controllers/
                - ProductsController
            - models/
                - Product
            - services/
                - ProductService

Common Scenario

In a modular monolith, the main project is implemented as a single unit, but organized into different modules:

Application Server: A backend like Spring Boot or Django, where each module manages a functionality (e.g., users, products, or payments).
Background Jobs: A task manager like Celery, integrated through specific configurations of modules.
Shared Database: An example is a MongoDB database with separate collections for each module or functionality.
Reusable Modules: Each module can be developed and tested separately, but the system works as a single application.

Advantages

Better organization: Modularity makes the code more legible and easier to maintain.
Ease of transition: It can serve as an intermediate step for a future migration to microservices.
Preserved performance: Like the traditional monolith, communication occurs within the same process.

Disadvantages

Internal dependencies: Coupling issues can still arise, especially if the interfaces aren’t well defined.
Monolithic deployment: Despite modularity, the system is still deployed as a single package.
Boundaries management: Requires development discipline to maintain clearly defined responsibilities between modules.

Microservices

Microservices represent a distributed architectural approach, where the application is composed of many independent services. Each service is responsible for specific functionalities and can be developed, deployed, and scaled independently.

Large-scale platforms such as Uber utilize this approach to separate critical functionalities, including geolocation, ride management, payments, and real-time communications.

Microservices Characteristics

Independent services: Each functionality is isolated in a microservice, which has its own life cycle and can be developed or deployed without directly depending on other services.
Technological flexibility: It is possible to use different technologies and programming languages for each microservice, depending on the specific needs of each functionality.
Distributed communication: Services communicate through REST APIs, gRPC, or asynchronous messages (e.g., RabbitMQ, Kafka). This approach allows for uncoupling functionalities but adds the necessity to manage latency and reliability.

Common Scenario

In a microservice-based application, services work autonomously but are orchestrated to create a coherent system:

Independent services:
- A microservice for authentication developed in Python with Flask.
- Another microservice for payments, using Node.js and integrated with a gateway like Stripe.
- A microservice for product recommendations, implemented in Go with support for machine learning models.
Orchestration:
- Solutions such as Kubernetes or Docker Compose are used to manage containers and ensure communication between services.
Distributed Databases:
- Each microservice manages its own database to meet its needs:
  - MySQL for the authentication service.
  - PostgreSQL for payments.
  - MongoDB for recommendations.

Advantages

Scalability: Allows for the individual scaling of each service, optimizing resource usage.
Resilience: Problems in one service are isolated, reducing the impact on the entire application.
Technological flexibility: Each service can adopt the most suitable technology for its functionality.

Disadvantages

Complexity: Managing communication, orchestration, and monitoring between services requires robust tools and a high level of discipline.
Infrastructure Overhead: Maintenance costs increase due to the necessity of separate environments for each service.
Latency: Communication over the network between services introduces delays and potential additional failure points.

Forem: Mikael Santilio

The Truth About Vibe Coding: AI Won’t Save You From Debugging

1. Where AI Works Well — and Where It Fails

2. Debugging Process

Logic Errors

3. The Risk of Context Rot

4. Security When Using AI for Development

5. AI as Co‑Pilot, Not Pilot

Conclusion

Sources

Essential MongoDB: A Practical Guide to Creating CRUD Operations and Powerful Aggregations

Introduction

MongoDB CRUD Operations

Create/Insert

Read

Update

Delete

Aggregate Pipeline

1. $match

2. $group

3. $project

4. $addFields

5. $sort

6. $limit and $skip

7. $unwind

8. $switch

9. $map, $filter e $reduce

10. $lookup

Monolith, Modular Monolith, and Microservices: A Comparison

Monolith

Characteristics

Common Scenario

Advantages:

Disadvantages:

Modular Monolith

Characteristics

Common Scenario

Advantages

Disadvantages

Microservices

Microservices Characteristics

Common Scenario

Advantages

Disadvantages

Sources:

1. `$match`

2. `$group`

3. `$project`

4. `$addFields`

5. `$sort`

6. `$limit` and `$skip`

7. `$unwind`

8. `$switch`

9. `$map`, `$filter` e `$reduce`

10. `$lookup`