DEV Community: Daniel Cerverizzo

Comprehension Debt: o custo invisível de programar sem entender🇧🇷

Daniel Cerverizzo — Sat, 31 Jan 2026 04:39:49 +0000

Afinal, tecnologias que geram código são nossas inimigas?

A resposta é não. A tecnologia nasce para ajudar.
Mas nem sempre o efeito é exatamente o que esperamos.

No final de 2022, tivemos o lançamento do ChatGPT, uma das ferramentas mais impactantes desde a invenção da internet. Desde então, vimos mudanças rápidas na sociedade e no mundo do desenvolvimento não foi diferente. Entramos na onda: usamos IA para tirar dúvidas, gerar soluções e, principalmente, escrever código.

Com esse avanço, algo curioso começou a acontecer. Fóruns técnicos mudaram de comportamento. Plataformas como o Stack Overflow passaram a receber menos perguntas. O padrão mudou: menos dúvidas públicas, mais prompts privados.
Isso indica uma transição importante: as pessoas deixaram de perguntar por quê e passaram a pedir faça por mim.

Para um desenvolvedor sênior, usar um prompt para gerar uma classe pode ser apenas um atalho de produtividade.
Mas e para um desenvolvedor iniciante?

Se até Linus Torvalds já afirmou usar ferramentas de IA, por que nós não poderíamos?
A diferença está em um detalhe que quase não entra na equação:
o iniciante entende o que a máquina está escrevendo?

Esse ponto nos leva ao conceito de comprehension debt.

Assim como technical debt surge quando escolhemos atalhos técnicos, comprehension debt surge quando escolhemos atalhos mentais. É o acúmulo de código que funciona, mas que ninguém realmente entende nem mesmo quem escreveu.

Você copia, cola, ajusta… mas não compreende o motivo.
Isso cria uma falsa sensação de progresso.
A tarefa foi concluída, mas o aprendizado não aconteceu.

Imagine um navio navegando sem bússola e sem mapa. Ele até anda… mas não sabe para onde está indo.
Programar sem entender é exatamente isso: produzir código sem compreender o “porquê” das decisões.

Não é código ruim.
É código sem dono.

A IA não cria esse problema.
Ela amplifica.

A partir de um prompt, o código aparece rápido e a tarefa parece resolvida. Isso gera a impressão de eficiência, mas também pode gerar aprendizado superficial.
Se a IA resolve rápido, quem aprende?

Como saber se você está acumulando comprehension debt?

Algumas perguntas simples ajudam:

Você conseguiria implementar essa funcionalidade sem usar prompts?
Você sabe explicar o que o código gerado está fazendo?
Você tem medo de mexer no código sem pedir ajuda da IA?
Você apenas testa no localhost e torce para funcionar?

Se você não consegue explicar a solução, provavelmente não entendeu o problema.
E se você só testa e torce… algo está errado.

O custo disso aparece com o tempo.
Você evolui mais devagar, cria dependência das ferramentas e fragiliza sua base como desenvolvedor.
Em um processo seletivo, sem IA, como você se sairia?

Você troca velocidade hoje por estagnação amanhã.

O objetivo não é parar de usar IA.
É mudar como você usa.

Como conselho prático:

Peça para a IA explicar o código que ela gerou.
Reescreva a solução com suas próprias palavras.
Simule mentalmente o fluxo do programa.
Faça pequenos testes e alterações para ver o efeito.
Tente escrever primeiro e só depois peça revisão da IA.

Use a IA como copiloto, não como motorista.

Como ferramenta auxiliar, ela é incrível.
Mas só se você estiver navegando com mapa e bússola e não apenas sendo levado pela corrente.

Comprehension Debt: The Hidden Cost of Coding Without Understanding 🇺🇸

Daniel Cerverizzo — Sat, 31 Jan 2026 04:33:07 +0000

🇧🇷 Leia em português

Are technologies that generate code our enemies?

The answer is no. Technology exists to help.
But the result is not always what we expect.

At the end of 2022, ChatGPT was released, one of the most impactful tools since the invention of the internet. Since then, we have seen fast changes in society and software development was no exception. We joined the wave: using AI to solve doubts, generate solutions, and mainly write code.

With this growth, something interesting started to happen. Technical forums began to change. Platforms like Stack Overflow started receiving fewer questions. The pattern shifted: fewer public doubts, more private prompts.
This shows an important transition: people stopped asking why and started asking do it for me.

For a senior developer, using a prompt to generate a class can be just a productivity shortcut.
But what about a beginner?

If even Linus Torvalds uses AI tools, why couldn’t we?
The difference is a detail that is often ignored:
does the beginner understand what the machine is writing?

This brings us to the idea of comprehension debt.

Just like technical debt comes from technical shortcuts, comprehension debt comes from mental shortcuts. It is the accumulation of code that works, but no one really understands not even the person who wrote it.

You copy, paste, and adjust… but you don’t understand why.
This creates a false feeling of progress.
The task is done, but learning did not happen.

Imagine a ship sailing without a compass or a map. It moves… but it does not know where it is going.
Coding without understanding is exactly that: producing code without knowing the reasons behind the decisions.

It is not bad code.
It is ownerless code.

AI does not create this problem.
It amplifies it.

With a single prompt, code appears and the task seems solved. This creates a sense of efficiency, but also shallow learning.
If AI solves it fast, who is learning?

How can you know if you are building comprehension debt?

Some simple questions help:

Could you implement this feature without using prompts?
Can you explain what the generated code is doing?
Are you afraid to change the code without asking AI?
Do you only test on localhost and hope it works?

If you cannot explain the solution, you probably did not understand the problem.
And if you only test and hope… something is wrong.

The cost appears over time.
You grow slower, become dependent on tools, and weaken your foundation as a developer.
In a job interview, without AI, how would you perform?

You trade speed today for stagnation tomorrow.

The goal is not to stop using AI.
It is to change how you use it.

Practical advice:

Ask the AI to explain the code it generated.
Rewrite the solution in your own words.
Run the program flow in your head.
Make small changes and see what happens.
Try to write first and ask for AI review later.
Use AI as a copilot, not as the driver.

As a helper tool, it is amazing.
But only if you are navigating with a map and a compass not just following the current.

Microfrontends: A Solution or Just Distributed Complexity?

Daniel Cerverizzo — Fri, 30 Jan 2026 21:58:56 +0000

We live in a time where applications keep growing, teams keep getting smaller, and deployment is still slow.
In this context, microfrontends seem like an obvious answer.
But if an AI can generate an architecture in seconds, who takes responsibility for the consequences of that choice?

The problem is not generating code.
The problem is sustaining decisions.

Microfrontends are a good solution in many contexts. The real question is: do they make sense in yours?
It is still common to treat this architecture as a silver bullet, when in some scenarios it is just complexity disguised as overengineering. That is why analyzing your ecosystem and its trade-offs is more important than following the latest trend.

Microfrontends promise autonomy. But when implemented without care, they often multiply problems instead of solving them.

What are microfrontends?

In simple terms, microfrontends apply the same idea of microservices to the frontend: splitting the system into independent parts, each with a clear responsibility.

Instead of one large frontend, the product is composed of domains. One project handles the dashboard, another handles forms, another handles checkout. Each team becomes the owner of a part of the product not just a screen.

This separation does not necessarily require different technologies. In most cases, teams use the same stack. What really changes is the boundary of responsibility and the level of isolation between parts.

When does it make sense to use microfrontends?

Make sense when the problem is no longer only technical, but also organizational.

They usually work better when:

the team is large
product domains are well defined
there is a real deployment bottleneck
team dependencies are slowing down delivery

In this scenario, splitting the frontend by domain allows each part to evolve more independently. Teams gain autonomy and delivery becomes more predictable.

When it does NOT make sense

Microfrontends are not a good choice when:

the application is small
there is only one team
the main problem is messy code

In these cases, a simpler architecture often solves the problem with less cost.
Before breaking the frontend into pieces, it is worth asking if the problem is really scale or just internal organization.

Technical strategies and risks

There are several approaches, and everything depends on scope and time. On the frontend, microfrontends affect both build time and runtime integration, especially in systems that handle a lot of data.

Module Federation, for example, allows sharing code as if it were an external library. This makes integration easier, but creates runtime dependency. The problem moves from “build is broken” to “version mismatch in production”.

Web Components help standardize behavior and reuse components across projects. Without this, the system becomes a group of different applications trying to look like a single product.

The main risks appear quickly:

duplicated dependencies
incompatible versions
higher observability cost
harder debugging

The more applications you have, the more discipline you need.

Where microfrontends work (and where they break)

Without contracts, there is no independence. There is chaos.
Microfrontends only work when there is a clear agreement between parts: what each domain does, what it exposes, and what it consumes.

The problem is rarely technical first. It is organizational.

Microfrontends help when the main issue is coordination between teams. If the problem is only technical, a good refactor may be more effective.

Standards are no longer optional. Design systems, versioning, and integration rules are not bureaucracy they prevent autonomy from becoming fragmentation.

A warning sign is version divergence between projects.
For example:

Checkout: React 18
Dashboard: React 15

Does it work? Maybe.
Is it healthy? Probably not.

A real scenario

An e-commerce company started with a single frontend responsible for everything: registration, user profile, checkout, and admin panel.

As the product grew, problems appeared:

more frequent deployments
code conflicts
slow reviews
delayed releases

The problem was not technical. It was organizational.

The solution was to split the frontend by domain:

checkout
user profile
admin panel
reports

Each project got its own repository and deployment pipeline. For the user, nothing changed. For the teams, everything changed.

The cost came later: more standards, stronger dependency control, and more concern about observability. Complexity did not disappear it was redistributed.

In the end, microfrontends are a valid solution in many contexts. But the trade-offs must be on the table.

Before adopting them, it is always worth asking:

Are you using microfrontends to scale your product…
or to hide technical debt?

Unlocking the World of International Job Listings: A Node.js and Puppeteer Web Scraping Project🚀

Daniel Cerverizzo — Mon, 06 Nov 2023 13:32:17 +0000

Introduction

Job hunting can be a daunting task, especially with countless job platforms offering excellent opportunities. Faced with this challenge, I decided to streamline my job search by consolidating the most frequently visited websites into a single, accessible resource.

But how did I go about it? My solution was to create a web scraper using cutting-edge technologies such as Puppeteer, Node.js, and MongoDB. This blog post takes you on a journey through the structure and development of this simple yet powerful project.

The Quest Begins

The first step in my mission to simplify the job search process was to leverage web scraping. Web scraping allowed me to extract data from multiple job websites, collate it, and present it in a user-friendly format.

For this, I chose Puppeteer, a headless Chrome browser, and Node.js, a powerful JavaScript runtime. These technologies worked in tandem to retrieve job listings and relevant details. With the data collected, I stored it efficiently using MongoDB, a document-based NoSQL database.

The Building Blocks

To commence my project, I initiated the process of creating a web scraper using Puppeteer. This technology granted me access to web pages, from where I could extract crucial job listing data.

Node.js played a vital role in orchestrating this process. By utilizing JavaScript, I could craft functions to navigate web pages, retrieve job descriptions, and compile the data into structured information.

Storing Data for Easy Access

MongoDB, known for its flexibility in handling unstructured data, proved invaluable. It served as the perfect repository for the job listings gathered from web scraping.

The NoSQL database stored each job listing as a document, making it easier to organize, retrieve, and display the data in a user-friendly manner.

Project structure

The project's root directory is where all your project files and subdirectories reside.

`src/`

The src/ directory contains the source code of your project.

scripts/: This directory houses the core logic of your web scraping and database operations.
- scraper.js: The main script for web scraping using Puppeteer and Node.js.
- database.js: Script for handling MongoDB database operations.
server.js: Your main Node.js application file to serve the scraped data to a frontend.

`models/`

The models/ directory contains the data models, schemas, or structures for your project.

jobSchema.js: Defines the schema for job listings to be stored in your MongoDB database.

`utils/`

The utils/ directory contains utility files, configurations, and other miscellaneous scripts.

sites.js: A configuration file listing the websites to scrape, including selectors for job details.
config.js: Configuration settings for your database connection.

`node_modules/`

This directory contains the Node.js modules and packages that your project depends on. You don't need to manage this directory manually.

`.gitignore`

The .gitignore file specifies which files or directories should be ignored when you push your project to a version control system like Git. Commonly, it includes the node_modules/ directory.

`package.json`

The package.json file lists project metadata and dependencies. It's also where you specify your project's main entry point and various scripts.

`README.md`

The README file provides essential information about your project, including how to set it up, run it, and any other necessary documentation.

This structured approach keeps your project organized, making it easier to manage and collaborate with others. The main logic for web scraping and database operations is separated, ensuring a clean and maintainable codebase. You can customize this structure based on your specific project needs.

Code

The Scraper Class

Our scraper will be encapsulated in a class for modularity and maintainability. Here's what it looks like:

// Import necessary modules and configuration
const puppeteer = require('puppeteer');
const sites = require('../utils/sites');
const database = require('../utils/config');

class Scraper {
  async scrapeData(site) {
    // Create a headless Chromium browser using Puppeteer
    const browser = await puppeteer.launch();
    const page = await browser.newPage();

    try {
      // Navigate to the specified website
      await page.goto(site.url, { timeout: 600000 });

      // Select all job listings on the page using a provided selector
      const jobList = await page.$$(`${site.selectors.list}`);
      const jobData = [];

      // Loop through the job listings and extract relevant information
      for (const job of jobList) {
        const title = await job.$eval(`${site.selectors.title}`, (element) => element.textContent.trim());
        const company = await job.$eval(`${site.selectors.company}`, (element) => element.textContent.trim());
        const location = await job.$eval(`${site.selectors.location}`, (element) => element.textContent.trim());
        const link = await job.$eval(`${site.selectors.link}`, (element) => element.href);
        jobData.push({ title, company, location, link });
      }

      return jobData;
    } finally {
      // Close the browser after scraping is complete
      await browser.close();
    }
  }

  async init() {
    try {
      // Connect to the MongoDB database
      await database.connect();
      // Clear existing data in the database
      await database.clearData();
      // Scrape data from multiple sites and store it in MongoDB
      const scrapedData = await Promise.all(sites.map((site) => this.scrapeData(site)));
      // Save scraped data to MongoDB
      await database.saveDataToMongoDB(scrapedData);
    } catch (error) {
      console.error('Error in app:', error);
    } finally {
      console.log('Finish!');
    }
  }
}

module.exports = Scraper;

// Configuration for websites to scrape
const sites = [
  {
    name: 'Remotive',
    url: 'https://remotive.com/remote-jobs/software-dev',
    selectors: {
      list: 'li.tw-cursor-pointer',
      title: 'a.tw-block > span',
      company: 'span.tw-block',
      location: 'span.job-tile-location',
      link: 'a.tw-block',
    },
  },
];

module.exports = sites;

Conclusion

The fusion of Puppeteer, Node.js, and MongoDB created a comprehensive solution to simplify job searches. With this project, I centralized data from various websites, making it easier for jobseekers to access the most relevant listings. By sharing this experience, I hope to inspire others to embark on similar projects, harnessing the power of web scraping and innovative technologies. The journey to streamline your job search begins here!

You can access this project online here:

https://jobs-one-drab.vercel.app/

https://github.com/Dcerverizzo/web-scraping-jobs