Guia Definitivo de Chaves SSH: Segurança Máxima e Conexões Práticas na sua VPS

No universo da administração de servidores, o acesso remoto via SSH (Secure Shell) é uma das ferramentas mais triviais e indispensáveis. Contudo, há uma linha tênue entre a facilidade de acesso e a vulnerabilidade do sistema. Depender exclusivamente de logins por senha deixa seus servidores expostos a ataques automatizados de força bruta de escala global.

A solução definitiva para este problema reside na implementação de autenticação por chaves SSH. Neste artigo, vamos explorar minuciosamente o conceito de par de chaves, como realizar o endurecimento de segurança (hardening) do serviço no servidor remoto, automatizar a cópia das credenciais e estruturar atalhos para otimizar drasticamente o seu fluxo de trabalho diário.

1. O Conceito Fundamental: Chave e Fechadura

Para entender chaves SSH de forma definitiva, podemos utilizar a analogia clássica de uma chave física e sua respectiva fechadura criptográfica:

• Chave Privada (Sua Chave): Permanece exclusivamente na sua máquina local. Ela nunca, sob hipótese alguma, deve ser compartilhada, transmitida ou exposta a terceiros. Ela atua como o segredo necessário para assinar as solicitações de acesso.
• Chave Pública (A Fechadura): É instalada nos servidores remotos (VPS) aos quais você deseja obter acesso. Por ser um componente público, o conhecimento dela por terceiros não compromete o sistema, uma vez que ela é matematicamente inútil se não estiver associada à chave privada correspondente.

Quando você solicita uma conexão, o cliente local e o servidor remoto utilizam conceitos de criptografia assimétrica para validar a autenticidade da sessão sem que a sua chave privada precise trafegar pela rede.

2. Gerando o Par de Chaves Criptográficas

O primeiro passo prático consiste em gerar o par de chaves na sua máquina local. Atualmente, o padrão recomendado pela indústria em termos de segurança e performance de processamento é o algoritmo ED25519, superando os legados padrões RSA.

Abra o terminal do seu computador local e execute o comando abaixo:

ssh-keygen -t ed25519 -f ~/.ssh/id_vps_root

O parâmetro -t ed25519 especifica o algoritmo moderno desejado, enquanto o -f define o caminho e o nome customizado do arquivo de identidade (evitando sobrescrever chaves genéricas pré-existentes).

Durante o processo, o utilitário solicitará uma Passphrase (frase secreta). Trata-se de uma senha que criptografa a sua própria chave privada em disco. Caso alguém consiga roubar o arquivo da sua máquina, não poderá usá-lo sem conhecer essa senha. Para rotinas altamente automatizadas, alguns profissionais optam por deixá-la vazia, o que requer uma atenção redobrada na segurança física do dispositivo local.

Após a conclusão, dois arquivos serão gerados no diretório ~/.ssh/:

• id_vps_root: O arquivo contendo a sua chave privada (sigilo absoluto).
• id_vps_root.pub: O arquivo contendo a sua chave pública (a ser exportada).

3. Exportando a Chave Pública para a VPS

Para que o servidor remoto reconheça a sua assinatura criptográfica, precisamos armazenar o conteúdo da chave pública dentro de um arquivo específico na conta do usuário remoto, localizado por padrão em ~/.ssh/authorized_keys.

Método Automatizado (Recomendado)

A maneira mais limpa e segura de realizar esse procedimento é usando o comando nativo ssh-copy-id, passando explicitamente o arquivo público gerado:

ssh-copy-id -i ~/.ssh/id_vps_root.pub usuario@ip_do_seu_servidor

O utilitário se conectará ao servidor (solicitando a senha tradicional pela última vez), criará as pastas necessárias com as permissões corretas e inserirá a chave de maneira limpa.

Método Manual (Alternativo)

Caso o utilitário automatizado não esteja disponível, você pode exibir o conteúdo da chave na sua tela, copiá-lo e inseri-lo manualmente no servidor:

cat ~/.ssh/id_vps_root.pub

No servidor remoto, você precisará colar essa string de texto dentro do arquivo ~/.ssh/authorized_keys. É de suma importância garantir as permissões rígidas exigidas pelo serviço OpenSSH, executando na VPS:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys

⚠️ Atenção Crucial às Permissões!

O OpenSSH possui salvaguardas rigorosas. Se o diretório .ssh ou o arquivo authorized_keys permitirem escrita ou leitura por outros grupos/usuários do sistema, o servidor ignorará a chave pública silenciosamente e bloqueará a conexão.

4. Hardening do Servidor: Ajustando o arquivo sshd_config

Apenas habilitar as chaves SSH não protege seu ambiente por completo se as vulnerabilidades de autenticação por senha padrão continuarem ativas. Precisamos reconfigurar o serviço SSH Daemon no servidor remoto.

Acesse sua VPS e abra o arquivo de configuração principal (utilize o editor de sua preferência com privilégios administrativos):

sudo nano /etc/ssh/sshd_config

Localize (ou adicione ao final do arquivo) as seguintes diretivas críticas detalhadas na tabela abaixo:

Diretiva de Configuração	Explicação Técnica e Impacto de Segurança
PubkeyAuthentication yes	Habilita oficialmente a validação e aceitação de conexões baseadas em chaves SSH assimétricas. Elemento mandatório da indústria.
PasswordAuthentication no	Desativa completamente o login por senhas tradicionais. Isso elimina 100% dos ataques automatizados baseados em dicionários e força bruta.
PermitRootLogin no	Impede que o usuário administrador máximo (root) realize login diretamente de fora. Obriga o acesso por uma conta de usuário comum, elevando privilégios apenas quando necessário via sudo.
PermitEmptyPasswords no	Mecanismo de salvaguarda explícito que impede acessos a contas locais que, por ventura ou erro, não possuam senha definida.

💡 Dica de Manutenção Proativa

Sistemas modernos baseados em Debian/Ubuntu frequentemente importam arquivos modulares localizados em /etc/ssh/sshd_config.d/*.conf. As diretivas são interpretadas de cima para baixo. Portanto, certifique-se de aplicar suas regras onde elas efetivamente se sobreponham aos padrões mais fracos.

Antes de aplicar as alterações, teste a sintaxe do arquivo de configuração para garantir que você não inseriu erros tipográficos que possam te trancar para fora do servidor de vez:

sudo sshd -t

Se nenhum erro for retornado, reinicie o daemon para aplicar as políticas ativas:

sudo systemctl restart ssh

5. Produtividade Máxima: Criando Atalhos Avançados (Aliases)

Após fixar as chaves, digitar comandos extensos definindo parâmetros de arquivos de identidade em todas as conexões compromete o fluxo produtivo. Para resolver isso, configuramos atalhos organizados diretamente na máquina local cliente.

No seu computador local, crie ou edite o arquivo de configuração do usuário cliente:

nano ~/.ssh/config

Adicione um bloco de configuração mapeando explicitamente a sua VPS:

Host meu-servidor
    HostName ip_ou_dominio_da_sua_vps
    User seu_usuario_remoto
    Port 22
    IdentityFile ~/.ssh/id_vps_root
    IdentitiesOnly yes

Entendendo as propriedades do bloco do cliente:

• Host meu-servidor: O alias ou pseudônimo que você escolheu. Você pode usar qualquer nome intuitivo aqui.
• HostName: O endereço IPv4 público ou domínio qualificado da VPS de destino.
• User: O nome exato do usuário remoto configurado para receber as chaves.
• IdentityFile: O caminho exato da chave privada local correspondente para esta conexão.
• IdentitiesOnly yes: Instrui o SSH a tentar estritamente a identidade configurada neste bloco, prevenindo que o agente teste chaves aleatórias em massa, o que dispararia gatilhos de segurança e rejeições por tentativas excessivas nos servidores mais rígidos.

Agora, o acesso à infraestrutura remota resume-se a um único e rápido comando no terminal:

ssh meu-servidor

O cliente lerá o arquivo config de forma transparente, carregará a identidade privada correta, mapeará as credenciais de IP e usuário adequadas e abrirá o terminal seguro de maneira imediata e robusta.

Considerações finais

A transição de autenticações tradicionais baseadas em senhas para pares de chaves assimétricas estruturadas via algoritmo ED25519 é o pilar inicial essencial de qualquer arquitetura de infraestrutura de rede resiliente. Ao combinar a segurança do endurecimento no arquivo sshd_config com o conforto operacional provido pelos blocos de configuração do cliente SSH, você eleva significativamente a maturidade de segurança da sua VPS ao mesmo tempo em que otimiza sua velocidade de operação diária.

Feito!

Como estruturar a arquitetura da ferramenta de IA do jeito certo

Se você utiliza a ferramenta de Inteligência Artificial de IA no seu dia a dia de desenvolvimento ou criação de conteúdo, provavelmente já passou por este cenário: você começa um chat com um LLM, o fluxo vai bem nas primeiras interações, mas, após algumas correções e colagens de código, a IA começa a alucinar, perder o fio da meada e entregar outputs de baixa qualidade.

Esse fenômeno não é um defeito do modelo em si, mas sim um reflexo da fadiga da janela de contexto. À medida que entupimos o histórico com tentativas e erros, o poder de raciocínio do modelo degrada. Para mitigar isso, profissionais estão evoluindo o uso de ferramentas como o Claude Code, ChatGPT/Codex, Gemini e etc de simples caixas de chat para ecossistemas maduros.

Para extrair o máximo valor dos LLMs com eficiência, performance e baixo custo, o mercado de tecnologia está migrando do Prompt Engineering casual para a verdadeira Arquitetura de IA. A seguir, vamos entender como essa estrutura se divide entre Harness, Skills, Agents e Subagents.

O coração da estrutura: O que é o Harness?

Muitas vezes confundido com engenharia de contexto, o Harness é a infraestrutura de software que encapsula o LLM (o motor de raciocínio). Enquanto o modelo apenas processa texto, o Harness dita as regras arquiteturais do sistema:

• Permissões e Segurança: Define se a IA pode alterar arquivos diretamente na IDE ou se precisa de aprovação manual.
• Gestão de Estado: Gerencia o que deve ser mantido como memória persistente a longo prazo e o que é apenas um estado temporário da execução atual.
• Ciclo de Instruções: Determina quais diretrizes e guias técnicos (como arquivos Markdown de especificação) entram no contexto do modelo em cada etapa.

Com um Harness bem desenhado, você elimina a necessidade de repetir regras de boas práticas em cada prompt enviado, automatizando o alinhamento de contexto.

Skills vs. Agents: Quando usar cada abordagem?

Uma das maiores confusões atuais é chamar qualquer automação simples de "Agente". Na arquitetura moderna, dividimos a execução de tarefas de forma clara com base na previsibilidade do escopo.

1. Skills (habilidades reutilizáveis e previsíveis)

As Skills são pacotes de instruções padronizados e reutilizáveis voltados para processos conhecidos. Quando você sabe exatamente as etapas do fluxo de trabalho e precisa de um resultado padronizado, você desenha uma skill.

• Foco principal: Previsibilidade e economia de tokens de contexto.
• Exemplos: Gerar propostas comerciais em um formato fixo, rodar um checklist de Code Review ou criar metadados padronizados para vídeos.
• Reutilização: Uma mesma habilidade pode ser acoplada a múltiplos componentes do seu sistema sem reescrever o código base.

2. Agents (ciclos de ação autônomos)

Um Agent entra em cena quando enfrentamos processos investigativos ou de escopo desconhecido. Em vez de apenas gerar um texto estático, o agente opera dentro de um loop dinâmico de ação (agent loop): ele analisa o problema, planeja os passos, executa e valida o resultado de forma autônoma.

• O papel do MCP: Graças ao surgimento do Model Context Protocol (MCP), os agentes ganharam uma interface universal para se conectar a ferramentas externas (bancos de dados, APIs e sistemas de arquivos), permitindo ações robustas no mundo real.

Visualizando a Arquitetura Híbrida

O segredo da manutenção da performance é a aplicação do componente correto para o problema certo. Abaixo, ilustramos como um Agente atua como orquestrador de escopos:

Cenário Arquitetural: Fluxo Híbrido de IA

Otimizando a Janela de Contexto com Subagents

Para evitar a saturação da memória do chat principal, a arquitetura moderna delega escopos. Quando um agente principal recebe uma macro-tarefa que envolve varredura de logs ou pesquisas longas, ele invoca um Subagent em uma janela paralela.

O subagente consome os tokens necessários para aquela micro-investigação, resolve o problema e devolve apenas o dado consolidado para o fluxo principal. Isso protege a experiência de uso contra o desperdício de recursos e falhas de alucinação.

Nota de Automatização Consciente: Nem tudo precisa de utilizar uma ferramenta de Inteligência Artificial (IA). Se o processo é estritamente mecânico (como mover arquivos ou converter formatos), utilize scripts convencionais em lote ou ferramentas de pipeline. Deixe os LLMs para etapas que demandam interpretação pura.

Considerações finais

O mercado de tecnologia está deixando para trás a fase do empirismo de prompts copiados e colados. O próximo nível profissional exige a capacidade de sistematizar o conhecimento em software, desenhando arquiteturas capazes de entregar alta qualidade com o menor consumo de recursos possível. Ao estruturar seu fluxo com componentes modulares, você garante escalabilidade e robustez na engenharia de soluções orientadas a IA.

DDD explicado de forma didática

Domain-Driven Design: como modelar software complexo colocando o domínio no centro do universo

O que é DDD?

Domain-Driven Design (DDD) é uma abordagem de desenvolvimento de software criada por Eric Evans no livro azul de 2003. O nome pode assustar, mas a ideia é simples: em vez de começar pensando em bancos de dados, rotas HTTP ou frameworks, você começa pensando no domínio do negócio, ou seja, no problema que o software precisa resolver.

DDD não é uma tecnologia, nem um framework, nem uma arquitetura como MVC. É um conjunto de princípios e padrões que ajuda times de software a criar modelos mentais compartilhados com especialistas do negócio.

"O coração do software é a capacidade de resolver problemas do domínio." Eric Evans

Por que DDD existe?

Projetos de software falham com frequência porque o time técnico e os especialistas do negócio não falam a mesma língua. O desenvolvedor pergunta "qual o tipo desse campo?"; o especialista responde "é o código da agência". Ninguém se entende. O resultado são sistemas cheios de regras espalhadas, modelos anêmicos e código que ninguém consegue mudar sem quebrar tudo.

DDD propõe uma linguagem comum (chamada de Ubiquitous Language) usada por todos, do analista ao dev ao QA, e um modelo de software que reflete fielmente essa linguagem.

Os pilares do DDD

1. Linguagem Ubíqua (Ubiquitous Language)

É o vocabulário compartilhado entre todos os envolvidos. Se o especialista chama algo de "Transferência", o código deve ter uma classe Transferencia, a tabela deve se chamar transferencias, e a API deve expor /transferencias. Nada de Trans, TransfRecord ou transactions, usem o mesmo nome.

2. Domínio e Subdomínios

O domínio é o coração do negócio, é o problema principal que o sistema resolve. Um único sistema grande geralmente contém vários subdomínios:

• Core Domain: a parte mais importante, que dá vantagem competitiva. Ex: o motor de precificação de um banco.
• Supporting Subdomain: necessário, mas não estratégico. Ex: cálculo de impostos.
• Generic Subdomain: pode ser comprado ou usado pronto. Ex: autenticação, envio de e-mail.

// Exemplo: o domínio de um sistema bancário
// Core Domain: Motor de crédito
class AnaliseDeCredito {
  constructor(private score: Score, 
  private rendaMonetaria: Renda) {}
  aprovar(): boolean {
      /* lógica de negócio central */
      }
}

// Supporting Subdomain: Cálculo de tarifas
class CalculadoraDeTarifas {
  calcular(operacao: Operacao): number { 
  /* complexo, mas não estratégico */ }
}

// Generic Subdomain: Autenticação (pronto, comprado)
// Usamos Keycloak, Auth0, ou similar

3. Contextos Delimitados (Bounded Contexts)

Um dos conceitos mais importantes do DDD. Um Bounded Context é uma fronteira explícita dentro da qual um modelo de domínio é válido. Dentro dela, a Linguagem Ubíqua tem significado único e consistente.

Por exemplo: no contexto de Vendas, "Cliente" tem endereço de entrega e histórico de pedidos. No contexto de Cobrança, "Cliente" tem CPF, score de crédito e data de vencimento. São modelos diferentes e devem viver em contextos separados (serviços, módulos, ou até repositórios distintos).

Cada Bounded Context pode ter sua própria arquitetura, seu próprio banco de dados e sua própria equipe. O que vale dentro de um, não vale dentro do outro.

Os blocos de construção táticos

DDD fornece padrões de modelagem para transformar a linguagem do negócio em código expressivo.

Entity

Um objeto que tem identidade própria. Dois objetos com os mesmos atributos mas identidades diferentes são entidades diferentes. Ex: um Cliente com id = 123 é diferente do cliente id = 456, mesmo que tenham o mesmo nome.

class Cliente {
  constructor(
    // identidade única
    readonly id: ClienteId,  
    private nome: Nome,
    private email: Email
  ) {}

  trocarEmail(novoEmail: Email): void {
    this.email = novoEmail;
  }
}

Value Object

Um objeto que não tem identidade, é definido apenas pelos seus atributos. Dois Value Objects com os mesmos valores são considerados iguais. São imutáveis.

• Dinheiro (valor + moeda), R$ 50,00 não deixa de ser R$ 50,00 por ter "identidade".
• CPF, Email, Endereco, todos imutáveis e comparados por valor.

class Dinheiro {
  constructor(
    readonly valor: number,
     // 'BRL', 'USD'
    readonly moeda: string 
  ) {}

  somar(outro: Dinheiro): Dinheiro {
    if (this.moeda !== outro.moeda)
      throw new Error('Moedas diferentes');
    return new Dinheiro(this.valor + 
                       outro.valor, this.moeda);
  }

  equals(outro: Dinheiro): boolean {
    return this.valor === outro.valor && 
               this.moeda === outro.moeda;
  }
}

Aggregate

Um cluster de objetos tratados como uma unidade. Cada Aggregate tem uma raiz (Aggregate Root) que é a única porta de entrada para o mundo externo. Toda consistência do cluster passa pela raiz.

// Aggregate Root: Pedido
class Pedido {
  constructor(
    readonly id: PedidoId,
    readonly clienteId: ClienteId,
    private itens: Item[],
    private status: StatusPedido
  ) {}

  adicionarItem(produto: Produto, 
    quantidade: number): void {
    if (this.status !== 'aberto')
      throw new Error('Pedido fechado não aceita itens');
    this.itens.push(new Item(produto, quantidade));
  }

  total(): Dinheiro {
    return this.itens.reduce(
      (acc, item) => acc.somar(item.subtotal()),
      new Dinheiro(0, 'BRL')
    );
  }
}

Domain Event

Algo que aconteceu no domínio e interessa a outras partes do sistema. Usa-se verbos no passado: PedidoCriado, TransferenciaRealizada, ContaEncerrada.

class PedidoCriado {
  constructor(
    readonly pedidoId: PedidoId,
    readonly clienteId: ClienteId,
    readonly total: Dinheiro,
    readonly ocorridoEm: Date = new Date()
  ) {}
}

Repository

Abstração de persistência. Para o domínio, o Repository parece um coleção em memória. O domínio nunca sabe se está usando PostgreSQL, MongoDB ou arquivo JSON.

interface PedidoRepository {
  salvar(pedido: Pedido): Promise<void>;
  buscarPorId(id: PedidoId): Promise<Pedido | null>;
  buscarPorCliente(clienteId: ClienteId): Promise<
                                          Pedido[]>;
}

Domain Service

Quando uma operação não pertence naturalmente a uma Entity ou Value Object, criamos um Domain Service. Ele orquestra regras que envolvem múltiplos agregados.

class ServicoDeTransferencia {
  constructor(
    private contas: ContaRepository
  ) {}

  transferir(origemId: ContaId, destinoId: 
  ContaId, valor: Dinheiro): void {
    const origem = this.contas.buscarPorId(origemId);
    const destino = this.contas.buscarPorId(destinoId);

    origem.debitar(valor);
    destino.creditar(valor);

    this.contas.salvar(origem);
    this.contas.salvar(destino);
  }
}

DDD e arquitetura

DDD não exige uma arquitetura específica, mas se encaixa perfeitamente com Arquitetura Hexagonal (Ports & Adapters) e Clean Architecture. A regra de ouro é:

• O domínio fica no centro, isolado de frameworks, banco de dados e UI.
• A infraestrutura (HTTP, banco, filas) fica nas bordas e depende do domínio, não o contrário.
• As dependências apontam para dentro (Dependency Inversion Principle).

src/
├── dominio/    # CORE  sem dependências externas
│   ├── entidades/
│   ├── value-objects/
│   ├── servicos/
│   └── repositorios/ # Interfaces apenas
├── aplicacao/        # Casos de uso (orquestração)
├── infra/            # Implementações concretas
│   ├── persistencia/
│   ├── http/
│   └── fila/
└── shared/           # Código compartilhado

Quando usar DDD?

• Use quando o domínio do negócio é complexo e cheio de regras.
• Use quando há especialistas de negócio dispostos a conversar com o time técnico.
• Não use em CRUDs simples um formulário que só insere dados no banco não precisa de DDD.
• Não use se o time não tem disciplina para manter a Linguagem Ubíqua viva.
• Não use como dogma DDD é ferramenta, não religião.

Passos práticos para começar

1. Entreviste especialistas sente com quem entende do negócio e faça perguntas. Anote os termos que eles usam.
2. Crie um glossário monte a Linguagem Ubíqua com definições claras de cada termo.
3. Identifique os Bounded Contexts desenhe fronteiras: o que faz parte de Vendas? O que faz parte de Cobrança?
4. Modele os Aggregates descubra as raízes e o que pertence a cada uma.
5. Implemente com TDD o domínio é a parte mais testável do sistema. Teste as regras de negócio sem tocar em banco ou HTTP.
6. Refatore sem medo o modelo de domínio evolve com o negócio. DDD favorece a mudança.

Exemplo completo: Aluguel de Carros

Vamos modelar um pequeno domínio de locação de veículos usando DDD:

// ——— Value Objects ———
class Placa {
  constructor(readonly valor: string) {
    if (!/^[A-Z]{3}\d[A-Z]\d{2}$/.test(valor))
      throw new Error('Placa inválida');
  }
}

class Quilometragem {
  constructor(readonly valor: number) {
    if (valor < 0) throw new 
    Error('KM não pode ser negativo');
  }
}

class Periodo {
  constructor(readonly inicio: Date, 
  readonly fim: Date) {
    if (fim <= inicio) throw new 
    Error('Período inválido');
  }
  duracaoDias(): number {
    return (this.fim.getTime() - 
    this.inicio.getTime()) / 86400000;
  }
}

// ——— Aggregate: Veiculo ———
class Veiculo {
  constructor(
    readonly id: VeiculoId,
    readonly placa: Placa,
    private kmAtual: Quilometragem,
    private disponivel: boolean = true
  ) {}

  alugar(): void {
    if (!this.disponivel) throw new 
    Error('Veículo indisponível');
    this.disponivel = false;
  }

  registrarDevolucao(kmFinal: Quilometragem): void {
    this.disponivel = true;
    this.kmAtual = kmFinal;
  }
}

// ——— Aggregate: Locacao ———
class Locacao {
  constructor(
    readonly id: LocacaoId,
    readonly veiculoId: VeiculoId,
    readonly clienteId: ClienteId,
    readonly periodo: Periodo,
    readonly tarifaDiaria: Dinheiro,
    private status: 'ativa' | 'finalizada' = 'ativa'
  ) {}

  calcularTotal(): Dinheiro {
    const dias = this.periodo.duracaoDias();
    return new Dinheiro(dias * 
           this.tarifaDiaria.valor, 'BRL');
  }

  finalizar(): void {
    if (this.status === 'finalizada')
      throw new Error('Locação já finalizada');
    this.status = 'finalizada';
  }
}

// ——— Domain Event ———
class VeiculoAlugado {
  constructor(
    readonly veiculoId: VeiculoId,
    readonly locacaoId: LocacaoId,
    readonly clienteId: ClienteId
  ) {}
}

// ——— Repository (interface) ———
interface VeiculoRepository {
  salvar(veiculo: Veiculo): Promise<void>;
  buscarDisponivel(): Promise<Veiculo[]>;
  buscarPorId(id: VeiculoId): Promise<Veiculo | null>;
}

Para se aprofundar

• Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans (o "livro azul")
• Implementing Domain-Driven Design Vaughn Vernon (o "livro vermelho")
• Domain-Driven Design Distilled Vaughn Vernon (resumo prático, ótimo para começar)
• DDD: The First 15 Years Artigos de diversos autores sobre a evolução do DDD

Considerações finais

DDD não é sobre diagramas bonitos ou arquitetura sofisticada. É sobre comunicação. É sobre criar um modelo de software que qualquer pessoa do negócio consegue ler e validar. É sobre colocar a complexidade do domínio no centro e usar padrões que a tornem controlável.

Comece pequeno: escolha um Bounded Context, crie a Linguagem Ubíqua com um especialista, modele alguns Aggregates e escreva testes. O resto vem com a prática.

DDD é uma jornada, não um destino.

Feito!

A defasagem acadêmica em TI: Por que você deve ser um aluno autodidata

O cenário atual do ensino superior de Tecnologia da Informação no Brasil enfrenta um desafio crítico: o abismo entre o que é ensinado em sala de aula e o que o mercado de trabalho realmente exige. Enquanto as tecnologias evoluem em ciclos semestrais, os currículos acadêmicos muitas vezes permanecem estáticos por anos.

O Abismo entre Teoria e Prática

Muitas faculdades focam excessivamente no "saber" acadêmico, títulos, teses e artigos de prateleira, enquanto o mercado valoriza o "saber fazer". Em áreas como Infraestrutura e Redes, ensinar apenas com "giz e saliva" ou slides estáticos é insuficiente. A tecnologia exige laboratório, experimentação e contato direto com o hardware e software moderno.

Os principais problemas da faculdade tradicional:

• Currículos Defasados: Linguagens e metodologias que não acompanham a velocidade da IA e Cloud Computing.
• Comodismo Docente: Professores que replicam materiais de décadas atrás sem atualização prática.
• Falta de Infraestrutura: O alto custo de equipamentos muitas vezes impede que a faculdade ofereça o ambiente real de um Data Center.

A Diferença entre o Aluno "Passivo" e o Autodidata

Muitos estudantes cometem o erro de esperar passivamente pelo material do professor. Se o professor disponibiliza apenas um resumo em slides, o aluno passivo limita seu conhecimento àquela simplificação. Ele espera a lista de exercícios pronta para apenas cumprir uma tarefa.

Em contrapartida, o aluno autodidata não espera. Ele busca direto na fonte: o livro-texto que serviu de base para os slides. Ele resolve os exercícios que não foram pedidos e vai além do que a ementa exige. Esse comportamento é o que separa um profissional comum de um engenheiro de excelência.

Colocando a Mão na Massa: O Exemplo das Redes

Para aprender Redes de Computadores ou Sistemas Distribuídos de verdade, a curiosidade deve ser o motor principal. Não basta ler sobre IPs e protocolos; é preciso simular cenários reais.

Dica Prática: Simulação de Ambiente Real

Um aprendizado sólido envolve criar Máquinas Virtuais (VMs) e configurar a interface de rede em modo Bridge (Ponte). Ao fazer isso, a VM recebe um IP na mesma faixa da sua rede física, permitindo que ela se comporte como uma máquina real na rede.

Isso permite testar:

• Conectividade entre sistemas distribuídos.
• Configurações de servidores Web e Banco de Dados.
• Protocolos de roteamento e segurança de rede.

Considerações finais

As universidades podem fornecer o diploma, mas o aprendizado real vem da curiosidade e da prática constante. Se você quer ser um Full Cycle Developer ou um especialista em infraestrutura, o segredo é ser inquieto: leia os livros, suba seus próprios laboratórios e não dependa exclusivamente da grade curricular. O mercado não paga pelo seu diploma, paga pela sua capacidade de resolver problemas reais.

Referências

Faculdades de TI defasadas" do canal Netfinders Brasil

Feito!

Uma alternativa gratuita e Open Source ao Claude Design

A era das ferramentas de design assistidas por Inteligência Artificial (IA) ganhou um novo capítulo. Se você se encantou com as capacidades do Claude Design, mas se sentiu limitado pelas cotas de uso ou pelo custo da assinatura, o Open Design surge como a solução definitiva. Exploramos como essa ferramenta está democratizando a criação de interfaces de alta fidelidade.

O que torna o Open Design "Insano"?

Diferente das soluções proprietárias, o Open Design não é apenas uma ferramenta de chat; é um ecossistema completo para desenvolvedores e designers que buscam autonomia total. Seus pilares fundamentais são a liberdade de escolha e a robustez técnica.

1. Adeus ao "IA Slop" (Conteúdo Genérico)

Um dos maiores problemas das ferramentas/agentes de IAs atuais é o conteúdo padronizado e sem alma. O Open Design utiliza um mecanismo "anti-slop" que força o LLM a realizar uma breve entrevista de briefing com o usuário antes de gerar o código. Isso garante que o resultado final reflita a identidade da marca e as necessidades reais do público-alvo.

2. Biblioteca de 72 Design Systems

A ferramenta vem carregada com mais de 70 sistemas de design prontos. Quer que seu projeto tenha a estética da Apple ou a robustez de um dashboard corporativo? Basta selecionar o sistema correspondente. Isso elimina horas de trabalho definindo paletas de cores, tipografia e espaçamentos.

3. Independência de Modelo

Você não está preso ao Claude. O Open Design pode ser conectado ao GPT-4, modelos locais via Ollama ou qualquer outra API de LLM, permitindo que você controle seus próprios custos e privacidade de dados.

Como começar: O caminho da instalação

Segue os procedimentos de pré-requisitos e de instalação

Os principais pré-requisitos para o sucesso da instalação incluem:

• Instalação prévia do Node.js.
• Git
• Configuração de chaves de API (OpenAI, Anthropic, Gemini) ou conexão com modelos locais.

Clonar o repositório

git clone https://github.com/nexu-io/open-design.git

Acessar o diretório

cd open-design

Habilitar o gerenciador de pacotes

corepack enable

Instalar dependências

pnpm install

Executar o ambiente de desenvolvimento

pnpm tools-dev run web

Considerações Finais

Embora ainda existam pontos de polimento, como alguns bugs visuais em exportações complexas e uma interface mais rústica que a versão oficial, o Open Design é um marco. Ele prova que o futuro do design assistido por IA será aberto, customizável e acessível a qualquer pessoa com vontade de aprender.

Referências

https://github.com/nexu-io/open-design

Feito!

Elevando o Hermes Agent para o Nível Profissional e Seguro

Se você acompanha a evolução dos agentes de IA autônomos, sabe que o Hermes Agent tem se consolidado como o principal concorrente open-source do OpenClaw. Recentemente, o lançamento do Hermes Desktop mudou o jogo, trazendo uma interface gráfica (GUI) poderosa que permite gerenciar seus agentes com a mesma fluidez de um Claude Desktop, mas com soberania total sobre seus dados.

O Que Torna o Hermes Desktop um "Game Changer"?

• Gerenciamento Remoto: Rode o "cérebro" na VPS (24/7) e controle-o do seu notebook pessoal.
• Aprendizado Contínuo: O agente utiliza lógica de auto-evolução, aprendendo com sucessos e falhas.
• Privacidade (Self-Hosted): Seus dados e códigos não passam por servidores de terceiros.

1. Instalação do Hermes Agent na VPS (Ubuntu)

No servidor, utilizaremos o instalador automático para agilizar o processo:

Atualize o sistema

sudo apt update && sudo apt upgrade -y

Instalação automática do Hermes Agent

curl -fsSL https://get.hermesagent.com | bash

Gere sua API Key segura

openssl rand -hex 32

Configuração de Segurança (Blindagem)

Edite o arquivo .env para garantir que o serviço não fique exposto diretamente à internet:

# Edite as variáveis no .env
SERVER_HOST=127.0.0.1
SERVER_PORT=8642
API_KEY=SUA_CHAVE_GERADA_AQUI
API_SERVER_ENABLE=true

Reinicie o serviço para aplicar:

gateway restart

2. Instalação do Hermes Desktop no Computador

Escolha o procedimento de acordo com seu sistema operacional:

• Clonar o repositório:
  git clone https://github.com/fathah/hermes-desktop
• Acessar o diretório: cd hermes-desktop
• Instalar dependências: npm install (isso baixa o Electron e as bibliotecas necessárias).
• Gerar o executável: npm run build:sua-plataforma., conforme segue abaixo.

  
    npm run build:mac 
    npm run build:win 
    npm run build:linux 
    npm run build:rpm   
  
  

3. A Premissa do Túnel SSH: O "Pulo do Gato"

Para um workflow profissional, não abrimos portas no firewall. Usamos o SSH Port Forwarding para criar um túnel criptografado entre sua máquina e a VPS.

Como abrir o túnel:

No seu terminal pessoal (Windows PowerShell, Linux ou Mac), execute:

ssh -L 8642:127.0.0.1:8642 usuario@ip-da-vps -i ~/.ssh/id_rsa -N

Com o terminal do túnel aberto, configure o Hermes Desktop com os seguintes dados:

1. Server URL: http://127.0.0.1:8642
2. API Key: A chave hexadecimal que você gerou na VPS.

Considerações finais

Combinar o Hermes Agent em uma VPS com o Hermes Desktop via Túnel SSH entrega o melhor dos dois mundos: a conveniência de uma interface moderna e a segurança inabalável de uma infraestrutura privada. É a verdadeira autonomia para o desenvolvedor moderno.

Feito!

Como reduzir 50% do consumo de créditos do Claude Code sem perder qualidade

Guia técnico para founders, operadores e líderes que usam Claude pesado e não querem sair do plano atual

Por que esse documento existe

Nas últimas semanas, "o Claude está queimando meus créditos" virou uma das frases mais repetidas em comunidades de founder e operador de IA no Brasil.

Um desenvolvedor monitorou o próprio uso e descobriu que 98,5% dos tokens consumidos foram gastos relendo histórico de conversa. Apenas 1,5% saiu na resposta final.

Algo mudou na infraestrutura da Anthropic em 2026. Eles formalizaram estrutura de pico e fora de pico, então seu limite de sessão de 5 horas drena mais rápido nas manhãs de dia útil. Isso é real e importa.

Mas ninguém está falando publicamente o que importa mais. Os hábitos que causam a maior parte do desperdício já existiam antes da mudança. Os limites só tornaram o problema visível.

Esse guia é sobre o mecanismo. Quando você entende como o Claude conta o que você envia, a maior parte do desperdício fica óbvia, e a maior parte das soluções leva menos de 5 minutos.

Ao final desse documento, você vai saber exatamente:

• Para onde estão indo seus créditos;
• Quais hábitos mudar essa semana;
• Como configurar um sistema que corta seu consumo de tokens em 50% ou mais sem mudar de plano e sem perder qualidade;
• Como integrar Claude otimizado com workflow Lovable na sua operação.

Como o Claude realmente conta o que você envia

Antes dos hábitos, o modelo. Sem entender isso, nenhuma das dicas faz sentido intuitivo.

Toda vez que você envia uma mensagem para o Claude, ele não lê só sua nova mensagem. Ele relê a conversa inteira desde o começo. Toda mensagem que você enviou, toda resposta que ele deu, do turno 1 ao turno atual, tudo isso, antes de gerar 1 palavra da nova resposta.

A janela de contexto não é resumo rolante. É transcrição completa que cresce a cada troca. A conversa acumula custo.

A matemática quando você efetivamente conta:

Considere cada troca (sua mensagem + resposta do Claude) como tendo o mesmo tamanho. Chame de 1 unidade.

• Turno 1 custa 2 unidades no total.
• Turno 2 custa 4 unidades (3 entrando porque o histórico inteiro vai junto, 1 saindo).
• Turno 10 custa 20 unidades por turno.
• No turno 10, gasto cumulativo: 110 unidades.

As mesmas 10 tarefas em 10 conversas separadas de 1 turno cada: 20 unidades.

Mesmo trabalho. 5,5 vezes mais caro. Só por manter um chat aberto.

Segunda dimensão para entender. O modelo que você usa é multiplicador em todo token da conversa, não só na mensagem atual. Haiku, Sonnet e Opus têm preços diferentes. A mesma conversa no Opus custa cerca de 5 vezes mais que no Haiku. Não porque usa mais tokens, mas porque cada token custa mais.

Duas alavancas então. Custo por token é o multiplicador do modelo. Volume de tokens é quanto seus hábitos geram. Reduza as duas e você vai se perguntar como já bateu limite alguma vez.

Os 6 hábitos que estão drenando seu consumo

A maioria das pessoas assume que o caro é prompt longo e complexo. Não é. O caro é quase sempre 1 desses 6 padrões, frequentemente em combinação.

1. Conversas que rodam tempo demais

Cada turno carrega o histórico inteiro. Uma sessão que vai a 25 mensagens antes da tarefa terminar pagou cerca de 12 vezes o conteúdo que produziu.

A solução não é usar Claude menos. É começar do zero entre tarefas.

2. PDFs e arquivos enviados em formato bruto

Quando você sobe PDF, o Claude extrai texto e também converte cada página em imagem, processando os dois.

O custo:

• 1.500 a 3.000 tokens por página só para texto, antes do processamento de imagem.
• Um PDF de 50 páginas pode consumir 75.000 a 150.000 tokens antes da sua primeira pergunta.
• DOCX, PPTX e XLSX têm overhead similar de metadados de formatação.

Se você sobe o mesmo documento em 5 conversas diferentes, paga esse custo 5 vezes.

3. Screenshots de tela inteira em vez de imagens recortadas

Claude tokeniza imagens por contagem de pixels:

• Screenshot de tela cheia 1.000x1.000 pixels: ~1.334 tokens.
• Recorte preciso 200x200 do mesmo elemento relevante: ~54 tokens.
• Diferença de 25 vezes para a mesma informação útil.

Se você consegue descrever o que está na imagem em 1 ou 2 frases, escreva. Screenshots ganham seu custo quando contêm estrutura visual que linguagem não consegue transmitir: diagrama, layout, mockup. O resto é decoração cara.

4. Modelo errado para a tarefa

A maioria das pessoas usa Sonnet ou Opus por padrão porque parece mais seguro. Na prática, isso aplica multiplicador de 3 a 5 vezes em trabalho que modelo mais barato faria igualmente bem.

Roteador prático:

• Haiku: perguntas rápidas, rascunhos de email, resumos, formatação, brainstorming.
• Sonnet: análise complexa, escrita longa, síntese de pesquisa, código real.
• Opus: raciocínio multi-step genuinamente difícil onde você vai notar a diferença de qualidade.

A maioria das pessoas poderia rodar Haiku em 60-70% das interações diárias sem notar diferença.

5. Conectores ativos em todas as conversas

Cada conector ativo (Google Drive, Slack, Calendar, Linear, Notion) carrega definições de ferramentas no contexto a cada mensagem, use você ou não.

Não é dreno dramático, mas é imposto constante em toda sessão.

Claude tem configuração "carregar ferramentas quando necessário" que muda o padrão de "todos conectores sempre ativos" para "carregar só quando a tarefa pedir". Anthropic recomenda para qualquer pessoa com mais de 10 conectores. Procure no menu "+", em Conectores > Acesso a ferramentas.

6. Prompts vagos que geram loops de correção

Prompt vago não economiza tokens por ser curto. Custa tokens pelas rodadas de correção que gera.

"Melhora isso" produz revisão que você não queria. Aí "não, eu quis dizer o tom, não a estrutura" carrega histórico inteiro mais a revisão indesejada. 3 rodadas disso custam mais que prompt preciso de 40 palavras teria custado.

Como cortar consumo sem mudar seu trabalho

Comece nova conversa quando a tarefa muda

O hábito de maior impacto desse guia, e o que dá menos trabalho.

Quando termina 1 tarefa e começa outra, não continue rolando no mesmo thread. A conversa anterior é peso morto que o Claude relê toda vez que você escreve nova mensagem.

Se precisa de continuidade, use esse prompt no fim da sessão:

Resuma tudo que estabelecemos nessa conversa: decisões tomadas, restrições confirmadas, estado atual do trabalho. Mantenha em menos de 200 palavras. Vou usar isso para começar sessão nova.

Copie a saída. Abra chat novo. Cole como primeira mensagem. Resumo bom tem 500 a 1.500 tokens e substitui 5.000 a 15.000 tokens de histórico.

Edite a mensagem em vez de mandar follow-up

No Claude Chat, dá para clicar em Editar em qualquer mensagem anterior, corrigir, e regenerar. A tentativa que falhou some do contexto ativo em vez de ficar consumindo tokens pelo resto da conversa.

Toda vez que você digita "não, eu quis dizer..." você está adicionando ao histórico e pagando para relê-lo no próximo turno.

Se Claude desviou, edite o prompt que causou, não o seguinte.

Agrupe perguntas em 1 mensagem

3 mensagens separadas custam 3 reloads de contexto inteiro. 1 mensagem com 3 perguntas custa 1 reload.

Em vez de:

"Pode resumir esse artigo?", "Agora liste os pontos principais", "Sugira um título"

Escreva:

Resuma esse artigo, liste os 3 pontos principais e sugira um título. Devolva cada um como bloco separado. Sem comentário entre eles.

Rascunhe a mensagem em bloco de notas antes de enviar. Escrever fora do chat força você a organizar pensamento antes, o que naturalmente gera menos correção.

Converta arquivos antes de subir

Se precisa que Claude analise conteúdo (não layout ou design), extraia o texto antes. Workflow simples:

1. Abra Google Doc em doc.new
2. Cole o texto que precisa que o Claude leia
3. Arquivo > Download > Markdown (.md)
4. Suba o .md em vez do PDF

Página de PDF que custa 2.000 tokens para processar custa cerca de 100 tokens como texto colado limpo. Para páginas web, extensão como MarkDownload salva qualquer página como texto limpo em 1 clique.

Limite o tamanho da resposta

Claude vem com tendência a responder denso. Tokens de saída contam contra seu uso exatamente como tokens de entrada, e toda essa saída verbosa fica no histórico sendo reprocessada a cada mensagem futura.

Essas restrições são gratuitas e imediatas:

Apenas o código. Sem comentário.

Responda em 1 frase.

3 bullets máximo. Sem explicação.

Aplique as edições e devolva apenas o documento atualizado.

Desligue raciocínio estendido para tarefas simples

Com Opus e Sonnet em modo adaptativo, Claude quase sempre raciocina no nível alto padrão. Esse raciocínio usa tokens cobrados como saída.

Para perguntas casuais, edição rápida ou brainstorm, desligue em Buscar e ferramentas. Trocar de modelo começa conversa nova. Ligar e desligar raciocínio dentro do mesmo modelo não.

Como construir sistema que economiza créditos automaticamente

Use Projects para qualquer documento que você consulta mais de uma vez

Se você sobe o mesmo PDF em 5 conversas diferentes, Claude tokeniza ele 5 vezes.

Projects resolvem. Sobe documento na knowledge base do Project 1 vez. Toda conversa dentro daquele Project consulta sem re-upload e sem contar como upload novo.

Em planos pagos, Projects usam recuperação seletiva. Claude puxa só as seções relevantes em vez de carregar tudo no contexto a cada mensagem.

Duas coisas para manter distintas dentro de Projects:

• Project Instructions: carrega em toda conversa do Project, sempre. Mantenha enxuto. Papel, restrições, estilo. Toda palavra aqui custa tokens em toda sessão, para sempre.
• Project Knowledge: seus arquivos, recuperados sob demanda. Coloque material de referência pesado aqui, não nas instruções.

Construa Skills para workflows que rodam mais de uma vez

Toda vez que você explica workflow para o Claude que já explicou antes, está pagando tokens para repetição.

Skills são arquivos de instrução reutilizáveis (SKILL.md) que carregam sob demanda quando Claude reconhece tarefa correspondente.

Forma mais rápida de construir. No fim de qualquer conversa onde você refinou workflow, rode esse prompt:

Baseado em tudo que pedi para você fazer e corrigir nessa conversa, escreva um arquivo SKILL.md que captura esse workflow para eu reusar sem reexplicar. Inclua formato, restrições e regras que apliquei pelas correções.

Salve a saída. Suba no seu Project. A partir desse ponto, você nunca mais reexplica esse workflow.

Combine modelo com tarefa, não com sessão

Versão prática disso é regra que você define 1 vez e segue automaticamente:

• Abra toda sessão no Haiku.
• Suba para o Sonnet quando a saída parecer rasa ou perder complexidade.
• Use Opus só quando você precisar genuinamente de raciocínio multi-step em horizonte longo.

Você nota o teto quando bate nele. Antes de bater, está pagando prêmio por nada.

Agende tarefas pesadas para horários fora de pico

Horários de pico da Anthropic são dias úteis das 5h às 11h Pacífico, equivalente a 9h-15h horário de Brasília. Limites de sessão drenam mais rápido nessa janela.

Para qualquer coisa não sensível ao tempo (análise de documento, sumarização em massa, relatórios semanais, sessões longas de código), mova para tardes ou fins de semana.

Como saber se você finalmente está gastando tokens no que importa

A última peça é medição.

No Claude Code, rode /cost no fim de qualquer sessão para ver quanto aquela sessão gastou. A maior parte das pessoas que começa a checar isso identifica imediatamente:

• A conversa que rodou 25 turnos quando devia ter sido 3.
• O PDF que comeu um quarto do orçamento do dia antes da primeira pergunta.

Se está usando API direto, o objeto usage em toda resposta inclui 2 campos que valem acompanhar:

• cache_creation_input_tokens: o que você pagou para escrever no cache.
• cache_read_input_tokens: o que você economizou lendo do cache.

Se criação está consistentemente alta e leituras próximas de zero, seu cache não está funcionando e você está pagando preço cheio para reprocessar mesmo conteúdo a cada requisição. Leituras em cache custam cerca de 10% do preço de entrada padrão.

O padrão que sinaliza que seus hábitos mudaram: créditos duram até o fim do dia em vez de sumirem na manhã, sem redução de saída. Esse intervalo entre "acabaram os créditos" e "terminei o que precisava" é a medida de quanto era desperdício.

Lista completa para você fechar essa aba sabendo o que fazer

1. Chat novo a cada tarefa, sempre.
2. Edite o prompt que deu errado em vez de corrigir para frente.
3. Agrupe múltiplas perguntas em 1 mensagem.
4. Converta arquivos para texto antes de subir.
5. Recorte screenshots só ao elemento relevante.
6. Limite tamanho da resposta direto no prompt.
7. Desligue raciocínio estendido para tarefas simples.
8. Comece no Haiku, suba só quando sentir o teto.
9. Desabilite conectores que não está usando na conversa atual.
10. Coloque documentos recorrentes em Projects, não no chat.
11. Construa um Skill para qualquer workflow que você explicou mais de duas vezes.
12. Agende tarefas pesadas para fora de pico (após 11h Pacífico em dias úteis ou fins de semana).
13. Rode /cost no fim das sessões para ver onde o gasto foi.

Os founders que tiram mais do Claude não são os que estão no plano mais caro. São os que pararam de tratar cada conversa como rascunho que pode rodar quanto eles quiserem.

Como integrar Claude otimizado com workflow Lovable na sua operação

Essa é a camada que falta na maioria dos guias técnicos sobre Claude. Otimizar consumo é metade da equação. A outra metade é amarrar Claude num workflow que entrega operação real, não só mensagens isoladas.

Quando bem integrado com Lovable, Claude vira motor de raciocínio dentro de um app que sua empresa controla. Você tira ele de "ferramenta de chat solta" e coloca em "operação rodando 24h sem você precisar lembrar de abrir conversa".

Como o workflow integrado funciona na prática

A configuração mais eficiente que vi rodando em empresa brasileira de médio porte:

Tela 1 — Lovable como interface principal

Cliente, equipe interna ou cliente final acessa Lovable, não Claude direto. Lovable tem formulários, dashboards, fluxos visuais.

Tela 2 — Claude como motor de raciocínio nos bastidores

Lovable chama API Claude (Haiku ou Sonnet, raramente Opus) para executar tarefas específicas dentro de cada fluxo. Ex: classificar lead, gerar relatório, traduzir resposta de cliente.

Tela 3 — Integração via Make.com ou Supabase Edge Functions

Faz a ponte entre Lovable e API Claude, com cache e logs.

Por que essa configuração economiza créditos

• Cada chamada é stateless. Não há conversa rolando. Cada tarefa é prompt independente, com contexto enxuto enviado especificamente para aquela operação;
• Você escolhe o modelo certo para cada chamada. Classificação de lead vai com Haiku. Análise estratégica vai com Sonnet. Você quase nunca precisa de Opus em fluxo de operação;
• Cache funciona automaticamente. Prompts repetidos (header, instruções, contexto fixo) entram em cache e são reutilizados a 10% do custo;
• Sem histórico desnecessário. Cada chamada começa limpa. Não tem conversa de 25 turnos consumindo crédito.

Comparativo prático

Operação tradicional com Claude no chat aberto:

• 100 atendimentos de cliente por dia, cada um com conversa de 8-10 turnos;
• Modelo padrão Sonnet ou Opus;
• Consumo médio: 800.000 a 1.500.000 tokens por dia.

Operação integrada Claude + Lovable:

• 100 atendimentos por dia, cada um stateless via Lovable;
• Modelo Haiku para triagem, Sonnet para resposta complexa;
• Cache ativo em prompts fixos;
• Consumo médio: 80.000 a 200.000 tokens por dia.

Diferença: 4 a 10 vezes menos consumo, com melhor controle de qualidade.

Por onde começar

Se você ainda está usando Claude principalmente no chat aberto:

1. Identifique 1 fluxo da sua operação que roda mais de 10 vezes por dia;
2. Construa esse fluxo como tela em Lovable, com formulário no início e resposta estruturada no fim;
3. Conecte Lovable na API Claude via Supabase Edge Function ou Make.com;
4. Use Haiku como padrão. Suba para Sonnet só onde qualidade pedir;
5. Meça consumo antes e depois em 7 dias.

Você vai ver imediatamente onde estavam os tokens desperdiçados.

Stack mínimo recomendado

Para empresa brasileira de médio porte que quer integrar Claude com operação real:

• Lovable como interface (já tem plano gratuito que aguenta MVP);
• Supabase como backend (gratuito até 500MB);
• Claude API com Haiku como padrão (cerca de 10x mais barato que Sonnet);
• Make.com ou n8n como orquestrador opcional para fluxos com mais de 3 etapas.

Custo total dessa stack para operação de 100 atendimentos por dia: cerca de R$ 200 a R$ 500 mensais. Compare com plano enterprise de Claude direto, que custa 10 a 30 vezes mais.

O que esperar depois de aplicar esse guia

Empresas que aplicam consistentemente as 13 dicas do guia + integração Lovable cortam consumo de Claude em 50% a 80%, mantendo ou aumentando volume de operação.

A diferença não está em pagar plano mais caro. Está em entender como Claude conta o que você envia, e construir workflow que respeita esse mecanismo.

A pergunta que fica é simples. Você vai aplicar isso na próxima semana, ou vai esperar mais 1 mês de fatura crescente para começar a otimizar?

Sobre quem produziu esse documento

Rafael Milagre. Founder do Desenvolver com agentes de IA, plataforma B2B de aplicação de IA em empresas brasileiras. Embaixador Lovable Brasil. Mentor de IA no G4.

Stack pessoal aplicado nesse guia: Claude (Sonnet 4.6 e Haiku), Lovable, Make.com, Supabase, ElevenLabs e Typebot. Operação rodando há mais de 2 anos com método replicável em empresas brasileiras de R$ 1M a R$ 100M de faturamento.

Feito!