Se você acompanha o vocabulário que está se formando ao redor da engenharia de software com IA, provavelmente já esbarrou na palavra harness. Ela aparece em posts da Anthropic, na documentação do Claude Code, em artigos sobre Cursor e Cline, e em discussões sobre como construir agentes em produção.

Mas o que harness quer dizer, afinal?

A tradução literal — “arnês”, “cinto”, “atrelagem” — já entrega quase tudo. Harness é o conjunto de estruturas, regras, ferramentas e contexto que envolve um LLM para fazê-lo trabalhar de forma útil, segura e repetível em um problema real. O LLM sozinho é um cavalo: forte, rápido e meio caótico. O harness é o que transforma esse cavalo em uma carruagem que chega no destino.

Quando alguém diz “o Claude Code é um agentic harness”, está dizendo: existe um LLM no centro, e em volta dele existe uma camada de software que decide quais ferramentas ele pode chamar, qual contexto ele recebe, quais regras ele precisa seguir, quando ele para, o que acontece quando ele falha. Essa camada é o harness.

Por que esse conceito importa agora?

Até pouco tempo atrás, “usar IA pra programar” significava abrir o ChatGPT, colar código, copiar resposta. O LLM era um oráculo isolado: você pergunta, ele responde, você decide o que fazer.

A geração atual de ferramentas — Claude Code, Cursor, Cline, Aider, Codex — mudou essa equação. O LLM agora age dentro do seu projeto: lê arquivos, roda comandos, faz commits, abre PRs. E para que ele aja sem destruir tudo, alguém precisou construir uma camada de contenção e orientação ao redor dele.

Essa camada é o que diferencia uma demo bonita de uma ferramenta que aguenta o dia a dia de uma equipe. A qualidade do harness importa mais do que a qualidade bruta do modelo. Um modelo mediano num harness excelente entrega mais valor que um modelo top de linha num harness pobre.

A partir daqui, vamos passar pelos termos que aparecem o tempo todo nesse vocabulário. Cada um é uma peça do arnês.

Janela de contexto (Context window)

A janela de contexto é a quantidade máxima de texto (medida em tokens) que o LLM consegue “enxergar” de uma vez. Tudo o que importa para a tarefa precisa caber ali dentro: a sua pergunta, o histórico da conversa, os arquivos que o agente leu, as definições das tools, as regras do projeto, as respostas anteriores do modelo.

Modelos recentes oferecem janelas de 200 mil, 1 milhão ou até mais tokens — números que parecem astronômicos mas se esgotam rápido quando o agente começa a ler arquivos grandes ou a rodar comandos verbosos.

O harness é quem gerencia a janela: decide o que entra, o que sai, o que vira resumo, o que é jogado fora. Sem essa gerência, em três interações você teria estourado o limite.

Spec-Driven Development (SDD)

Spec-Driven Development é a prática de escrever uma especificação clara antes de pedir ao agente para implementar. Em vez de mandar “cria um endpoint de login”, você produz um documento que descreve o comportamento esperado, os casos de borda, os contratos de entrada e saída, e só depois entrega ao agente para implementar.

A ideia não é nova — é basicamente engenharia de software como sempre foi feita, só que com um detalhe novo: o agente é um leitor literal. Ele faz exatamente o que está escrito, e omissões viram suposições. Uma spec bem feita reduz o “telefone sem fio” entre o que você quis dizer e o que o modelo entendeu.

O fluxo típico do SDD com agentes é:

1. Brainstorm — uma conversa com o agente para esclarecer requisitos.
2. Spec — documento curto que captura decisões e critérios de aceitação.
3. Plan — desdobramento da spec em passos implementáveis.
4. Work — o agente executa o plano.
5. Review — você (ou outro agente) revisa o resultado contra a spec.

Cada uma dessas etapas tende a virar um slash command ou um skill dentro do harness.

Specs

Uma spec (de specification) é o documento curto que descreve o que deve ser construído e por quê — sem entrar em como. Ela vive próxima do código (geralmente em docs/specs/ ou specs/) e é tratada como artefato versionado.

Uma spec útil costuma ter:

• Objetivo — uma frase explicando a intenção.
• Contexto — por que isso é necessário agora.
• Comportamento esperado — bullets descritivos, em linguagem natural.
• Casos de borda — o que acontece quando dá errado.
• Critérios de aceitação — como saber que está pronto.
• Não-objetivos — o que explicitamente fica de fora.

A última seção é a que mais economiza tempo com agentes: declarar explicitamente o que não fazer evita que o modelo invente features que ninguém pediu.

ADRs (Architecture Decision Records)

ADR significa Architecture Decision Record. É um documento curto que registra uma decisão arquitetural relevante, junto com o contexto que a motivou e as consequências esperadas. O formato foi popularizado por Michael Nygard e virou padrão em muitos times.

A estrutura clássica de um ADR tem quatro seções:

1. Contexto — qual era o problema ou a situação na época.
2. Decisão — o que foi escolhido.
3. Status — proposto / aceito / substituído.
4. Consequências — o que ganhamos e o que perdemos com essa escolha.

Em um projeto que trabalha com agentes, ADRs cumprem um papel duplo: orientam o time humano e alimentam o contexto do agente. Quando você abre uma sessão pedindo “implemente o cache de sessão usando Redis”, o agente que leu o ADR-007 sabe que o projeto já decidiu padronizar TTL em 24h e usar a estratégia de cache-aside.

PRDs (Product Requirements Documents)

PRD significa Product Requirements Document. É o documento mais “alto” da família: descreve o que o produto precisa fazer e por quê, do ponto de vista do usuário e do negócio — sem se comprometer com decisões técnicas. Onde a spec responde “como esse endpoint se comporta”, o PRD responde “por que essa feature existe e qual problema do usuário ela resolve”.

Um PRD típico tem:

• Problema — qual dor do usuário ou do negócio estamos atacando.
• Persona / contexto de uso — quem usa, em que momento, com qual objetivo.
• Métricas de sucesso — como saberemos que funcionou (adoção, conversão, redução de ticket de suporte).
• Escopo da v1 — o conjunto mínimo de comportamento que entrega valor.
• Fora de escopo — o que fica para depois (ou nunca).
• Riscos e perguntas em aberto — o que ainda precisa ser validado.

No fluxo com agentes, o PRD costuma ser o ponto de partida: a partir dele você (ou um agente como o to-prd do Claude Code) deriva um RFC para discutir a abordagem técnica, depois um ou mais ADRs registrando decisões e, por fim, specs detalhadas de implementação. O PRD ancora a intenção; todo o resto se conecta de volta a ele.

RFCs (Request for Comments)

RFC vem de Request for Comments — formato cunhado pela IETF nos anos 70 para discutir mudanças em padrões da internet. No contexto de empresas de software (Rust, Stripe, Squarespace, Basecamp), virou o nome do documento de proposta que precede uma mudança grande.

A diferença prática entre PRD, RFC, ADR e spec:

Em um time saudável, um PRD origina um RFC, o RFC discutido vira um (ou vários) ADRs, e cada ADR pode gerar uma ou mais specs de implementação. O harness se beneficia de todos esses artefatos: quanto mais texto bem-organizado existir no repositório descrevendo intenção e racionalidade, melhor o agente consegue navegar e decidir.

Rules (regras)

Rules são instruções permanentes que você dá ao agente — preferências, convenções e proibições que devem valer em todas as sessões. No Claude Code elas moram em arquivos CLAUDE.md (no projeto e/ou globais), no Cursor moram em .cursorrules, no Cline em .clinerules, e assim por diante.

Boas rules são específicas e acionáveis. Compare:

• ❌ “escreva código de boa qualidade”
• ✅ “no diretório lib/, use attr_reader em vez de definir getters manualmente”

A diferença é que a segunda pode ser verificada. Rules genéricas viram ruído; rules concretas viram comportamento.

Em projetos maiores, as rules costumam declarar:

• Stack e versões em uso (Ruby 3.3, Rails 7.2, Postgres 16).
• Convenções de nomenclatura e estilo.
• Comandos de teste, lint e build.
• O que não fazer (não mexer em migrations antigas, não rodar db:reset sem confirmar).

Skills

Skills são pacotes de conhecimento e procedimento que o agente carrega sob demanda — só quando a tarefa pede. Diferente das rules (que estão sempre presentes), uma skill fica adormecida até ser invocada por contexto ou por nome.

Uma skill típica é uma pasta com um SKILL.md na raiz, descrevendo:

• Quando ativar (triggers em linguagem natural).
• O passo a passo que o agente deve seguir.
• Arquivos de apoio (templates, snippets, exemplos).

Exemplos de skills no ecossistema Claude Code: tdd (faz red-green-refactor disciplinado), diagnose (loop de debug com hipótese-instrumentação-teste), to-issues (quebra um plano em tickets), grill-me (entrevista você para validar uma proposta).

A grande sacada das skills é a disclosure progressiva: o agente lê o nome e a descrição de todas as skills (barato), mas só lê o conteúdo completo da skill que vai usar (caro). Isso permite ter dezenas de procedimentos disponíveis sem pagar o custo de janela por todos eles.

Tools (ferramentas) e MCP

Tools são as funções que o agente pode chamar — leitura de arquivo, execução de shell, busca na web, query em banco. Cada tool é declarada no harness com nome, descrição e schema de entrada; o LLM lê essas descrições e decide quando invocar cada uma.

O MCP (Model Context Protocol) é um padrão aberto criado pela Anthropic para expor tools de forma reutilizável entre diferentes clientes de IA. Em vez de cada agente reimplementar “ler email do Gmail” ou “consultar Jira”, você sobe um servidor MCP uma vez e qualquer cliente compatível (Claude Code, Cursor, etc.) passa a usar.

Pense no MCP como o “USB-C dos agentes”: um conector padronizado entre o cérebro e o mundo.

Subagentes

Subagentes (ou sub-agents) são agentes que o agente principal pode lançar para tarefas específicas, geralmente em paralelo. Cada subagente tem a sua própria janela de contexto, executa o seu trabalho isoladamente, e devolve um resumo curto para o agente que o lançou.

A vantagem é dupla: paraleliza trabalho independente e protege a janela principal de leituras pesadas. Se você precisa que cinco arquivos enormes sejam analisados, fazer isso no agente principal queima toda a janela; delegar a cinco subagentes resolve o problema gastando contexto apenas com o resumo final.

Hooks

Hooks são scripts que o harness dispara automaticamente em momentos específicos do ciclo de vida do agente: antes de uma tool rodar, depois de um arquivo ser editado, ao receber um prompt, ao terminar uma sessão. Eles transformam regras estáticas em comportamento ativo.

Exemplos comuns:

• Rodar prettier automaticamente depois de cada Edit em arquivos .ts.
• Bloquear comandos perigosos (rm -rf, git push --force) antes que executem.
• Notificar via Slack quando o agente terminar uma sessão longa.
• Logar todas as tools usadas para auditoria.

Hooks são onde o harness deixa de ser passivo e começa a ter opinião sobre o trabalho do agente em tempo real.

Slash Commands

Slash commands (comandos /foo) são atalhos para acionar fluxos do harness ou skills específicas. No Claude Code, comandos como /plan, /work, /review, /init empacotam workflows inteiros — o usuário digita uma palavra, o harness expande para uma sequência de prompts, leituras de arquivos e invocações de tools.

A diferença prática entre slash command e skill é sutil: o slash command é a interface, a skill é o conteúdo. Muitos slash commands chamam skills por baixo dos panos.

Permissões e sandbox

Toda essa máquina precisa de limites. Permissões definem o que o agente pode fazer sem perguntar, o que ele precisa pedir aprovação e o que está terminantemente proibido. Em projetos sérios, o agente roda dentro de um sandbox (container, máquina virtual leve, devbox isolado) para que mesmo um comando errado não consiga estragar nada importante.

O harness é quem aplica essas permissões: intercepta a tool antes da execução, checa contra a lista de regras, decide se executa, pede confirmação ou recusa.

Juntando tudo: o harness como sistema

Repare na lista do que percorremos:

• Janela de contexto — quanto cabe.
• PRDs, RFCs, ADRs, Specs — o que precisa ser construído e por quê, em camadas que vão do problema do usuário até o comportamento detalhado.
• Rules — convenções sempre ativas.
• Skills — procedimentos sob demanda.
• Tools e MCP — ações no mundo.
• Subagentes — paralelismo e proteção de contexto.
• Hooks — automação reativa.
• Slash commands — interface ergonômica.
• Permissões e sandbox — limites de segurança.

Cada item, isolado, é simples. O harness é a montagem deles num sistema coerente que pega um LLM e o transforma em um colaborador de engenharia.

Quando você escolhe (ou constrói) um harness, está escolhendo opiniões sobre cada uma dessas dimensões: o quanto delegar ao modelo, o quanto escrever em texto, o quanto automatizar, o quanto travar.

Antes de escrever uma linha de código, vale separar dois conceitos que vivem misturados:

• LLM (Large Language Model) — uma função pura: recebe texto, devolve texto. Sem memória, sem ações, sem mundo externo. Você manda uma mensagem, ele responde uma vez e acabou.
• Agente de IA — um LLM dentro de um loop, com acesso a ferramentas que ele decide quando chamar. O loop só termina quando o modelo diz “acabei”.

A diferença não é técnica, é arquitetural. Um chatbot é um LLM com histórico. Um agente é um LLM com autonomia para agir.

Os quatro componentes de um agente

Praticamente todo agente — do mais simples ao mais sofisticado — combina os mesmos quatro elementos:

1. Modelo — o “cérebro” que decide o próximo passo. Hoje, normalmente um LLM (Claude, GPT, Llama).
2. Ferramentas (tools) — funções do seu código que o modelo pode chamar: ler arquivo, consultar banco, fazer requisição HTTP, executar SQL.
3. Loop de execução — quem orquestra: pergunta ao modelo, executa a ferramenta que ele pediu, devolve o resultado, repete.
4. Critério de parada — quando o modelo sinaliza end_turn, ou quando o loop atinge um limite de iterações.

É isso. Tudo o que você ouve falar sobre “agentes autônomos”, “multi-agentes”, “ReAct”, “function calling” — são variações em cima dessa estrutura.

A anatomia de uma chamada com tools

A API da Anthropic (e a da OpenAI, com nomes diferentes) expõe esse padrão de forma direta. O fluxo é:

Você  →  [mensagens + descrição das tools]  →  Modelo
Modelo  →  responde tool_use(name, input)  →  Você
Você executa a tool  →  manda tool_result  →  Modelo
Modelo  →  responde texto final (end_turn)

O modelo nunca executa nada — ele só descreve o que quer fazer. Quem executa é o seu código. Isso é fundamental: o agente é seu, o LLM é só o tomador de decisão.

Construindo um agente mínimo em Ruby puro

Vamos construir um agente que sabe duas coisas:

• current_time — retorna a hora atual.
• read_file — lê um arquivo do disco.

Sem gem anthropic, sem Rails. Para a chamada HTTP, vamos usar a HTTParty — uma gem clássica do ecossistema Ruby que deixa o cliente bem mais enxuto que net/http puro.

gem install httparty

Estrutura

mini_agent/
├── lib/
│   ├── agent.rb       # o loop
│   ├── client.rb      # cliente HTTP da API
│   └── tools.rb       # implementação das ferramentas
└── bin/agent          # executável

O cliente HTTP

# lib/client.rb
require "httparty"

class Client
  include HTTParty

  base_uri "https://api.anthropic.com"
  format   :json

  MODEL = "claude-sonnet-4-6"

  def initialize(api_key: ENV.fetch("ANTHROPIC_API_KEY"))
    @headers = {
      "x-api-key"         => api_key,
      "anthropic-version" => "2023-06-01",
      "content-type"      => "application/json"
    }
  end

  def call(messages, tools)
    body = {
      model:      MODEL,
      max_tokens: 1024,
      tools:      tools,
      messages:   messages
    }

    self.class.post("/v1/messages", headers: @headers, body: body.to_json).parsed_response
  end
end

A HTTParty resolve três chatices de uma vez: parseia o JSON da resposta automaticamente (parsed_response), aceita base_uri para deixar as rotas curtas, e expõe post/get/put como métodos de classe. O cliente inteiro cabe em pouco mais de 20 linhas.

As ferramentas

# lib/tools.rb
module Tools
  DEFINITIONS = [
    {
      name:        "current_time",
      description: "Retorna a data e hora atual no fuso de São Paulo.",
      input_schema: { type: "object", properties: {} }
    },
    {
      name:        "read_file",
      description: "Lê o conteúdo de um arquivo de texto local.",
      input_schema: {
        type: "object",
        properties: {
          path: { type: "string", description: "Caminho do arquivo" }
        },
        required: ["path"]
      }
    }
  ].freeze

  module_function

  def run(name, input)
    case name
    when "current_time" then Time.now.strftime("%Y-%m-%d %H:%M:%S %z")
    when "read_file"    then File.read(input.fetch("path"))
    else                     "tool desconhecida: #{name}"
    end
  rescue => e
    "erro: #{e.message}"
  end
end

A DEFINITIONS é o que o modelo enxerga — ele lê o description para decidir quando usar cada tool. O run é o despachante: recebe o nome e os argumentos que o modelo pediu, executa, devolve uma string.

O rescue é proposital: se a tool falhar, o erro vira input para o modelo, que normalmente consegue se recuperar (tentar outro caminho, pedir mais informação, desistir educadamente).

O loop

O coração do agente. Com comentários explicando cada passo:

# lib/agent.rb
require_relative "client"
require_relative "tools"

class Agent
  MAX_ITERATIONS = 10

  def initialize
    @client   = Client.new
    @messages = []
  end

  def ask(prompt)
    @messages << { role: "user", content: prompt }

    MAX_ITERATIONS.times do
      response = @client.call(@messages, Tools::DEFINITIONS)
      @messages << { role: "assistant", content: response["content"] }

      return final_text(response) if response["stop_reason"] == "end_turn"

      tool_results = response["content"]
        .select { |block| block["type"] == "tool_use" }
        .map    { |block| execute(block) }

      @messages << { role: "user", content: tool_results }
    end

    "[limite de iterações atingido]"
  end

  private

  def execute(block)
    output = Tools.run(block["name"], block["input"])
    {
      type:        "tool_result",
      tool_use_id: block["id"],
      content:     output.to_s
    }
  end

  def final_text(response)
    response["content"]
      .select { |block| block["type"] == "text" }
      .map    { |block| block["text"] }
      .join("\n")
  end
end

Três coisas merecem atenção aqui:

• O histórico inteiro vai junto a cada chamada. O LLM não tem memória; quem mantém o estado é o array @messages.
• tool_use_id precisa bater. Cada tool_use que o modelo emite tem um ID único, e o tool_result correspondente precisa referenciar esse mesmo ID — é assim que o modelo associa pergunta e resposta.
• MAX_ITERATIONS é um cinto de segurança. Sem ele, um modelo confuso pode te custar caro. Sempre tenha um teto.

O executável

#!/usr/bin/env ruby
# bin/agent
$LOAD_PATH.unshift(File.expand_path("../lib", __dir__))
require "agent"

agent = Agent.new
puts agent.ask(ARGV.join(" "))

chmod +x bin/agent
export ANTHROPIC_API_KEY="sk-ant-..."
bin/agent "Que horas são agora? E me diga o que tem no Gemfile."

Saída esperada (algo nessa linha):

Agora são 2026-05-11 14:23:07 -0300.

O Gemfile contém as dependências do projeto: jekyll na versão 4.4.1,
o tema minima, e plugins como jekyll-feed e jekyll-seo-tag.

Por baixo dos panos, o que aconteceu:

1. O modelo recebeu a pergunta e decidiu chamar current_time.
2. Você executou e devolveu o resultado.
3. O modelo decidiu chamar read_file com path: "Gemfile".
4. Você leu o arquivo e devolveu o conteúdo.
5. O modelo escreveu a resposta final em texto e marcou end_turn.

Tudo isso em uma única chamada agent.ask.

O que esse exemplo deixa de fora (de propósito)

Para manter o foco, o agente acima ignora algumas coisas que você vai querer em produção:

• Streaming — a resposta vem inteira, em vez de chegar token a token.
• Persistência de conversa — o histórico mora em memória e morre com o processo.
• Validação de input das tools — o modelo pode mandar argumentos malformados; aqui só confiamos.
• Custo e tokens — não há contagem nem limite de gasto.
• Permissões — o read_file lê qualquer arquivo do sistema. Em um agente real, você precisa de um sandbox.

Cada um desses itens vira um post separado. O ponto aqui é mostrar que um agente de IA, em sua forma mais essencial, cabe em umas 60 linhas de Ruby.

Resumo

Agente de IA não é mágica — é um padrão arquitetural simples em volta de um LLM. Uma vez que o loop está claro na sua cabeça, o resto (memória de longo prazo, multi-agentes, MCP, RAG) são camadas que você adiciona conforme o problema pede. Mas tudo começa aqui: um modelo, algumas ferramentas, um loop.

Considere o seguinte cenário:

Você precisa construir uma aplicação em Ruby puro (sem Rails, sem Sinatra) que receba payloads JSON de diversos fornecedores (cada um com sua própria estrutura de dados) representando o mesmo conceito de domínio — por exemplo, um ticket de viagem. A aplicação deve identificar automaticamente de qual fornecedor o payload veio e tratá-lo de forma uniforme dentro do sistema.

Esse tipo de problema é interessante porque ele não é sobre Ruby idiomático em si, mas sim sobre escolher abstrações e aplicar design patterns clássicos sem cair em overengineering.

Estrutura do projeto

ticket_normalizer/
├── lib/
│   ├── entrypoint.rb        # carrega tudo
│   ├── ticket.rb            # value object normalizado
│   ├── parser.rb            # fábrica que escolhe o adapter
│   └── adapters/
│       ├── base.rb          # interface comum
│       ├── alpha.rb         # fornecedor A
│       └── beta.rb          # fornecedor B
├── test/
│   ├── test_helper.rb
│   └── parser_test.rb
├── payloads/
│   ├── alpha.json
│   └── beta.json
└── bin/normalize            # script executável

Três pastas, uma responsabilidade cada: lib/ é o código, test/ é a verificação, payloads/ são os exemplos para testar manualmente. O bin/normalize mostra como o consumidor usa a biblioteca.

Design patterns aplicados

A solução combina três patterns. Cada um resolve uma responsabilidade específica.

1. Adapter Pattern

O que é: o Adapter converte a interface de uma classe em outra interface esperada pelo cliente. Ele traduz “dialetos” diferentes para uma linguagem comum.

Por que aqui: cada fornecedor envia o ticket com chaves diferentes e às vezes unidades diferentes (preço em reais vs. centavos, datas em ISO 8601 vs. timestamp). Em vez de espalhar if vendor == :alpha pelo código, isolamos cada tradução em uma classe própria.

Interface base — define o contrato que todo adapter precisa cumprir:

# lib/adapters/base.rb
module Adapters
  class Base
    def self.matches?(payload) = raise NotImplementedError

    def initialize(payload) = @payload = payload

    def to_ticket = raise NotImplementedError

    private attr_reader :payload
  end
end

Dois métodos importantes:

• .matches?(payload) — heurística de detecção: presença de uma chave única, valor de um campo provider, formato de um ID etc.
• #to_ticket — converte o payload bruto em um Ticket normalizado.

Adapters concretos:

# lib/adapters/alpha.rb
module Adapters
  class Alpha < Base
    def self.matches?(payload) = payload.key?("alpha_ticket_id")

    def to_ticket
      Ticket.new(
        external_id:    payload["alpha_ticket_id"],
        passenger_name: payload.dig("passenger", "full_name"),
        origin:         payload.dig("trip", "from"),
        destination:    payload.dig("trip", "to"),
        departure_at:   Time.parse(payload["departure_time"]),
        price_cents:    (payload["price"].to_f * 100).round,
        currency:       payload["currency"],
        vendor:         "alpha"
      )
    end
  end
end

# lib/adapters/beta.rb
module Adapters
  class Beta < Base
    def self.matches?(payload) = payload["source"] == "beta_rail"

    def to_ticket
      data = payload["data"]
      Ticket.new(
        external_id:    data["id"],
        passenger_name: data["customer_name"],
        origin:         data["origin_station"],
        destination:    data["destination_station"],
        departure_at:   Time.at(data["departs_at_unix"]),
        price_cents:    data["price_in_cents"],
        currency:       data["currency_iso"],
        vendor:         "beta"
      )
    end
  end
end

Toda a complexidade do payload original fica encapsulada dentro de cada adapter. O resto do sistema só conhece Ticket.

2. Factory Pattern

O que é: a Factory é responsável por decidir e instanciar o objeto correto para uma situação. Aqui ela resolve a pergunta: “dado este payload, qual adapter eu uso?”

Por que aqui: centralizar a lógica de seleção em um único lugar evita que o cliente da biblioteca conheça todos os adapters. Adicionar um novo fornecedor não toca código existente — é o Open/Closed Principle na prática.

# lib/parser.rb
require "json"

class Parser
  ADAPTERS = [Adapters::Alpha, Adapters::Beta].freeze
  UnknownVendorError = Class.new(StandardError)

  def self.parse(json)
    payload = JSON.parse(json)
    adapter = ADAPTERS.find { |a| a.matches?(payload) }
    raise UnknownVendorError unless adapter

    adapter.new(payload).to_ticket
  end
end

Detalhes que valem destacar:

• ADAPTERS.freeze comunica que aquela lista é o ponto de configuração do sistema.
• find em vez de select: o primeiro adapter que casa vence. A ordem da lista importa quando há heurísticas sobrepostas.
• Erro tipado permite ao chamador fazer rescue UnknownVendorError específico.

3. Value Object Pattern

O que é: um Value Object é um objeto imutável definido pelos seus atributos, não por uma identidade. Dois Ticket com os mesmos atributos são considerados iguais.

Por que aqui: o Ticket normalizado é dado, não comportamento. Usar Data.define deixa isso explícito e bloqueia mutação acidental.

# lib/ticket.rb
Ticket = Data.define(
  :external_id, :passenger_name, :origin, :destination,
  :departure_at, :price_cents, :currency, :vendor
) do
  def price = price_cents / 100.0
end

Data.define (Ruby 3.2+) entrega de graça: construtor com argumentos nomeados, imutabilidade real, igualdade por atributos e to_h. Em versões anteriores, a alternativa é Struct.new(..., keyword_init: true).

Entrypoint e execução

O entry point só carrega as dependências na ordem certa:

# lib/entrypoint.rb
require_relative "ticket"
require_relative "adapters/base"
require_relative "adapters/alpha"
require_relative "adapters/beta"
require_relative "parser"

O bin/normalize consome a biblioteca via stdin:

#!/usr/bin/env ruby
$LOAD_PATH.unshift(File.expand_path("../lib", __dir__))
require "entrypoint"

puts Parser.parse(ARGF.read).to_h.inspect

chmod +x bin/normalize
bin/normalize < payloads/alpha.json
bin/normalize < payloads/beta.json

Testes com Minitest

Minitest está na stdlib desde o Ruby 1.9 — zero dependências externas. O estilo spec deixa a leitura próxima do RSpec.

# test/test_helper.rb
$LOAD_PATH.unshift(File.expand_path("../lib", __dir__))
require "minitest/autorun"
require "minitest/spec"
require "entrypoint"

# test/parser_test.rb
require_relative "test_helper"

describe Parser do
  it "normaliza payload alpha" do
    ticket = Parser.parse(File.read("payloads/alpha.json"))
    _(ticket.vendor).must_equal "alpha"
    _(ticket.price_cents).must_be_kind_of Integer
  end

  it "normaliza payload beta" do
    ticket = Parser.parse(File.read("payloads/beta.json"))
    _(ticket.vendor).must_equal "beta"
  end

  it "rejeita payload desconhecido" do
    _ { Parser.parse('{"foo":"bar"}') }.must_raise Parser::UnknownVendorError
  end
end

Rodar os testes sem nenhuma ferramenta extra:

ruby -Ilib -Itest test/parser_test.rb

Decisões de projeto

• Por que matches? em vez de um campo vendor no payload? Porque nem sempre o fornecedor envia esse campo. A heurística de detecção é responsabilidade do adapter.
• Como adicionar um novo fornecedor? Cria a classe em lib/adapters/, adiciona o require_relative no entrypoint e inclui na constante ADAPTERS. Zero alteração no código existente.
• Por que não usar dry-struct, ActiveModel? O foco é Ruby puro. A stdlib já oferece Data, JSON e Minitest — o suficiente para o escopo.

Resumo

Essa combinação resolve o problema com alta coesão (cada classe tem um propósito) e alta extensibilidade (novos fornecedores não tocam código existente). A elegância da solução não está em ser sofisticada — está em ser proporcional ao problema.

Começando a estudar Inteligência Artificial recentemente por motivos de mestrado e pós-graduação, rapidamente percebi que frameworks como PyTorch e TensorFlow abstraem muita coisa — mas essa abstração cobra um preço. Sem entender a matemática por trás, você consegue rodar modelos, mas não consegue debugar, otimizar ou criar nada novo.

Este post é um mapa dos principais conceitos matemáticos que sustentam IA, Machine Learning e Deep Learning. Não é um curso completo de cada tópico, mas sim uma explicação de o que é, por que importa e onde aparece na prática.

Para tornar o conteúdo mais prático, o Claude me acompanha ao longo do post com sugestões de exercícios e referências para cada tópico.

1. Álgebra Linear

A álgebra linear é a linguagem fundamental da IA. Praticamente tudo — dados, pesos, transformações — é representado como vetores e matrizes.

Vetores e Matrizes

Um vetor é uma lista ordenada de números. Uma imagem 28x28 pixels pode ser representada como um vetor de 784 elementos. Uma matriz é uma tabela de números — os pesos de uma rede neural são armazenados em matrizes.

Onde aparece: representação de dados, embeddings de texto, imagens como tensores.

Multiplicação de Matrizes

A operação mais executada em redes neurais. Quando um input passa por uma camada, o que acontece é uma multiplicação de matrizes seguida de uma função de ativação.

output = activation(W · input + b)

Onde W é a matriz de pesos e b é o vetor de bias.

Onde aparece: forward pass de qualquer rede neural, camadas densas, convoluções.

Transposição e Inversão

Transpor uma matriz (trocar linhas por colunas) é usado constantemente em operações de gradiente. A inversão aparece em soluções analíticas como regressão linear.

Onde aparece: backpropagation, regressão linear, PCA.

Autovalores e Autovetores

Um autovetor de uma matriz é um vetor que, quando multiplicado pela matriz, muda apenas de escala (não de direção). O fator de escala é o autovalor.

Onde aparece: PCA (Principal Component Analysis), análise espectral, estabilidade de redes recorrentes.

Espaços Vetoriais e Transformações Lineares

Entender que dados vivem em espaços de alta dimensão e que redes neurais aplicam transformações sucessivas nesses espaços é fundamental para intuir como modelos “aprendem”.

Onde aparece: embeddings (Word2Vec, BERT), redução de dimensionalidade, atenção em Transformers.

2. Cálculo

O cálculo é o motor do aprendizado. Sem ele, não existe treinamento de modelos.

Derivadas

A derivada mede a taxa de mudança de uma função. No contexto de ML, ela responde: “se eu ajustar este peso um pouquinho, quanto a perda (loss) muda?”

Onde aparece: toda otimização de modelos.

Derivadas Parciais

Quando a função tem muitas variáveis (e um modelo pode ter bilhões), calculamos derivadas parciais — a derivada em relação a cada variável individualmente.

Onde aparece: cálculo de gradientes, backpropagation.

Regra da Cadeia

A regra da cadeia permite calcular a derivada de funções compostas. Uma rede neural é basicamente uma composição de funções, então a regra da cadeia é o que torna o backpropagation possível.

dL/dw = dL/dy · dy/dz · dz/dw

Onde aparece: backpropagation — é literalmente a base matemática de como redes neurais aprendem.

Gradiente

O gradiente é o vetor de todas as derivadas parciais. Ele aponta na direção de maior crescimento da função. Para minimizar o erro, andamos na direção oposta ao gradiente.

Onde aparece: gradient descent, SGD, Adam, e todos os otimizadores.

Integrais

Menos usadas diretamente no dia a dia de ML, mas essenciais para entender distribuições de probabilidade, funções de densidade e normalização.

Onde aparece: modelos probabilísticos, VAEs (Variational Autoencoders), teoria da informação.

3. Probabilidade e Estatística

Se álgebra linear é a linguagem e cálculo é o motor, probabilidade é a lógica da IA. Quase todo modelo lida com incerteza.

Probabilidade Básica

Onde aparece: classificadores, modelos generativos, qualquer predição com incerteza.

Teorema de Bayes

P(A|B) = P(B|A) · P(A) / P(B)

O teorema de Bayes permite atualizar crenças com base em evidências. É a base de classificadores Naive Bayes e de toda a inferência bayesiana.

Onde aparece: Naive Bayes, filtros de spam, redes bayesianas, inferência probabilística.

Distribuições de Probabilidade

As mais importantes para IA:

• Normal (Gaussiana): inicialização de pesos, ruído, normalização
• Bernoulli: classificação binária, dropout
• Categórica/Multinomial: classificação multiclasse, softmax
• Uniforme: inicialização, amostragem aleatória

Onde aparece: em praticamente tudo — de inicialização de pesos a modelos generativos.

Valor Esperado e Variância

O valor esperado é a “média ponderada” dos resultados possíveis. A variância mede o quanto os valores se dispersam. Controlar a variância dos gradientes é crucial para treinar modelos estáveis.

Onde aparece: funções de perda, normalização (batch norm, layer norm), análise de convergência.

Maximum Likelihood Estimation (MLE)

A ideia de encontrar os parâmetros que maximizam a probabilidade dos dados observados. É a justificativa teórica por trás de muitas funções de perda.

Onde aparece: regressão logística, cross-entropy loss, modelos de linguagem.

4. Otimização

O treinamento de qualquer modelo de ML é, no fundo, um problema de otimização: encontrar os parâmetros que minimizam uma função de erro.

Gradient Descent

O algoritmo mais fundamental de ML. A cada passo, calculamos o gradiente da função de perda e ajustamos os pesos na direção oposta.

w = w - learning_rate * gradiente

Onde aparece: treinamento de qualquer modelo.

Stochastic Gradient Descent (SGD)

Em vez de calcular o gradiente usando todos os dados, usamos mini-batches aleatórios. Isso torna o treinamento viável para datasets grandes e adiciona ruído que ajuda a escapar de mínimos locais.

Onde aparece: treinamento de redes neurais em escala.

Otimizadores Avançados (Adam, RMSprop, AdaGrad)

Variações do SGD que adaptam a taxa de aprendizado para cada parâmetro individualmente. Adam é o mais popular e combina momentum com taxas adaptativas.

Onde aparece: praticamente todo treinamento moderno de deep learning.

Funções de Perda (Loss Functions)

A função que o otimizador tenta minimizar. As mais comuns:

• MSE (Mean Squared Error): regressão
• Cross-Entropy: classificação
• Binary Cross-Entropy: classificação binária

Escolher a função de perda certa é tão importante quanto a arquitetura do modelo.

Convexidade e Mínimos Locais

Uma função convexa tem um único mínimo — fácil de otimizar. Redes neurais têm funções de perda não-convexas com muitos mínimos locais. Entender isso explica por que técnicas como momentum e learning rate scheduling existem.

Onde aparece: design de treinamento, debugging de convergência.

5. Teoria da Informação

Conceitos da teoria da informação aparecem em funções de perda, compressão de modelos e avaliação de qualidade.

Entropia

Mede a quantidade de “surpresa” ou incerteza em uma distribuição. Uma distribuição uniforme tem entropia máxima; uma distribuição concentrada em um valor tem entropia baixa.

Onde aparece: cross-entropy loss, árvores de decisão, avaliação de modelos de linguagem.

Cross-Entropy

Mede a diferença entre duas distribuições de probabilidade. Quando usamos como função de perda, estamos medindo o quão diferente a predição do modelo é da distribuição real.

Onde aparece: a função de perda mais usada em classificação e modelos de linguagem.

KL Divergence

Onde aparece: VAEs, destilação de modelos, RLHF (o fine-tuning por feedback humano).

6. Geometria e Topologia (noções)

Distâncias e Similaridade

• Distância Euclidiana: distância “em linha reta” entre dois pontos
• Similaridade do Cosseno: mede o ângulo entre dois vetores, ignorando magnitude
• Distância de Manhattan: soma das diferenças absolutas

Onde aparece: K-NN, clustering, busca por similaridade em embeddings, RAG.

Espaços de Alta Dimensão

A intuição humana falha em dimensões altas. Fenômenos como a “maldição da dimensionalidade” — onde os dados ficam esparsos e distâncias perdem significado — são reais e afetam o design de modelos.

Onde aparece: embeddings, redução de dimensionalidade, regularização.

Roteiro de estudo sugerido

Para quem quer construir uma base sólida, sugiro esta ordem:

1. Álgebra Linear — comece aqui. Vetores, matrizes, multiplicação
2. Cálculo — derivadas, regra da cadeia, gradientes
3. Probabilidade — distribuições, Bayes, MLE
4. Otimização — gradient descent e variações
5. Teoria da Informação — entropia, cross-entropy

Recursos recomendados

• Mathematics for Machine Learning (Deisenroth, Faisal, Ong) — livro gratuito online, cobre tudo com foco em ML
• 3Blue1Brown (YouTube) — as melhores visualizações de álgebra linear e cálculo que existem
• Khan Academy — para revisar fundamentos que ficaram enferrujados
• Deep Learning Book (Goodfellow, Bengio, Courville) — capítulos 2-4 cobrem a matemática essencial

Conclusão

Você não precisa ser matemático para trabalhar com IA, mas precisa ser amigo da matemática. Entender esses conceitos transforma a experiência de “usar frameworks como caixa preta” para “entender o que está acontecendo e por quê”.

No mestrado, percebi que a maioria dos papers e técnicas novas são variações criativas desses mesmos fundamentos. Quem domina a base matemática consegue ler papers, implementar arquiteturas novas e — mais importante — saber por que algo funciona ou não funciona.

Nos últimos meses, o Claude Code se tornou uma das ferramentas mais presentes no meu fluxo de trabalho como desenvolvedor. Diferente de assistentes que funcionam dentro de IDEs com autocomplete, o Claude Code roda direto no terminal — e isso muda completamente a forma como eu interajo com ele.

Neste post, vou compartilhar como está meu setup atual, quais plugins uso, como configurei permissões e a status line customizada que me ajuda a monitorar o contexto da conversa.

O que é o Claude Code?

O Claude Code é a CLI oficial da Anthropic para o Claude. Ele funciona como um agente de engenharia de software que pode:

• Ler, criar e editar arquivos no seu projeto
• Executar comandos no terminal
• Pesquisar na web e buscar documentação
• Navegar pelo codebase com ferramentas como Glob e Grep
• Criar commits, abrir PRs e interagir com o GitHub
• Lançar sub-agentes para tarefas paralelas

A versão que estou usando atualmente é a 2.1.61.

Minha configuração (settings.json)

O coração da configuração fica em ~/.claude/settings.json. Aqui está o meu:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  },
  "permissions": {
    "allow": [
      "Bash(bin/rails test:*)",
      "Bash(bin/rails db:migrate*)",
      "Bash(bundle exec rubocop*)",
      "Bash(bun:*)",
      "Bash(foreman start)",
      "Bash(git:*)",
      "WebSearch",
      "WebFetch(domain:api.stripe.com)",
      "WebFetch(domain:qbench.net)",
      "WebFetch(domain:github.com)"
    ]
  },
  "enabledPlugins": {
    "compound-engineering@every-marketplace": true,
    "ralph-loop@claude-plugins-official": true
  },
  "skipDangerousModePermissionPrompt": true
}

Permissões

Uma das partes mais importantes do setup são as permissões pré-aprovadas. Sem elas, o Claude Code pede confirmação para cada comando executado no terminal, o que pode ser bem lento no fluxo de trabalho. Eu configurei permissões para:

• Rails: rodar testes (bin/rails test:*) e migrações (bin/rails db:migrate*)
• Rubocop: executar o linter livremente
• Bun: gerenciamento de pacotes JavaScript
• Foreman: iniciar o servidor de desenvolvimento
• Git: todos os comandos git
• Web: pesquisa na web e fetch de domínios específicos (Stripe, GitHub)

Isso me dá um equilíbrio entre produtividade e segurança — o Claude pode executar comandos comuns sem pedir permissão, mas qualquer coisa fora desse escopo ainda precisa da minha aprovação.

Agent Teams (experimental)

A variável CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS habilita o recurso de times de agentes. Isso permite que o Claude Code lance múltiplos agentes que trabalham em paralelo, se comunicam entre si e dividem tarefas complexas. É útil para projetos maiores onde diferentes partes do trabalho podem ser feitas simultaneamente.

Agent Teams + tmux: paralelismo real

Uma das combinações mais poderosas que descobri é usar Agent Teams com tmux. A ideia é simples: em vez de rodar tudo em um único painel do terminal, eu abro uma sessão tmux com múltiplos painéis e deixo cada agente trabalhando de forma visível.

Na prática, o fluxo funciona assim:

1. Abro uma sessão tmux e divido a tela em painéis
2. No painel principal, inicio o Claude Code como líder do time
3. Quando ele lança sub-agentes, cada um aparece em seu próprio processo
4. Consigo acompanhar visualmente o que cada agente está fazendo em tempo real

# Criar sessão tmux com layout para agent teams
tmux new-session -s claude -d
tmux split-window -h
tmux split-window -v
tmux select-pane -t 0
tmux split-window -v
tmux attach -t claude

Com esse layout de 4 painéis, consigo monitorar o agente principal e até 3 sub-agentes simultaneamente. É como ter um time de desenvolvedores trabalhando na sua tela.

O que torna isso prático:

• Visibilidade: vejo exatamente o que cada agente está fazendo, sem precisar esperar o resultado final
• Controle: se um agente tomar um caminho errado, posso identificar rapidamente
• Produtividade: enquanto um agente pesquisa documentação, outro pode estar editando código e um terceiro rodando testes

Um exemplo real: ao importar e traduzir 20 posts para este blog, o Claude Code dividiu o trabalho entre 3 agentes — cada um traduziu um lote de posts em paralelo. O que levaria vários minutos sequencialmente foi resolvido em uma fração do tempo.

Para quem já usa tmux no dia a dia, a integração é natural. E para quem não usa, esse é um ótimo motivo para começar.

Plugins

Atualmente uso dois plugins:

Compound Engineering (Every Marketplace)

O plugin compound-engineering adiciona uma grande quantidade de agentes especializados e skills ao Claude Code. Alguns que uso com frequência:

• Agentes de review: revisão de código com diferentes perspectivas (Rails, segurança, performance, arquitetura)
• Design Iterator: para refinar interfaces iterativamente
• Framework Docs Researcher: busca documentação atualizada de libraries
• Context7: integração com documentação e code examples atualizados de qualquer library

Ralph Loop

O plugin ralph-loop permite criar loops autônomos onde o Claude Code continua trabalhando em uma tarefa sem precisar de input constante. Útil para tarefas mais longas.

Status Line customizada

Uma das customizações que mais gosto é a status line no terminal. Ela mostra em tempo real:

• O modelo sendo usado (Opus, Sonnet, Haiku)
• O diretório do projeto atual
• O branch do git ativo
• Uma barra de progresso do contexto utilizado
• O horário atual

A configuração fica no settings.json, na chave statusLine:

{
  "statusLine": {
    "type": "command",
    "command": "<conteúdo do script abaixo>"
  }
}

O comando em si é um shell script. Para facilitar a leitura, aqui está ele formatado:

input=$(cat)

# Extrai informações do JSON de input
model=$(echo "$input" | jq -r '.model.display_name')
cwd=$(echo "$input" | jq -r '.workspace.current_dir')
dir_name=$(basename "$cwd")

# Detecta branch do git
git_info=""
if git -C "$cwd" rev-parse --git-dir > /dev/null 2>&1; then
  branch=$(git -C "$cwd" --no-optional-locks branch --show-current 2>/dev/null || echo "detached")
  git_info=" - 🌿 ${branch}"
fi

# Monta barra de progresso do contexto
progress_bar=""
remaining=$(echo "$input" | jq -r '.context_window.remaining_percentage // empty')
if [ -n "$remaining" ]; then
  used=$(echo "$input" | jq -r '.context_window.used_percentage // 0')
  used_int=${used%.*}
  bar_length=20
  filled=$((used_int * bar_length / 100))
  empty=$((bar_length - filled))
  bar=""
  for ((i=0; i<filled; i++)); do bar="${bar}█"; done
  for ((i=0; i<empty; i++)); do bar="${bar}░"; done
  progress_bar=$(printf "[\033[32m%s\033[0m] %d%%" "$bar" "$used_int")
fi

time=$(date +%H:%M:%S)

# Output: linha 1 = modelo + diretório + branch
#         linha 2 = barra de contexto + horário
printf "%s - 📁 %s%s\n%s - %s" \
  "$model" "$dir_name" "$git_info" "$progress_bar" "$time"

O Claude Code passa um JSON via stdin com informações sobre o modelo, diretório e uso de contexto. O script lê esse JSON com jq, monta uma barra visual e exibe tudo na status line.

A barra de contexto é especialmente útil: conforme a conversa cresce, o Claude Code consome mais da janela de contexto. Quando a barra está quase cheia, sei que é hora de iniciar uma nova conversa ou comprimir o contexto.

Como uso no dia a dia

Meu fluxo típico com o Claude Code:

1. Abro o terminal no diretório do projeto e digito claude
2. Descrevo a tarefa em linguagem natural — pode ser em português ou inglês
3. Reviso as mudanças que ele propõe antes de aprovar
4. Peço commits e PRs quando estou satisfeito com o resultado
5. Uso /help quando preciso lembrar de funcionalidades

Dicas práticas

• Seja específico: quanto mais contexto você der, melhor o resultado
• Use o modo plan para tarefas complexas — ele analisa o codebase antes de fazer mudanças
• Aproveite os sub-agentes: para pesquisa ou tarefas paralelas, o Claude Code pode lançar agentes especializados
• Configure permissões: poupa muito tempo não ter que aprovar cada git status
• Monitore o contexto: conversas muito longas perdem qualidade. Comece uma nova quando necessário

Conclusão

O Claude Code mudou significativamente como eu trabalho. A combinação de acesso ao terminal, leitura do codebase e capacidade de executar comandos faz dele muito mais do que um chatbot — é um par de programação que realmente entende o projeto.

Se você é desenvolvedor e ainda não experimentou, recomendo fortemente. E se já usa, invista tempo configurando as permissões e a status line — faz toda a diferença na produtividade.

Estou criando alguns posts de estudos particulares com ajuda de IA e decidi começar a compartlhar um pouco do que tenho aprendido utilizando IA.

Processos, Threads, Fibers e ActiveSupport::CurrentAttributes

Quem trabalha com Rails há algum tempo inevitavelmente esbarra em conceitos como Current.user, concorrência, vazamento de contexto e comportamentos estranhos que só aparecem em produção. Muitas vezes esses problemas são atribuídos a “Rails magic”, quando na verdade eles nascem de um entendimento incompleto sobre como o código Rails é executado em tempo de execução.

Este texto tem um objetivo simples: explicar, de forma progressiva e conectada, como processos, threads e fibers se relacionam no Rails moderno e como o framework usa essa estrutura para compartilhar contexto com segurança através do ActiveSupport::CurrentAttributes.

Processos: o primeiro nível de isolamento

Um processo é a unidade mais isolada de execução fornecida pelo sistema operacional. Quando um processo é criado, ele recebe seu próprio espaço de memória, seu próprio identificador (PID) e não compartilha variáveis, objetos ou estado com outros processos.

No contexto de Rails, isso significa que cada worker de um servidor web em modo cluster (como Puma) ou cada processo do Sidekiq roda em um processo separado. Mesmo que dois processos estejam executando o mesmo código Rails, eles não enxergam a memória um do outro. Se um processo altera um objeto em memória, os demais processos não sabem que isso aconteceu.

Uma boa analogia é pensar no processo como uma casa: tudo o que está dentro dela pertence apenas àquela casa. Outras casas podem ser idênticas, mas não compartilham móveis.

Essa característica é o motivo pelo qual nenhum estado em memória — incluindo CurrentAttributes — pode atravessar processos. Se algo precisa ser compartilhado entre processos, ele precisa ser persistido em um banco, cache externo ou fila.

Threads: concorrência dentro do mesmo processo

Dentro de um processo, o sistema operacional permite a criação de threads. Uma thread é um fluxo de execução independente, mas que compartilha a mesma memória do processo que a criou.

No Rails, cada request é atribuído a uma thread do servidor web. Em um processo Puma com múltiplas threads, vários requests podem estar sendo processados simultaneamente, todos compartilhando as mesmas classes, constantes e heap de memória.

A grande diferença entre processo e thread é que threads compartilham memória, mas não compartilham execução. Cada thread tem sua própria stack, seu próprio contador de instruções e seu próprio Thread.current. Além disso, threads são preemptivas: o sistema operacional pode interromper uma thread a qualquer momento para dar espaço a outra.

Uma analogia útil é pensar na thread como pessoas andando dentro da mesma casa. Elas compartilham os mesmos móveis, mas cada uma tem sua própria linha de pensamento e pode ser interrompida no meio de uma ação.

Essa característica é essencial para entender por que o Rails não pode usar variáveis globais simples para armazenar dados como current_user. Em um ambiente multi-thread, isso causaria vazamento de dados entre requests.

Fibers: concorrência cooperativa e previsível

Fibers são frequentemente confundidas com threads, mas elas resolvem um problema diferente. Uma fiber é uma unidade leve de execução gerenciada pelo próprio Ruby, não pelo sistema operacional. Diferente das threads, fibers não são preemptivas: elas só pausam quando o código explicitamente permite.

Fibers vivem dentro de uma thread e nunca executam em paralelo. O que elas permitem é que múltiplas operações façam progresso enquanto aguardam I/O, sem bloquear a thread inteira. Isso é especialmente útil para servidores web e sistemas que lidam com muitas operações de rede.

No Rails moderno, fibers são usadas para suportar I/O assíncrono, ActionCable, Turbo Streams e outras formas de concorrência cooperativa. O modelo real de execução passa a ser: um processo contendo várias threads, e cada thread podendo alternar entre múltiplas fibers.

Uma boa analogia é imaginar uma thread como um trilho de trem e fibers como vagões. Apenas um vagão anda por vez, mas vários podem se revezar no mesmo trilho de forma organizada e previsível.

O ciclo de vida de um request no Rails

Sistema Operacional
 └── Processo (PID)
      ├── Thread 1
      ├── Thread 2
      ├── Thread 3
      └── ...

Com esses conceitos em mente, fica mais fácil entender o request lifecycle no Rails. Quando um request chega ao servidor web, ele é atribuído a uma thread específica. Todo o código do Rails — middlewares, controllers, models, services e callbacks — executa dentro dessa thread.

Durante a execução, o Rails pode suspender e retomar a execução usando fibers, especialmente quando há operações de I/O. Mesmo assim, o contexto do request permanece associado à execução correta.

Esse detalhe é fundamental: todo request Rails sempre tem uma thread associada, mesmo quando fibers entram em cena. Fibers não eliminam threads; elas apenas permitem um uso mais eficiente delas.

ActiveSupport::CurrentAttributes: contexto atrelado à execução

O ActiveSupport::CurrentAttributes existe para resolver um problema prático: como disponibilizar dados de contexto — como usuário atual, conta, fuso horário ou request ID — em qualquer camada da aplicação sem passar parâmetros por toda parte e sem usar variáveis globais perigosas?

A solução do Rails é tratar contexto como algo associado à execução, não a objetos específicos. Internamente, o Rails armazena esses dados em um storage ligado à thread e, no Rails moderno, também integrado ao contexto de fibers por meio do ActiveSupport::ExecutionContext.

Quando você define Current.user = current_user no início do request, esse valor fica disponível em qualquer ponto do código que esteja executando naquele mesmo contexto. Models, services e callbacks conseguem acessá-lo porque estão rodando dentro da mesma thread (e fibers associadas).

Esse contexto é automaticamente limpo ao final do request. Isso é essencial porque threads são reutilizadas. Sem esse reset, dados de um request poderiam vazar para o próximo.

Até onde vai o contexto

É importante entender os limites desse mecanismo. CurrentAttributes não atravessa processos. Ele também não sobrevive a background jobs, filas ou qualquer fronteira temporal. Quando um job começa, ele roda em outro processo ou thread, com um contexto completamente novo.

Por isso, qualquer dado necessário fora do request lifecycle deve ser passado explicitamente. O Current é uma ferramenta poderosa, mas apenas dentro do escopo correto.

Leituras

O ciclo de vida de uma request por exemplo vive dentro de uma thread. O contexto é preservado no Rails através de ExecutionContext

Conclusão

Entender processos, threads e fibers não é um detalhe acadêmico: é o que permite escrever aplicações Rails previsíveis, seguras e escaláveis. ActiveSupport::CurrentAttributes funciona porque o Rails trata contexto como parte do fluxo de execução, respeitando os limites impostos pelo sistema operacional e pelo Ruby.

Quando esses conceitos estão claros, desaparecem os mistérios do tipo “funciona local, quebra em produção”. O que sobra é arquitetura, concorrência e decisões conscientes — exatamente o tipo de entendimento que diferencia quem apenas usa Rails de quem realmente o domina.

Exploring Kamal (2) and how to deploy Ruby on Rails applications to DigitalOcean (or any other cloud service) using a managed database service, i started testing some configurations/deploy and my idea now is definitely create more posts about Kamal and share more information here in my personal blog about it.

What is Kamal?

The official Kamal website says:

“Kamal offers zero-downtime deploys, rolling restarts, asset bridging, remote builds, accessory service management, and everything else you need to deploy and manage your web app in production with Docker. Originally built for Rails apps, Kamal will work with any type of web app that can be containerized.”

Why i like this?

Honestly i used Capistrano for a long time and i liked that. When I first heard Kamal described as a Capistrano-like tool for deploying containerized applications, I got pretty excited about the idea. But in my view, that’s not the best way to define it. For me, Kamal is a great tool for anyone looking to deploy containerized apps without having to rely on Kubernetes—or who just doesn’t need it.

Things to start understanding Kamal before using it

Kamal is now in version 2, here are some things i think are very important to understand.

• Docker (Containers, Orchestration)
• SSH (SSHKit)
• Reverse proxies (Kamal used Traefik in version 1 but now it uses Kamal-proxy)
• Load balances
• YAML files syntax

Managed databases vs Database container

Using Kamal you can choose adding accessories (containers) or use a managed database service we can find in multiple cloud services like AWS, GCP or DigitalOcean which i’m using right now for my apps.

I actually choose a managed database service because it’s easier to create backups, setup connections and etc, it’s all handled by the cloud service you choose. That’s the reason for me and my small apps i’ve being creating.

The example

When using Ruby on Rails 8, Kamal is by default in your app and you can check some files to see how it works.

• config/deploy.yml
• .kamal/secrets
• .kamal/hooks
• Dockerfile
• bin/docker-entrypoint

And this is my current config/deploy.yml file to deploy an app to Digital Ocean using the Digital Ocean managed database service, off course you need to create the database and droplet first. I added some comments sou you can use the file and understand what’s happening out there.

# Name of the Project
service: nice_project

# Name of the image, by default it will use DockerHub
image: joseanchieta/nice_project

# IP Servers, you can set just one or how many you want
servers:
  web:
    - 192.168.0.1

# Your DockerHub/Other service username
registry:
  username: joseanchieta
  # You can find this variable inside .kamal/secrets
  password:
    - KAMAL_REGISTRY_PASSWORD

# Secrets come from .kamal/secrets.
env:
  secret:
    - RAILS_MASTER_KEY
    - PRODUCTION_DB_HOST
    - KAMAL_REGISTRY_PASSWORD
  clear:
    SOLID_QUEUE_IN_PUMA: true

    # IP or address of the database service, this is an example using
    # Digital Ocean
    # In database.yml >> production you should have something like this:
    # production:
    #   adapter: postgresql
    #   encoding: unicode
    #   pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
    #   database: production_database_name
    #   url: <%= ENV["PRODUCTION_DB_HOST"] %>
    DB_HOST: db-postgresql-nyc3-something123.ondigitalocean.com

# These commands are helpful, you can type in your terminal:
# kamal console
# kamal shell
# kamal logs
aliases:
  console: app exec --interactive --reuse "bin/rails console"
  shell: app exec --interactive --reuse "bash"
  logs: app logs -f
  dbc: app exec --interactive --reuse "bin/rails dbconsole"

volumes:
  - "nice_project:/rails/storage"

asset_path: /rails/public/assets

builder:
  arch: amd64

Um novo horizonte para o que pode ser feito com Rails.

Desde o início dos anúncios sobre Hotwire e Turbo, venho acompanhando e formando minhas opiniões a respeito. Confesso que de primeira, fiquei cético e achei que seria apenas mais uma coisa de Javascript para aprender, eu estava terrivelmente enganado.

Após assistir as palestras do RailsWorld realizado em Berlim no mês passado, percebi de vez que a forma como vejo o ecossistema Rails, mudou muito. Hoje existe um horizonte de possibilidades para criação de aplicações web com Rails com um cardápio grande de opções: Esbuild, ImportMaps, Hotwire, Kamal e etc. Estou bem animado com todas as alternativas que temos e que teremos em breve no ecossistema Rails.

Turbo Native

Há a algum tempo, venho acompanhando o perfil no Twitter (X) do Joe Masilotti, The turbo native guy como ele se auto proclama. Esse era o ponto no qual eu mais duvidava, “aplicativos de celular com Rails?, não me parece uma boa ideia”. Esse pensamento surgiu em mim diante de tantas discussões a respeito de React Native e Flutter, parecem duas torcidas rivais e fervorosas para provar qual a melhor tecnologia.

O Joe foi um dos palestrantes do Rails World e na minha opinião, entregou uma das melhores palestras do evento. Este post basicamente replica e acrescenta algumas considerações ao que foi visto na palestra do Joe. Deixarei o link da palestra ao final deste post e o link para o Twitter do Joe também, vale bastante a pena segui-lo.

Como funciona isso e por que?

Bom, pra quem conhece o conceito de webview em aplicações mobile, não é nada revolucionário. Resumindo de forma muito simples, é um app mobile que exibe um app web. Ou seja, teremos uma aplicação web Rails sendo exibida dentro de um app mobile, neste caso específico iOS.

Já ouvi várias coisas negativas sobre a abordagem de webview, desde que ouvi pela primeira vez sobre ferramentas como Ionic lá em 2014. Concordo com grande parte dos pontos negativos que ouvi naquela época, porém temos de levar em consideração que não estamos mais em 2014 e os devices mudaram muito, principalmente em capacidade de processamento, memória e etc.

Tendo tudo isso em mente, tenho a impressão que estamos entrando em uma nova era do desenvolvimento de software em que as pessoas estão cada vez mais pragmáticas e simplistas, isso faz parte de um conjunto de teorias, pensamentos e opiniões que venho acompanhando e que faz sentido (para mim). Acredito que muito vem dos resultados falhos de overengineering que obtivemos nos últimos anos com separação de back e front, microservices e etc sem que haja de fato um motivo real para aderir a estas técnicas.

Joe cita na palestra um outro exemplo, empresas/pessoas criando apps nativos visando performance e extrair o máximo dos devices sem que haja a necessidade real disso, ou seja, grande parte dos apps mobile não precisam extrair o máximo do aparelho, elas precisam renderizar algumas views, realizar algumas operações de crud e etc. Mais uma vez, estou de acordo com isso e pra mim o uso do Turbo Native faz sentido neste momento.

Criando o projeto

Vamos começar criando um projeto simples em Rails, o intuito do post é criar um app rails e fazer com que o mesmo apareça em um iOS simulator (infelizmente apenas para usuários de Mac, mas sinta-se a vontade para fazer o mesmo para apps Android).

rails new iosapp -T -css tailwind

Vamos adicionar apenas um scaffold ao projeto para que possamos ver o resultado no simulador do iOS.

rails g scaffold Post title body:text

Execute as migrações:

rails db:migrate

Adicione um root_path (root_url) no arquivo routes.rb:

root "posts#index"

Execute o app:

./bin/dev

Agora acesse o seu browser em localhost:3000 e crie alguns posts.

Assim está o meu app no browser após adicionar alguns estilos utilizando Tailwind:

Criando o app iOS

Neste passo é necessário ter o XCode instalado e estar utilizando um Mac. Abra o XCode, no menu principal clique em File, New, Project.

Na caixa de seleção “Choose a template for your new project” selecione iOS » App e clique em Next. Aqui você terá algumas opções para preencher que são obrigatórias, no nosso caso pode desmarcar a opção Include Tests e na caixa de Interface, selecione StoryBoard.

Acrescentando o Turbo Native como dependência do projeto

Clique no menu File novamente, encontre a opção Add Package Dependecies, clique nesta opção e selecione o Turbo Native, caso o Turbo Native não apareça para você, digite a url do github no campo Enter Package URL.

URL: github.com/hotwired/turbo-ios

O único passo necessário por agora é alterar o arquivo swift SceneDelegate que se encontra na árvore de arquivos exibida no Xcode.

O código ficará da seguinte forma:

import Turbo
import WebKit
import UIKit

let rootUrl = URL(string: "http://127.0.0.1:3000/")!

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?
    
    private let navigationController = UINavigationController()

    private lazy var session = {
        let config = WKWebViewConfiguration()
        config.applicationNameForUserAgent = "Turbo Native iOS"
        
       let session = Session(webViewConfiguration: config)
       session.delegate = self
       return session
    }()

    // When the app launches
    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        window?.rootViewController = navigationController
        
        let proposal = VisitProposal(url: rootUrl, options: VisitOptions())
        visit(proposal: proposal)
    }
    
    // 1. Create Screen
    // 2. Push the Screen
    // 3. Render the HTML
    private func visit(proposal: VisitProposal) {
        let visitable = VisitableViewController(url: proposal.url)
        navigationController.pushViewController(visitable, animated: true)
        session.visit(visitable, options: proposal.options)
    }
 }

extension SceneDelegate: SessionDelegate{
    // Web view dies
    func sessionWebViewProcessDidTerminate(_ session: Session) {
        session.reload()
    }
    
    // Link is clicked
    func session(_ session: Session, didProposeVisit proposal: VisitProposal){
        visit(proposal: proposal)
    }
    
    // Link fails
    func session(_ session: Session, didFailRequestForVisitable visitable: Visitable, error: Error){
        print("Failed to visit: \(error.localizedDescription)")
    }
    
}

Aqui, temos algumas coisas relacionadas a navegação do app (que ficam muito bem explicadas pelo Joe no vídeo na Palestra) e logo no começo é possível ver que estamos apontando para algo no endereço localhost:3000. Sim, é aqui que indicamos ao app iOS onde buscar o seu conteúdo.

Agora vamos executar o simulador, isso pode ser feito com o atalho: Command + R

E olha só que maravilha!

Nossa aplicação Rails sendo executada como um app mobile iOS. Sensacional!

Conclusão

Este foi um pequeno exemplo de como é rápido criar um app iOS rodando uma aplicação Rails e isso é só o começo, imagina que para algumas atualizações basta apenas atualizar a aplicação Rails e isso já será refletido no App.

Considerações

Como eu disse anteriormente, isso não é a solução para todos os problemas. Mas é uma boa solução para vários. Reitero que é importante assistir a palestra do Joe, onde ele passa mais detalhes e passa até outras coisas como upload de imagens.

É isso, espero que gostem!

Referências

Palestra: Joe Masilotti - Just enough Turbo Native to be dangerous - Rails World 2023

Link para o Workshop do Joe Masilotti: Workshop

Link para Post no blog do Joe: Masilotti

Essa é uma tradução e adaptação desse artigo.

Como apreciador das obras que inspiraram esse post e como uma pessoa que sempre está em busca de um melhor desempenho, gostei bastante desse artigo que cita inclusive algumas medidas que tomei em minha vida em busca de produtividade e resolvi traduzi-lo. Espero que gostem.

Como uma função bem escrita, prefiro parar de executar cedo se nenhuma condição for válida. Então, se você discorda dessas definições e suposições, agora é um bom momento para parar de ler.

• Produtividade sustentável: A taxa máxima de produção de trabalho de qualidade, sem prejuízo para o bem-estar do desenvolvedor.

• Trabalho de qualidade: software que atende aos requisitos, é valioso para os usuários, pode ser mantido e é o mais livre de bugs possível.

• Atenção: A capacidade mental limitada de se concentrar em uma tarefa.

• A produtividade sustentável é desejada.

• Atenção é essencial para a produtividade sustentável.

Meu fluxo mais produtivo de trabalho é mais ou menos assim: identificar o problema a ser resolvido; pense no problema e deixe as idéias se infiltrarem; pesquise, discuta e experimente essas idéias; implementar e testar a solução; entregar e manter a solução.

Este ciclo pode se repetir muitas vezes ao dia. Ou eu poderia passar dias preso em uma única etapa do ciclo. Cada etapa deste ciclo requer atenção. Quanto mais atenção posso dedicar, mais ciclos posso concluir e mais produtivo sou.

Por quanto tempo você pode se concentrar em uma tarefa varia de pessoa para pessoa. Algumas pessoas são muito boas logo de cara, outras nem tanto. Independente das suas características, acredito que o foco (o ato de priorizar sua atenção) é uma habilidade e, como qualquer habilidade, pode ser melhorada com a prática.

Então, como você pode aumentar suas reservas de atenção? O melhor retorno para seu investimento é organizar seu mundo exterior de forma que seja o mais livre possível de distrações. Depois de fazer isso, você terá mais tempo para praticar e, portanto, mais tempo para melhorar.

Construa força física. O dano causado por ficar sentado 8 horas ou mais por dia é subestimado. Você precisa encontrar uma maneira de compensar esses danos, especialmente se planeja trabalhar nessa área por décadas. Se você não fizer mais nada, faça levantamento de peso. Existem poucos movimentos mais primitivos do que pegar um objeto pesado do chão e levantá-lo. Você pode aprender a técnica correta em minutos. Eu gosto mais de levantamento de peso porque você pode fazê-los com segurança, com pesos elevados, até ficar cansado. Também gosto da força das mãos, das costas e do quadril que eles proporcionam, para dificultar ainda mais os danos ao sentar-se.

Torne o seu local de trabalho enfadonho e organizado. Meu escritório é um quarto extra. As paredes estão vazias. Não há TV. Há uma mesa, cadeira, laptop, suporte para laptop, teclado, mouse e mouse pad. Há uma janela que permite a entrada de luz suficiente para que eu não sinta que estou perdendo um dia lindo, mas não muita luz para causar brilho na tela. Se eu precisar trabalhar com papel, ele é imediatamente arquivado em algum lugar quando terminar. Como eu disse, chato e arrumado.

Deixe seu smartphone mudo. Meu telefone está com todas as notificações desabilitadas, exceto para chamadas e mensagens de texto. Bem, e alertas do National Hurricane Center, já que moro na Louisiana. A menos que você seja minha esposa, você sabe que eu não respondo a mensagens de texto imediatamente, é assim que as coisas são. Desativei minhas contas de mídia social há algum tempo. Mas, se você os tiver, desligar as notificações deve ajudar a diminuir o desejo de verificá-los compulsivamente.

Tenha um sistema operacional minimalista. Os aplicativos que uso com menos frequência estão a uma combinação de teclas de distância. Diante disso, meu dock tem apenas os aplicativos que uso diariamente:

• Sistema de arquivos
• Browser
• Terminal
• Editor de texto para código de front-end e notas
• IDE para código de back-end
• IDE para banco de dados
• Visualizador de diferenças em arquivos para controle de versão
• Cliente de email
• Cliente de mensagem instantânea

Minha área de trabalho alterna entre os estados limpo e sujo. Arquivos com os quais estou trabalhando no momento na área de trabalho. Em seguida, eles são arquivados em pastas adequadas quando concluídos.

Organize os favoritos do seu navegador. Quando leio algo útil que talvez precise consultar mais tarde, eu deixo arquivado em uma pasta geral. Em seguida, itens mais específicos obtêm suas próprias pastas. Os links acessados ​​com frequência ficam visíveis na minha barra de favoritos em sua própria pasta.

Minimize as reuniões. Olha, eu sei que algumas coisas fazem sentido discutir cara a cara, ou voz a voz. Mas se não, você não precisa de uma reunião. Um e-mail ou mensagem instantânea será suficiente.

Finalmente, use o Método Eisenhower para categorizar suas tarefas. Imagine 4 categorias:

• Importante e Urgente
• Importante e Não Urgente
• Não Importante e Urgente
• Não Importante e Não Urgente

Tarefas Importantes e Urgentes precisam ser tratadas. Para mim, esses são geralmente os principais problemas de produção.

Tarefas Importantes e não Urgentes devem absorver a maior parte do seu tempo. Para mim, este é o velho trabalho de desenvolvimento de implementar recursos, corrigir bugs e tornar o código existente mais fácil de manter e melhorar seu desempenho. Também estão incluídos a construção de relacionamentos com outras pessoas e o planejamento futuro.

Tarefas Não Importantes e Urgentes são ladrões de atenção desagradáveis. Eles gritam com você imediatamente, mas oferecem pouco valor em troca. Você deve saber do que estou falando. Para mim, essas são na maioria das vezes perguntas mal feitas por outras pessoas, que exigem mais trabalho para determinar o que está realmente sendo perguntado, em vez de descobrir qual deveria ser a resposta. Também estão incluídas reuniões de última hora e colegas de trabalho muito faladores.

As tarefas Não Importantes e Não Urgentes geralmente não são conhecidas por seus usuários. Ler atualizações da documentação de um projeto por exemplo. O fato é que eles são um investimento em você mesmo, o que significa um “você” mais produtivo no futuro. Portanto, não se esqueça de se dedicar a eles um pouco em seus momentos de folga.

Leitura adicional. Se você não sabe quem é Cal Newport, está perdendo. Ele tem um blog inteiro dedicado a esse tipo de coisa, e já escreveu livros como Deep Work e Digital Minimalism. Aqui estão alguns dos meus artigos favoritos dele:

• Have We Lost Our Tolerance For a Little Boredom?
• Is Allowing Your Child to Study While on Facebook Morally Irresponsible?
• Monday Master Class: How to Reduce Stress and Get More Done By Building an Autopilot Schedule
• Are Passions Serendipitously Discovered or Painstakingly Constructed?
• Jerry Seinfeld’s Closed Door

Em primeiro lugar, pensar no lado humano não é desencorajar a fazer code review, pelo contrário, estou apenas alertando para possíveis problemas causados pelo code review quando feito sem estar consciente de alguns fatores. Fatores estes que estão mais ligados a parte humana do que a parte técnica.

Algumas premissas do code review ficaram fixas na minha cabeça depois de passar por algumas equipes muito boas em fazer code review e outras nem tanto, de qualquer forma o meu objetivo em relação aos code reviews e várias outras coisas da vida é fugir da superficialidade e dar contexto ou um sentido para as minhas ações, então vamos a algumas lições que aprendi:

O principal objetivo e a razão

Algumas vezes podemos esquecer disso, mas o principal objetivo de um code review é manter a qualidade do código, consequentemente melhorando a qualidade/confiabilidade do projeto. Quando se está fixado na mente que o principal objetivo é a qualidade do projeto, cria-se uma missão em comum com os seus colegas de equipe, que gera companheirismo e empatia.

Sempre que for revisar o código de alguém, lembre-se desse objetivo, é comum o code review acabar virando apenas uma crítica sem um objetivo, ou seja, quando uma crítica é feita com uma razão forte, provavelmente, será melhor aceita, já quando feita apenas pensando em código e sem empatia alguma por quem fez, existe uma grande probabilidade que se torne uma coisa desagradável, até mesmo tenha um tom ríspido ou agressivo, o que não traz benefício algum para a equipe.

Assim penso, acima de code reviews e lutas de ego entre programadores, está o bom relacionamento e sintonia entre a equipe. Hoje tenho uma certeza, prefiro trabalhar em empresas que se importam mais com o bom relacionamento dos colaboradores do que com as críticas feitas nos code reviews, já que tenho uma impressão (quase certeza) de que esses ambientes acabam entregando melhores produtos aos seus clientes e são ambientes muito melhores para se trabalhar e crescer como pessoa, além de fazer com o que os colaboradores sintam vontade de permanecer por anos e anos nesses lugares.

Empatia, enviando a mensagem

A empatia é o elo que liga uma crítica a um ambiente cordial e respeitoso entre colegas de equipe. Tive companheiros de equipe que faziam críticas tão boas e de uma forma tão sutil que eu tinha vontade de recebe-las todos os dias (várias vezes aos dias), por sentir que aquilo estava me fazendo evoluir como programador e como pessoa. Ao ver a cordialidade embutida na crítica, aquilo acabava me contagiando e criando um efeito dominó, eu sentia vontade de tratar os meus colegas com toda aquela gentileza que recebi através de críticas. Isso não tem preço.

Por outro lado, quando a empatia não faz parte das peças do jogo, o mais comum é que se crie um ambiente de disputa, nada cordial e até agressivo. Não consigo enxergar de que forma isso traz benefícios para a equipe ou empresa, já que o maior patrimônio das empresas, são as pessoas e não o código. Se as pessoas não estão pensando no seu colega antes de fazer uma crítica, já existe um erro que deveria ser revisado antes mesmo do code review.

Foco no problema, recebendo a mensagem

Do outro lado da ponta está o receptor, quem recebe a mensagem precisa estar preparado e adaptado ao pensamento de que críticas construtivas te fazem evoluir, e isso é tão importante quanto a forma com a mensagem é enviada. Não adianta enviar uma mensagem cordial e gentil se do outro lado é entendida como um “jab de direita”. Focar sempre nos problemas e não em pessoas é um bom exercício para se tornar um expert em receber críticas e transforma-las em um degrau na sua evolução.

Conlusão

Sempre estou me fazendo algumas perguntas como:

• Estou fazendo o meu melhor?
• Estou pensando no meu colega?
• Estou usando as melhores palavras?
• Estou pensando em todo o contexto?

Essa auto-reflexão te deixa mais consciente para não enviar uma mensagem ou receber recebe-la de uma forma errada. Cautela sempre é bom, pensar no próximo é melhor ainda, esses são ingredientes de um bolo que sempre corre riscos de não ficar bom, porém se utilizar os ingredientes certos e fizer com carinho, a chance de dar errado diminui muito. Graças a minha esposa, aprendi isso.

Pra mim, a mesma coisa vale para code reviews, os ingredientes são bem conhecidos e são fáceis de encontrar, basta saber dosar e sempre jogar duas xícaras de chá cheias de empatia que o risco do bolo ficar murcho ou sem sabor, é bem menor.

É isso, dattebayo.