DEV Community: Guilherme Stein

Spec-Driven Development (SDD): O fim do "Vibe Coding" ou a evolução dele?

Guilherme Stein — Wed, 25 Feb 2026 16:44:01 +0000

A IA mudou a velocidade da escrita de código, mas a manutenção do contexto continua sendo o maior gargalo na engenharia. O que muitos chamam de "Vibe Coding" (jogar prompts soltos e esperar o melhor) colapsa rápido em sistemas complexos. O SDD é o novo paradigma que ganha força para inverter essa lógica.

Spec como Fonte da Verdade

No SDD, o código deixa de ser o ativo principal e passa a ser um subproduto. A fonte da verdade é a Especificação (Spec): um documento técnico (Markdown ou qualquer) que descreve intenções, regras e restrições.

Seu novo papel: Arquiteto e Revisor.
Papel da IA: Executor e Implementador.
Foco: A prioridade muda de "como escrever a função" (sintaxe) para "o que o sistema deve fazer" (intenção).

Produtividade: Métrica Token/PR

Em 2026 e adiante, a eficiência de um dev não será mais medida por linhas de código, mas sim pela relação Tokens gastos -> PR -> Nova feature entregue.

Vibe Coding: Consumo altíssimo de tokens. A IA "anda em círculos" tentando adivinhar intenções enquanto quebra o legado.
SDD: Uma spec bem escrita reduz as interações. O agente recebe o contexto completo e gera o Pull Request (PR) de forma cirúrgica. Menos tokens por PR entregue é o novo indicador de uma comunicação técnica afiada.

Context Drift e Retrabalho

Agentes de IA perdem o contexto conforme o projeto cresce (Context Drift). O SDD resolve isso forçando o modelo a voltar sempre para a base técnica da Spec, evitando o loop infinito de "conserta aqui, quebra ali".

Tradeoffs: Velocidade Real vs. Escrita Rápida

O Custo: Existe um overhead inicial de pensamento. Você gasta mais tempo validando a lógica em texto antes do primeiro.
O Ganho: A velocidade real vem da eliminação do retrabalho. Se a Spec está 10/10, a implementação vira uma commodity descartável.

O diferencial do engenheiro hoje é a capacidade de orquestrar sistemas. Quem não souber especificar com rigor, fazer um bom troubleshooting e enxergar sistemas de forma macro passará o dia brigando com prompts.

Kafka e mensageria assíncrona em 5 minutos

Guilherme Stein — Mon, 27 Nov 2023 15:17:05 +0000

Objetivo

Nesse post voce não vai aprender a implementar de forma técnica Kafka e mensageria assíncrona em seu sistema, e sim entender como ele funciona de forma simples e abstraída.

Lets go

Imagine que temos um caderno 📚. Neste caderno, algumas pessoas querem apenas ESCREVER coisas, e outras querem apenas LER o que está escrito. Chamaremos de PUBs e SUBs, respectivamente, essas pessoas.

As pessoas que escrevem no caderno têm algo importante para compartilhar, então elas abrem o caderno e escrevem suas mensagens. Essas mensagens podem ser sobre qualquer coisa, como histórias, pensamentos ou até mesmo tarefas que precisam ser feitas.

Por outro lado, as pessoas que só querem ler podem vir ao caderno a qualquer momento, abrir e ler as mensagens que foram escritas pelos escritores. Eles não precisam estar lá quando a mensagem é escrita; podem ler mais tarde, dependendo da estratégia preestabelecida (não vamos nos concentrar nisso).

A parte legal é que os leitores não precisam esperar pelos escritores. Eles podem continuar fazendo suas tarefas e voltar ao caderno quando quiserem. As mensagens ficam lá esperando por eles ⏰⏰⏰.

E no nosso caderno nao precisamos ter apenas escritores, podemos ter desenhistas, compositores, poetas e todo e qualquer outro tipo de produtor que queira se expressar no nosso espaco.

Então, resumindo,

Kafka é como um assistente que cuida do caderno. Ele garante que as mensagens sejam salvas com segurança e que os leitores possam pegá-las sempre que quiserem. Os escritores também não precisam se preocupar se os leitores estão lá ou não. Eles apenas escrevem, e Kafka cuida do resto.

Mensageria assíncrona significa que os escritores não precisam esperar pelos leitores. Eles escrevem suas mensagens quando quiserem, e os leitores podem lê-las no seu próprio tempo. É como se os escritores deixassem recados para os leitores, e estes pudessem chegar e ler esses recados quando achassem conveniente. Nossos PUBs são nossos Publishers e nossos SUBs são nossos Subscribers.

Alinhando com o conceito de Microsserviços

Agora, imagine que o caderno ficou muito popular e diversas pessoas (PUBs) querem usá-lo para compartilhar diferentes tipos de informação.

Então, em vez de ter apenas um caderno, podemos ter vários cadernos (que também podemos chamar de TÓPICOS) e cada um dedicado a um tipo diferente de mensagem. O microsserviço nesse cenário fica responsável por escrever e/ou ler em determinado caderno (às vezes os dois).

Essa abordagem é como uma maneira organizada e eficiente de compartilhar informações importantes!

How to ensure code quality with automated pipelines on your codebase 🛠️⚙️🚨

Guilherme Stein — Sat, 15 Apr 2023 18:22:20 +0000

Automated pipelines have become an essential part of the software development process. They help ensure that code is tested and deployed consistently, saving time and reducing the possibility of errors. Here, we'll show you how to create an automated pipeline using GitHub Actions that is simple and efficient, and that ensures that committed code to the main branch is only merged if it passes through the configured pipeline.

Step 1: Set up the GitHub Actions environment
First, we need to understand that GitHub recognizes that you have a configuration for actions when you create the ".github/workflows" folder in your repository. You can do this in two ways, either through GitHub's GUI by clicking on the "Actions" tab and selecting "Set up a workflow yourself". This will allow you to create a new pipeline configuration file. Or you can manually create the directory in your repository and commit the change. The "main.yml" file will be your pipeline.

Step 2: Define the trigger for the pipeline
The next step is to define the trigger for your automated pipeline. This is done using the "push" event, which triggers the pipeline whenever a commit is made to the main branch of your repository. To define the trigger for the pipeline, add the following code to the "main.yml" file:

on:
  push:
    branches:
      - main

Step 3: Define the jobs of the pipeline
Now it's time to define the jobs that will be executed by the pipeline. A job is a specific task that should be performed by the pipeline, such as unit or integration tests, code builds, etc. You can define several jobs for your automated pipeline.

To keep your code healthy, we suggest defining at least two jobs: one for unit tests and one for integration tests. Here is an example of how to define a unit test job:

jobs:

  unit-tests:

    runs-on: ubuntu-latest

    steps:
      - name: Use Node.js
        uses: actions/checkout@v2

      - name: Install dependencies
        run: npm install

      - name: Running unit tests
        run: npm run test:unit

This job performs the following steps:

Checkout code.
Install the necessary dependencies.
Run unit tests.

Going deeper into the pipeline
Personally, I like pipelines that merge into my main branch only if all tests pass. Here's an example pipeline that gives me that:

name: project-name
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:

  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Use Node.js
      uses: actions/setup-node@v2
      with:
        node-version: 16.x

    - name: Install dependencies
      run: npm install

    - name: Checking lint
      run: npm run lint

    - name: Running unit tests
        run: npm run test:unit

    - name: Start application
      run: npm start &

    - name: Wait for application to start
      run: sleep 10s

    - name: Test health-check endpoint
      run: curl http://localhost:3333/api/health-check

    - name: Check for errors
      if: ${{ job.status != 'success' }}
      run: exit 1

    - name: Merge to main
      if: ${{ job.status == 'success' }}
      uses: ad-m/github-push-action@v0.6.0
      with:
        branch: main
        github_token: ${{ secrets.ACCESS_TOKEN }}

However, in this case we need to configure a permission setting in GitHub Actions.

Settings -> Actions -> General -> Workflow permissions and choose read and write permissions

And voila, you now have a setup to ensure good commits in your code 😄😄😄.

Refs

Serverless + JS: Um bot de web-scrapping diário

Guilherme Stein — Mon, 14 Nov 2022 20:32:38 +0000

Introducao

Se você está procurando uma maneira eficiente de coletar informações da web e não quer se preocupar com a infraestrutura de servidores, você precisa conhecer o poder do Serverless. O Serverless é um framework que permite criar arquiteturas sem servidores orientadas a eventos. Isso significa que você pode se concentrar nos eventos e comportamentos esperados em seus projetos, em vez de se preocupar com as máquinas que devem executá-los.

Ao usar o Serverless, você pode economizar tempo e dinheiro, pois só paga pelos recursos que usa. Além disso, para os desenvolvedores iniciantes, o Serverless oferece a possibilidade de criar projetos sem ter que lidar com a complexidade da infraestrutura.

Neste post, mostrarei como criei um bot de web-scrapping diário usando Serverless e JavaScript para informar o cardápio do restaurante universitário da minha faculdade pelo Telegram. O projeto está disponível em meu repositório GitHub (https://github.com/guisteink/sls-menu-service), e vou presumir que você tenha um conhecimento básico em Serverless.

Configuracoes de infraestrutura

O maximo que voce vai precisar saber configurar de infra nesse projeto sera isso.

provider:
  name: aws
  runtime: nodejs12.x
  memorySize: 128
  stage: v2
  region: sa-east-1
  timeout: 30

Simples assim!

Duas funções são executadas diariamente às 10h45 e 15h45 para capturar o almoço e o jantar do dia, respectivamente. Essas funções são agendadas via Lambda e consomem o método de scraping do site que contém o cardápio diário. Em seguida, a mensagem é tratada com alguns regex para melhor identificação no Telegram e enviada para o bot, que direciona a mensagem para o grupo (https://t.me/cardapioufes).

Funcoes

O handler dispara o mecanismo citado, e pode ser ativado de duas maneiras:

Pelo job agendado;
Por uma chamada http (POST) na rota.

Tambem existe o endpoint para receber o cardapio diario via REST, dando um GET na rota. Em casos de consumo da API.

functions:
  getMenuOfTheDay:
    handler: src/endpoints/getMenuOfTheDay.handler
    events:
      - http:
          method: GET
          path: /menu
  sendLunchMessageToGroup:
    handler: src/endpoints/scheduleEvent.handler
    events:
      - http:
          method: POST
          path: /message/almoco
      - schedule:
          rate:
            - cron(45 13 * * * *)
          enabled: true
          input:
            dish: almoco

Conclusao

Esse é apenas um exemplo do que é possível fazer com a arquitetura Serverless. Com ela, você pode criar projetos escaláveis e eficientes, economizando tempo e dinheiro. Além disso, com o Serverless, você pode se concentrar na lógica do seu projeto, em vez de se preocupar com a infraestrutura de servidores.