Harness e Loop Engineering: Por que eles importam mais que o LLM

Se você ainda está passando horas ajustando prompts individuais para que agentes de inteligência artificial escrevam código por você, é hora de mudar a sua abordagem. O verdadeiro diferencial das equipes de alto desempenho não está em encontrar o modelo de linguagem mais recente ou pagar pela API mais cara, mas sim em construir a infraestrutura ao redor dele.

"Você não devia mais estar promptando agentes de código; você devia estar desenhando loops que promptam seus agentes." Essa afirmação de Peter Stinberg, criador do OpenClaw, resume a grande virada de chave no desenvolvimento com IA.

Um exemplo impressionante desse paradigma vem da equipe da LangChain: ao manterem exatamente o mesmo modelo de IA com os mesmos pesos e alterar apenas a infraestrutura e as ferramentas ao redor (o chamado harness), eles saltaram de fora do top 30 para a 5ª posição em um benchmark global. Mas afinal, o que são esses conceitos e por que eles mudam tudo?

1. O que é Harness Engineering?

A palavra harness vem do inglês e refere-se ao arnês ou equipamento de segurança que conecta um cavaleiro ao cavalo, ou um alpinista à parede. No contexto do desenvolvimento com IA, o harness representa tudo o que não é o modelo em si.

Se o modelo de linguagem (LLM) é o motor do carro, o harness é todo o resto do veículo: o chassi, o volante, os freios e a transmissão. Na analogia de andaimes de construção, o harness é a estrutura temporária que molda e determina completamente como o prédio final será erguido.

Em suma, o harness engloba a gestão de contexto, a estrutura das instruções do sistema, as ferramentas fornecidas e os mecanismos de verificação e controle do agente.

2. A Matemática dos erros compostos

Por que o harness é tão crucial? Porque agentes de IA falham de maneira diferente do código imperativo tradicional. A grande ameaça na automação com IA é o acúmulo de etapas e a propagação de erros compostos.

Considere uma tarefa executada em múltiplos passos em sequência:

• Se um processo possui 10 etapas e cada uma tem excelentes 99% de chance de sucesso, a probabilidade final de o processo dar certo é de 90,4%.
• Com 20 etapas, a taxa de sucesso cai para 81,8%.
• Com 50 etapas, a chance de sucesso despenca para apenas 60%.

Como os agentes realizam dezenas de iterações para resolver um problema complexo, pequenas incertezas se multiplicam rapidamente. A principal missão da engenharia de harness é conter essa degradação através de mecanismos defensivos.

Como o Harness combate os erros compostos:

1. Mecanismos de Verificação: Dar ao agente ferramentas para testar o próprio trabalho antes de avançar. Dados oficiais do Claude Code mostram que a verificação autônoma melhora a qualidade do resultado final de 2 a 3 vezes.
2. Checkpoints: Pontos de interrupção estratégicos onde o progresso é validado antes de liberar a próxima fase.
3. Ferramentas Enxutas ("Menos é Mais"): A equipe da Vercel realizou um experimento onde seu agente apresentava mau desempenho. Em vez de adicionar mais capabilities, eles removeram 80% das ferramentas disponíveis. A performance subiu drasticamente porque a IA passou a ter menos oportunidades de escolher a opção errada.
4. Limpeza do Contexto: Janelas de contexto poluídas com histórico irrelevante aumentam exponencialmente as chances de interpretação equivocada.

3. O que é Loop Engineering?

Se o harness é a estrutura do carro, o loop é o piloto automático. A engenharia de loop refere-se a como o agente executa tarefas autonomamente, rodando iterações sucessivas sem a necessidade de intervenção humana constante.

Essa abordagem ganhou tração com o conceito do Ralph Loop (criado por Geoffrey Huntley e batizado em homenagem a Ralph Wiggum dos Simpsons), que consiste em rodar o agente em um loop contínuo até que a tarefa seja concluída.

Os 4 Níveis de Loop (Classificação Anthropic):

1. Nível 1 (Turn-based): O formato clássico. O humano envia um prompt a cada rodada e direciona a execução passo a passo.
2. Nível 2 (Goal-based): Você fornece uma condição de parada objetiva (ex: "rode até todos os testes passarem no terminal" ou "rode até o build compilar"). O agente não para quando *acha* que terminou, mas sim quando o objetivo é verificado.
3. Nível 3 (Time-based): Execuções agendadas ou disparadas por gatilhos de tempo no ambiente, sem você estar presente.
4. Nível 4 (Proactive): O sistema monitora ativamente o ambiente e decide por conta própria o que e quando executar.

Atenção: Criar um loop sem um critério de sucesso objetivo não é engenharia; é apenas um agente queimando tokens e gastando orçamento de API. O verdadeiro gargalo do loop não é o modelo de IA, mas a capacidade do seu verificador.

4. Os 7 Componentes Essenciais de um Harness Robusto

Para construir uma estrutura pronta para rodar em loop, seu harness deve incluir:

• System Prompt / Constituição: As diretrizes invioláveis, limitações e convenções do projeto.
• Ferramentas Selecionadas: Funções estritamente necessárias para evitar ambiguidades.
• Gestão de Janela de Contexto: Decisão consciente do que incluir e descartar no histórico.
• Mecanismos de Verificação: Executores de testes unitários, linters e validadores de código.
• Memória Persistente: Registro de aprendizados entre sessões para evitar a repetição de erros.
• Sandboxes: Ambientes isolados para rodar códigos e chamadas de API em segurança.
• Hooks de Intervenção: Padrões que acionam revisões automáticas ou humanas em cenários críticos.

5. Como aplicar isso no seu dia a dia Dev

Você provavelmente já pratica engenharia de harness sem saber. Para otimizar seu fluxo de trabalho com agentes de IA, conecte-os às boas práticas de engenharia de software:

• Arquivos de Convenção (ex: CLAUDE.md ou AGENTS.md): Mantenha um arquivo na raiz do repositório detalhando padrões de arquitetura e convenções do projeto. Isso serve como o system prompt vivo do projeto.
• Spec-driven Development: Separe rigorosamente a fase de planejamento da fase de execução. Escreva e aprove a especificação antes de pedir para a IA codificar.
• TDD (Test-Driven Development): Escrever testes antes da implementação provê tanto a verificação quanto a condição de parada perfeita para loops do Nível 2 (goal-based).

4 perguntas para fazer antes de trocar de LLM

Quando seu agente falhar em uma tarefa, evite trocar imediatamente para um modelo mais caro. Em vez disso, faça o seguinte diagnóstico:

1. Onde o agente está falhando? Falhas de entendimento indicam problemas no system prompt; falhas de execução indicam problemas nas ferramentas/sandbox; erros acumulados pedem verificadores melhores.
2. O agente possui meios de checar seu próprio trabalho? Se não, adicione suítes de testes ou linters.
3. Qual contexto essencial está na sua cabeça, mas não foi documentado no repositório?
4. Qual tarefa do seu projeto possui critério de sucesso 100% objetivo para ser seu primeiro loop autônomo?

Investir no seu harness traz retornos muito maiores do que simplesmente tentar usar modelos maiores. Construa a estrutura correta e veja seus agentes atingirem um novo nível de autonomia e precisão.

Feito!

Como sobreviver à "Inflação dos Tokens" com uma estrutura híbrida e local

Se você acompanha o mercado de tecnologia, certamente percebeu o burburinho recente. O lançamento de supermodelos como o Claude Fable 5 (derivado da poderosa e restrita família Mythos da Anthropic) trouxe um balde de água fria para a comunidade de desenvolvimento: o fim das assinaturas com uso ilimitado.

A era em que usávamos modelos de inteligência artificial de ponta de forma indiscriminada por uma taxa fixa mensal está chegando ao fim. O plano fixo virou um verdadeiro "taxímetro" de créditos e consumo real de tokens.

Mas por que isso aconteceu? E, mais importante, como nós, desenvolvedores e arquitetos de software, podemos nos adaptar a essa nova realidade sem ir à falência?

O Paradoxo da Memória: LLMs vs. Humanos

Para entender o limite dos LLMs, precisamos primeiro desmistificar o que eles são. Existe uma analogia fantástica para isso: a limitação de um LLM é muito parecida com a limitação da mente humana.

Pense bem. Um humano estuda durante anos, lê centenas de livros, faz cursos e consome horas de conteúdo de diversos assuntos. O aprendizado é eterno; sempre haverá algo que ainda não sabemos e precisamos continuar estudando. Porém, por mais inteligente que um profissional seja, ele tem uma capacidade de atenção limitada no momento presente (sua memória de trabalho). Se você lhe entregar um relatório de 1.000 páginas e exigir que ele correlacione instantaneamente uma linha da página 2 com outra da página 900, ele vai falhar ou demorar muito.

O mesmo se aplica aos LLMs:

Memória de Longo Prazo (Treinamento): O modelo foi treinado com bilhões de parâmetros de diversos assuntos. O conhecimento estático está lá.

Memória de Curto Prazo (Janela de Contexto): Na hora de resolver um problema na IDE, o modelo precisa carregar as informações na "janela de contexto". Encher o prompt de dados desnecessários gera sobrecarga cognitiva na IA (alucinações) e, principalmente, consome tokens de forma brutal.

Com as empresas de IA repassando o custo real de infraestrutura para o usuário, carregar contextos gigantescos em modelos proprietários caros tornou-se insustentável. A contabilidade bateu na porta do desenvolvimento de software.

A Rota de Fuga: IA Open Source e Execução Local

Se a "inflação de tokens" encareceu as APIs de nuvem, a comunidade Open Source nos deu a resposta perfeita: rodar modelos menores localmente para tarefas do dia a dia.

Hoje, máquinas comuns de desenvolvimento conseguem rodar com extrema facilidade e fluidez modelos eficientes de até 7B ou 8B parâmetros, como o recente Gemma 4 (Google) ou o Llama 3 (Meta).

Montar um ecossistema de IA local e totalmente gratuito é extremamente simples com três ferramentas:

Ollama (O Motor): Gerencia e executa seus LLMs locais em segundo plano de forma leve e rápida no sistema operacional.

Open WebUI (A Interface): Uma interface web fantástica, idêntica ao ChatGPT, que roda localmente. Ela permite gerenciar conversas, criar prompts do sistema e até fazer RAG (conversar com seus arquivos e PDF locais).

Continue.dev (A Integração na IDE): Uma extensão de código aberto para o VS Code que se conecta diretamente ao seu Ollama local. Ela atua como seu copiloto na geração de código, autocomplete e explicações, direto no editor.

Estratégia Híbrida: Mapeando suas Tarefas para Economizar

Para não ter que abrir mão do poder de modelos gigantescos (como o Claude Fable 5 ou o GPT-4o) quando eles forem realmente necessários, a melhor prática de engenharia é adotar uma abordagem híbrida.

Divida suas tarefas diárias com base no custo computacional e de raciocínio necessário utilizando a tabela de referência abaixo:

Complexidade	Exemplo de Tarefa	Modelo Recomendado	Onde Rodar	Custo por Token
Baixa	Autocomplete de sintaxe, formatação de arquivos JSON, geração de documentação de métodos (Docstrings), refatoração simples de funções.	Gemma 4 2B / 4B ou Qwen 2.5 3B	Local (Ollama + VS Code)	Zero (Custo Local)
Média	Explicação de trechos de arquitetura de código, debug de erros comuns de runtime, geração de testes unitários com base em regras bem definidas.	Gemma 4 12B ou Llama 3.1 8B	Local ou API de baixo custo	Extremamente baixo
Alta	Arquitetura de microsserviços do zero, refatorações profundas aplicando Clean Architecture e SOLID, resolução de bugs complexos de concorrência ou segurança.	Claude Fable 5 ou GPT-4o	API comercial em nuvem	Pago por uso (Taxímetro)

Considerações finais:

O Dev Consciente é o Novo Tech Lead da IA

O "fim do hype" não é um retrocesso; é um amadurecimento saudável do mercado de tecnologia. A ferramenta de IA deixou de ser uma "mágica de uso infinito" para se tornar um recurso de engenharia gerenciável, com custos, limites e arquitetura apropriada.

Como desenvolvedores, nossa missão agora é sermos inteligentes no uso da ferramenta de IA. Ao dominar o ecossistema local com ferramentas como o Ollama e utilizá-lo para 80% do nosso fluxo de trabalho básico, economizamos recursos preciosos para acionar a "artilharia pesada" da nuvem somente quando o desafio realmente exigir.

E você, já montou o seu ecossistema de IA local ou ainda está sofrendo com as contas das APIs na nuvem? Deixe sua experiência nos comentários!

Feito!

Isolamento de Ambientes no Python: Venv vs. Conda Qual escolher?

Se você já passou pela clássica frustração do "na minha máquina funciona, mas no servidor quebrou" ou acabou corrompendo as dependências globais do seu sistema operacional ao instalar uma biblioteca externa, parabéns: você descobriu a necessidade vital dos ambientes virtuais.

No ecossistema Python, duas ferramentas dominam essa arena de isolamento de dependências: o venv (nativo do Python) e o conda (proveniente da distribuição Anaconda/Miniconda). Embora ambos resolvam com primor o problema de isolar bibliotecas, eles operam de maneiras fundamentalmente diferentes sob o capô.

O que é o venv?

O venv é o gerenciador de ambientes virtuais padrão e nativo do Python, disponível nativamente a partir da versão 3.3. Ele foi desenhado com um propósito simples e focado: criar ambientes isolados para projetos Python, utilizando como base a instalação do interpretador Python que já existe de forma global no seu sistema operacional.

Como ele funciona?

Ao inicializar um ambiente usando o comando python -m venv meu_ambiente, ele gera um diretório local que contém cópias e links simbólicos que apontam para o executável do Python do seu sistema. Ao ativar esse ambiente e executar o pip install, os pacotes e suas respectivas versões são instalados isoladamente nesta pasta, sem qualquer interferência com dependências globais ou outros projetos.

O que é o conda?

O conda é um gerenciador de ambientes e também de pacotes multiplataforma de código aberto. Ao contrário do venv (que gerencia estritamente pacotes Python), o conda é agnóstico de linguagem de programação. Ele foi originalmente idealizado pela comunidade de Ciência de Dados, onde os projetos frequentemente demandam dependências complexas e binários de baixo nível written em C, C++, Fortran ou integrações com drivers de GPU.

Criando ambiente virtual no Conda

Exemplo para criar um ambiente virtual no Conda no Python 3.13

conda create --name meu_ambiente python=3.13

Pode instalar as libs junto com a criação do ambiente (Opcional)

conda create --name meu_ambiente python=3.13 numpy pandas scikit-learn

Vantagem: O gerenciador do Conda analisa a compatibilidade de todas as bibliotecas de uma vez só antes de baixar. Ele também instala binários pré-compilados e otimizados para o seu sistema operacional (como otimizações de performance da Intel para o NumPy, por exemplo).

Mas também pode instalar as libs dentro do ambiente virtual com pip

Regra de Ouro (Apenas um cuidado)

Se você optar por instalar depois com o pip, certifique-se sempre de ativar o ambiente primeiro (conda activate meu_ambiente). Se esquecer de ativar, o pip vai instalar Se você optar por instalar depois com o pip, certifique-se sempre de ativar o ambiente primeiro (conda activate meu_ambiente). Se esquecer de ativar, o pip vai instalar

conda activate meu_ambiente

pip install numpy pandas scikit-learn

Desativar o ambiente virtual conda deactivate

Como ele funciona?

Diferente do seu concorrente nativo, o conda não depende de um interpretador Python pré-instalado no sistema. Ele é capaz de baixar e instalar diferentes versões do próprio Python diretamente em cada ambiente de forma totalmente isolada. Ele gerencia binários pré-compilados diretamente de canais de distribuição (como o conda-forge), resolvendo conflitos a nível de sistema operacional.

Tabela Comparativa: Venv x Conda

Característica	venv (nativo)	conda (gerenciador global)
Instalação	Já vem pré-instalado por padrão junto ao Python.	Requer a instalação prévia do Anaconda ou do Miniconda.
Escopo de Pacotes	Gerencia exclusivamente pacotes Python via indexador PyPI.	Gerencia pacotes de qualquer linguagem (Python, C, R, CUDA, etc).
Versão do Python	Usa obrigatoriamente a versão do sistema operacional base.	Permite instalar e isolar qualquer versão do Python por ambiente.
Velocidade de Instalação	Rápida, mas pode gerar conflitos silenciosos de pacotes.	Mais lenta devido à rigorosa análise de resolução de dependências.
Armazenamento (Disco)	Extremamente leve e enxuto.	Moderado a pesado devido ao cache e compilação de binários.

Vantagens e Desvantagens

O clássico venv

Vantagens:
- Sem fricção de configuração: Não necessita de instaladores adicionais. Se você possui o Python na máquina, você já possui o venv pronto para uso.
- Alta eficiência de armazenamento: Os ambientes ocupam pouquíssimo espaço antes da instalação de novas bibliotecas.
- Padrão consolidado no desenvolvimento Web: Excelente para microsserviços, APIs (FastAPI, Flask) e deploys simplificados em containers Docker.

Desvantagens:
- Acoplado ao sistema: Dificulta o teste simultâneo de múltiplos interpretadores de Python sem o auxílio de ferramentas acessórias como o pyenv.
- Dependências não-Python: Falha em resolver dependências que exijam compilações complexas de bibliotecas de sistema C/C++ diretamente na máquina do usuário final.

O canivete suíço conda

Vantagens:
- Isolamento de baixo nível: Perfeito para gerenciar bibliotecas científicas complexas (NumPy, SciPy, TensorFlow) que dependem de otimizações de hardware.
- Portabilidade total: Garante que os pacotes binários de sistema funcionarão de forma idêntica em Windows, Linux ou macOS.
- Flexibilidade de interpretador: Criar um ambiente com Python 3.8 e outro com 3.12 é simples como executar conda create -n env python=3.12.

Desvantagens:
- Overhead de disco: Os binários ocupam consideravelmente mais armazenamento em disco.
- Complexidade extra: Para desenvolvimento de aplicações web convencionais e scripts leves de automação, seu ecossistema pode ser desnecessariamente robusto.

Dica Prática de Engenharia de Software:

Utilize o venv sempre que o deploy final do seu software for baseado em containers Docker enxutos e focados em microserviços Web tradicionais. Reserve o uso do conda para fluxos de trabalho que exijam engenharia de dados, machine learning ou computação científica de alto desempenho.

Referências

https://docs.conda.io/projects/conda/en/latest/user-guide/install/index.html

Feito!

Upload de arquivos no desenvolvimento de software do jeito certo

Para quem está de fora ou mesmo para desenvolvedores que estão iniciando na carreira, a funcionalidade de upload de arquivos parece uma das tarefas mais simples e triviais do desenvolvimento de software. A experiência do usuário moderno é quase mágica: basta arrastar uma foto de perfil ou um vídeo pesado para uma caixinha na tela, e o navegador faz o resto. No entanto, por trás dessa interface amigável e minimalista, esconde-se uma complexidade arquitetural gigantesca.

Se você lida com o desenvolvimento de sistemas escaláveis, sabe que tratar o upload de arquivos simplesmente como um POST tradicional que recebe um binário e o cospe em um diretório ou banco de dados é uma receita certa para o desastre. Neste artigo, vamos explorar por que essa abordagem falha, as dores do crescimento de uma infraestrutura e como desenhar uma arquitetura robusta inspirada nos padrões de grandes players de tecnologia.

O perigo da abordagem tradicional: Banco de Dados e diretórios locais

Quando começamos a construir uma aplicação monolítica rodando em um único servidor, a solução mais óbvia e simples é criar um endpoint clássico (como um POST /upload/foto), capturar o arquivo na aplicação e tomar uma de duas decisões:

1. Salvar o binário diretamente no banco de dados: Utilizando tipos como BLOB (Binary Large Object) ou BYTEA.
2. Salvar em um diretório local protegido: Armazenar o arquivo fisicamente no sistema de arquivos do próprio servidor que roda a aplicação, guardando apenas o caminho relativo no banco.

Embora a segunda opção seja muito superior à primeira por manter o banco de dados limpo, ambas esbarram em limites severos quando o sistema começa a escalar:

• Saturação do Banco de Dados: Salvar arquivos pesados direto no banco destrói a performance das consultas, infla o tamanho dos backups rapidamente e inviabiliza a aplicação mesmo sob tráfego moderado. Banco de dados foi feito para dados relacionais e transacionais, não para mídia.
• O Gargalo da Escalabilidade Horizontal (Stateless): Se sua aplicação crescer e você precisar subir múltiplas instâncias do seu backend atrás de um Load Balancer (balanceador de carga), o diretório local se torna um problema de estado. Se o usuário faz o upload de uma imagem que cai no Servidor A, quando ele tentar visualizar o arquivo e a requisição cair no Servidor B, o arquivo simplesmente não estará lá.
• Consumo de Recursos de I/O e Banda: Processar leitura e escrita de gigabytes de dados diretamente no seu servidor de aplicação consome processamento (CPU), memória e largura de banda preciosos, impedindo que o servidor responda rapidamente a requisições HTTP leves e normais de outros usuários.

Pilares de uma arquitetura de Upload moderna e escalável

Para desatar esses nós e permitir que seu sistema suporte o upload de arquivos gigantescos, como vídeos de dezenas de gigabytes, sem derrubar a infraestrutura, o ecossistema moderno adota padrões consolidados de System Design. Abaixo estão os conceitos fundamentais para mudar o patamar da sua aplicação:

1. Divisão em pedaços (Chunking) e validação de integridade (Checksums)

Arquivos imensos não se comportam bem em conexões de rede instáveis. Em redes móveis ou conexões lentas, transmitir um arquivo único de 5 GB é inviável: se a rede oscilar nos 95%, todo o progresso é perdido. A solução para isso é o Chunking: o cliente divide o arquivo em dezenas de pedaços menores (ex: 50 blocos de 100 MB) antes do envio.

Aliado a isso, utilizamos o Checksum. O checksum funciona como uma "impressão digital" matemática calculada com base nos bits do arquivo. Com ele, o servidor consegue verificar se o arquivo não foi corrompido durante a transmissão e, em caso de interrupção, o sistema sabe exatamente quais pedaços (chunks) faltam receber para retomar o upload exatamente de onde parou, garantindo segurança contra fraudes na retomada do arquivo.

2. Desacoplamento total com Object Storage (Blob Store)

Na engenharia de software moderna, as instâncias de backend devem ser o mais stateless (sem estado) possível. Os dados transacionais e metadados (como o ID do usuário, tamanho do arquivo, tipo de mídia e status do processamento) continuam indo para o seu banco de dados relacional (ex: PostgreSQL). No entanto, o arquivo binário em si é direcionado para um serviço especialista em armazenamento de objetos grandes, amplamente conhecidos como Blob Stores, tais como o AWS S3, o Google Cloud Storage ou o Cloudflare R2.

3. Upload direto via presigned URLs (URLs Pré-Assinadas)

Se enviarmos o arquivo para a Blob Store fazendo-o passar por dentro do nosso servidor, ainda estaremos sofrendo com o gargalo de banda de rede e processamento. Para eliminar esse intermediário, o backend atua apenas como um orquestrador de segurança:

• O cliente avisa ao backend que deseja realizar o upload de um arquivo e envia os metadados.
• O backend valida se o usuário tem permissão, faz as checagens de segurança e solicita ao provedor de storage uma Presigned URL (uma URL temporária e autenticada com chaves criptográficas embutidas).
• O backend devolve essa URL para o cliente, e o navegador faz o upload do arquivo binário pesado diretamente para o storage na nuvem, sem consumir um único bit de banda do seu servidor principal.

4. Processamento assíncrono com background Jobs

O fluxo de vida do arquivo não termina quando o upload é concluído. Sistemas profissionais utilizam filas de mensageria e workers em segundo plano para realizar processamentos necessários de forma assíncrona:

• Transcodificação e Compressão: No caso de vídeos, comprimir e gerar arquivos em diferentes resoluções (480p, 720p, 1080p). No caso de imagens, redimensionar ou otimizar para formatos mais leves no cliente ou no backend.
• Varredura Antivírus (Malware Scan): Nunca confie no arquivo enviado pelo usuário. Rotinas em segundo plano devem escanear o arquivo em busca de ameaças antes de marcá-lo como "pronto" no banco de dados.
• Rotinas de Limpeza (Clean-up Jobs): Se um usuário iniciar um upload em pedaços e abandonar o processo no meio do caminho, esses blocos órfãos consumirão espaço e custo. Jobs agendados limpam periodicamente uploads inacabados.

A revolução dos custos: O fator Cloudflare R2

Embora AWS S3 e Google Cloud Storage dominem amplamente o mercado corporativo, um grande divisor de águas recente na arquitetura de mídias é o Cloudflare R2. O modelo tradicional de nuvem cobra pelo armazenamento (por GB guardado) e pelas chamadas de API, mas impõe taxas pesadas sobre o egresso de dados (data egress fees), ou seja, você paga caro por cada gigabyte que sai do storage para ser consumido pelos seus usuários na internet.

O R2 rompeu esse modelo ao eliminar totalmente as taxas de egresso. Para aplicações de alta intensidade de leitura, como plataformas de streaming, blogs com muitas imagens ou distribuição de software, essa mudança arquitetural reduz custos drasticamente e permite uma integração nativa e veloz com redes de entrega de conteúdo (CDNs).

Considerações finais

Migrar o modelo mental de salvar arquivos localmente em diretórios ocultos do servidor para uma infraestrutura distribuída com URLs Pré-Assinadas e Object Stores é o verdadeiro passo que separa aplicações amadoras de sistemas resilientes e prontos para produção em larga escala. Ao desonerar seu backend do tráfego pesado e delegar o armazenamento para serviços especialistas, você garante que sua aplicação possa escalar horizontalmente de forma infinita, segura e financeiramente sustentável.

Feito!

Blindando o servidor SSH na VPS e EC2 contra bots

Você acabou de criar uma VPS ou uma instância EC2 na AWS. Ainda nem configurou direito o servidor e, pasme, já existem bots tentando invadir. Não é exagero. Em menos de 15 minutos após ligar uma máquina na nuvem, os primeiros acessos suspeitos começam a aparecer no log do SSH.

Bots varrem a internet o tempo todo. Eles testam combinações de root, ubuntu, admin, debian com senhas fracas na esperança de encontrar uma porta aberta e mal configurada. Se você criar uma instância Ubuntu na EC2, o nome de usuário padrão é ubuntu, e os bots sabem disso. Se for um Debian, tentam admin ou debian. Eles têm listas, e elas são enormes.

A boa notícia? Com 5 configurações básicas você reduz quase que totalmente o risco de acesso indevido. Vamos a elas.

As 5 camadas de proteção

1. Criar um usuário administrador: nunca use o usuário padrão da distro.
2. Autenticação por chave SSH: sem senha, sem risco de força bruta.
3. Desabilitar login como root: o alvo favorito dos bots.
4. Desabilitar login por senha: se não aceita senha, não adianta chutar.
5. Firewall + Fail2Ban: bloqueia quem insiste.

Antes de começar: EC2 × VPS

Se for EC2 (AWS): Quando você cria a instância EC2 na AWS já gera um par de chaves (pública/privada) no console ou via AWS CLI no momento da criação da instância. Você não precisa gerar uma nova chave, mas precisa pular a etapa de gerar e copiar a chave. As demais configurações (criar usuário, desabilitar root, firewall, fail2ban) ainda são necessárias.

Se for VPS: você vai precisar gerar a chave SSH manualmente, copiá-la para o servidor e configurar tudo do zero. O artigo cobre os dois cenários.

1. Atualizar o sistema

Sempre comece com o sistema atualizado. Pacotes desatualizados podem conter brechas conhecidas.

apt update
apt upgrade -y

2. Criar um usuário administrador

O nome de usuário padrão da sua distro (ubuntu, admin, debian etc.) é público. Os bots sabem qual é. Por isso a primeira coisa é criar um usuário só seu, com um nome que só você conhece.

adduser seu-usuario
usermod -aG sudo seu-usuario

Teste se o grupo sudo foi atribuído corretamente:

groups seu-usuario

Se aparecer sudo na lista, seu usuário tem privilégios administrativos. ✅

3. Gerar e configurar chave SSH

A chave SSH é como uma chave de casa: muito mais segura que uma senha. Enquanto senhas podem ser chutadas ou descobertas, a chave criptográfica é praticamente impossível de forjar.

🔹 Gerar a chave (Windows, Linux, macOS)

ssh-keygen -t ed25519 -C "seu-email@exemplo.com"

O comando acima cria um par de chaves usando o algoritmo Ed25519 (moderno, rápido e seguro). Você pode escolher onde salvar, o padrão ~/.ssh/id_ed25519 funciona bem.

Visualizar a chave pública (Linux e macOS)

cat ~/.ssh/id_ed25519.pub

Copie o texto que aparece. É a sua chave pública — pode compartilhá-la. A privada (id_ed25519 sem .pub) jamais deve sair da sua máquina.

Copiar a chave para o servidor (VPS)

Se for uma VPS comum, use o atalho:

ssh-copy-id -i ~/.ssh/nome-da-chave.pub seu-usuario@IP_DO_SERVIDOR

Esse comando instala sua chave pública no arquivo ~/.ssh/authorized_keys do servidor, e você já consegue conectar sem digitar senha.

Conectar ao servidor

ssh seu-usuario@IP_DO_SERVIDOR

Se tudo deu certo, você entra direto, sem pedir senha. 🎉

4. Endurecer a configuração do SSH

Agora vamos ajustar o coração da segurança: o arquivo de configuração do servidor SSH.

sudo nano /etc/ssh/sshd_config

Altere ou adicione as seguintes linhas:

# Desabilita login como root (os bots adoram tentar root)
PermitRootLogin no

# Permite autenticação por chave (é o que você acabou de configurar)
PubkeyAuthentication yes

# Desabilita login por senha (força bruta depende de senha)
PasswordAuthentication no

# Desabilita interação com senha (camada extra)
KbdInteractiveAuthentication no

# Opcional: alterar a porta SSH (fugir do padrão 22)
Port 2222

💡 Atenção para EC2 e VPS: em instâncias Ubuntu da AWS e VPS, existe o arquivo /etc/ssh/sshd_config.d/50-cloud-init.conf que sobrescreve as configurações do sshd_config. Você precisa editar também esse arquivo:

sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf

E adicionar:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Depois de salvar, reinicie o serviço SSH:

sudo systemctl restart ssh

Pronto. A partir de agora, não é mais possível fazer login com root ou com senha. Só entra quem tem a chave privada correta.

5. Firewall com UFW

O UFW (Uncomplicated Firewall) é um firewall simples e direto. Vamos liberar apenas o essencial.

sudo apt install ufw -y

# Bloquear toda conexão que entra (ninguém de fora se conecta sem sua autorização)
sudo ufw default deny incoming

# Liberar toda conexão que sai (você pode baixar pacotes, acessar sites etc.)
sudo ufw default allow outgoing

# Liberar SSH (porta padrão 22)
sudo ufw allow 22/tcp

# Se você alterou a porta SSH, libere a nova porta substituindo pela 22

# Liberar HTTP e HTTPS (para sites e APIs)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Ativar o firewall
sudo ufw enable

Verifique as regras ativas:

sudo ufw status

O UFW agora funciona na seguinte lógica: tudo que chega do exterior é bloqueado por padrão, a menos que você explicitamente libere (como fez com SSH, HTTP e HTTPS). Já tudo que sai do servidor é permitido, você consegue fazer atualizações, acessar APIs, baixar pacotes, tudo normal.

É o princípio do menor privilégio aplicado à rede: nada de fora entra sem permissão, mas o servidor pode se comunicar livremente com o mundo.

6. Fail2Ban o segurança do SSH

O Fail2Ban monitora os logs do sistema e bloqueia temporariamente (por meio do firewall) IPs que fazem muitas tentativas de login com falha. É como um segurança na porta da balada: "já errou a senha 5 vezes? Pode ir embora."

sudo apt install fail2ban -y

# Habilitar para iniciar com o sistema
sudo systemctl enable fail2ban

# Iniciar agora
sudo systemctl start fail2ban

# Verificar se está rodando

sudo systemctl status fail2ban

7. (Bônus) Atualizações automáticas de segurança

Manter o sistema atualizado é fundamental. As atualizações automáticas instalam correções de segurança sem você precisar lembrar.

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure unattended-upgrades

Na tela que aparecer, selecione Sim.

Facilitando a conexão: o arquivo de configuração do SSH

Digitar ssh usuario@IP -p 2222 toda vez é chato. Crie um atalho no arquivo ~/.ssh/config da sua máquina local:

nano ~/.ssh/config

Adicione algo como:

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

Host vps_ou_ec2
    HostName IP_DA_SUA_VPS
    User seu-usuario
    IdentityFile ~/.ssh/id_ed25519
    Port 2222
    ServerAliveInterval 60
    ServerAliveCountMax 3

Agora, para conectar, basta digitar:

ssh vps_ou_ec2

E para testar a conexão com GitHub:

ssh -T git@github.com

Se tudo estiver certo, o GitHub responde algo como:

Hi seu-usuario! You've successfully authenticated, but GitHub does not provide shell access.

Investigando: como ver quem está tentando entrar

Quer ver os bots em ação? Esses comandos mostram em tempo real as tentativas de acesso no seu servidor:

# Ver tentativas de login em tempo real
sudo tail -f /var/log/auth.log

# Ver bloqueios do Fail2Ban
sudo tail -f /var/log/fail2ban.log

# Status detalhado do Fail2Ban para o SSH
sudo fail2ban-client status sshd

O log do auth.log vai mostrar dezenas (ou centenas) de tentativas de login vindo de IPs do mundo inteiro. O fail2ban.log vai mostrar os IPs que foram bloqueados. É assustador e ao mesmo tempo satisfatório saber que o Fail2Ban está fazendo o trabalho dele.

Testando a blindagem

Depois de aplicar todas as configurações, é hora de confirmar que está tudo funcionando. O teste é simples: tente conectar sem usar a chave SSH.

Na sua máquina local, tente conectar como root:

ssh root@IP_DO_SERVIDOR

Você deve receber algo como:

root@IP_DO_SERVIDOR: Permission denied (publickey).

Agora tente com o usuário que você criou, também sem informar a chave:

ssh seu-usuario@IP_DO_SERVIDOR

O resultado é o mesmo:

seu-usuario@IP_DO_SERVIDOR: Permission denied (publickey).

✅ Isso é bom! A mensagem Permission denied (publickey) significa que o servidor rejeitou a conexão porque você não apresentou uma chave válida. O servidor nem sequer pediu senha, porque a autenticação por senha está desabilitada. Exatamente o que queremos.

Agora faça o teste com a chave para confirmar que o acesso legítimo continua funcionando:

ssh -i ~/.ssh/sua-chave.pub seu-usuario@IP_DO_SERVIDOR

Se entrou sem pedir nada, parabéns! 🎉 Sua VPS ou EC2 está blindada contra bots, força bruta e hackers metidos a cracker.

Recapitulando

Com esses passos, seu servidor passa de "porta escancarada" para "cofre blindado". Veja o resumo:

Configuração	Protege contra
Usuário personalizado	Bots que tentam nomes de usuário padrão
Chave SSH	Força bruta de senha
Root desabilitado	Ataques direcionados ao root
Senha desabilitada	Qualquer ataque baseado em senha
UFW + Fail2Ban	Varreduras e múltiplas tentativas

Considerações finais

Configurar segurança no SSH não é frescura, é responsabilidade de quem coloca um servidor na internet. Os bots não dormem. Enquanto você lê este artigo, centenas de scripts automatizados estão escaneando IPs atrás de uma porta 22 aberta com PermitRootLogin yes e senha fraca.

Gaste 15 minutos aplicando essas configurações. Sua VPS/EC2 com seus dados, agradecem.

Feito!

Os conceitos de Engenharia de Software que separam Devs Juniores de Seniores

No início da carreira na programação, é comum focarmos muito em sintaxe de linguagem, frameworks e na lógica de criar pequenas funcionalidades. No entanto, conforme os sistemas crescem e passam a atender milhões de usuários, os desafios mudam de figura. O que diferencia um desenvolvedor Júnior de um desenvolvedor Sênior não é apenas o domínio do código, mas o conhecimento em System Design (Arquitetura de Sistemas Distribuídos) e a capacidade de prever falhas antes que elas aconteçam.

Abaixo, explicamos de forma didática os principais conceitos de arquitetura que você precisa dominar para elevar o nível da sua carreira.

1. Idempotência

Idempotência é a garantia de que, não importa quantas vezes você execute a mesma ação, o resultado final e os efeitos colaterais serão exatamente os mesmos da primeira execução. Um exemplo clássico ocorre em transações financeiras: se você faz um PIX e a rede oscila, o aplicativo pode tentar reenviar a requisição. Um sistema idempotente gera uma chave única (geralmente um hash baseado nos dados da transação) e bloqueia a segunda tentativa se ela acontecer dentro de um curto intervalo de tempo, evitando cobranças duplicadas.

2. Transações Distribuídas

Em sistemas monolíticos antigos, garantir que tudo funcionasse ou falhasse junto era fácil usando o banco de dados. Em arquiteturas modernas de microsserviços, surge o desafio das Transações Distribuídas. Imagine comprar um pacote de viagens: o sistema precisa reservar o voo na companhia aérea, o quarto no hotel e o carro na locadora. Se o hotel falhar, o voo precisa ser cancelado. Para resolver isso, utilizam-se padrões como o Two-Phase Commit (2PC) ou o padrão Saga (Saga Pattern), que coordena transações compensatórias para desfazer passos anteriores em caso de erro.

3. Consistência Eventual

Em sistemas globais, atualizar um dado em todos os servidores do mundo instantaneamente é impossível devido à latência da rede. A Consistência Eventual aceita que os dados fiquem desatualizados por alguns segundos ou minutos, mas garante que, eventualmente, todos os servidores convergirão para o mesmo estado correto. Um exemplo prático é o contador de visualizações de um vídeo no YouTube: você no Brasil pode ver um número ligeiramente diferente de alguém acessando na China, mas depois de um tempo os valores se igualam.

4. Réplicas de Leitura (Read Replicas)

A imensa maioria das aplicações web lida com muito mais leituras do que escritas (por exemplo, milhares de pessoas leem uma postagem de rede social, mas poucas de fato escrevem uma). Para não sobrecarregar o banco de dados principal, cria-se uma estratégia onde apenas uma instância recebe as escritas (banco de Write) e várias cópias sincronizadas lidam apenas com as consultas dos usuários (bancos de Read).

5. Teorema de CAP

Este teorema dita que um sistema distribuído só pode garantir duas de três propriedades ao mesmo tempo: Consistência (C), Disponibilidade (A) e Tolerância a Partições de Rede (P). Como falhas de rede (Partições) são inevitáveis na realidade, o Teorema de CAP na prática força o arquiteto sênior a tomar uma decisão difícil quando a rede falha: ou o sistema nega a requisição para manter os dados idênticos (priorizando Consistência) ou aceita a alteração correndo o risco de dessincronização temporária (priorizando Disponibilidade).

6. Sistemas de Mensageria e Garantias de Entrega

Ao trafegar dados de forma assíncrona por ferramentas como o Apache Kafka, existem três decisões arquiteturais sobre como as mensagens serão entregues:

• At Most Once (No máximo uma vez): A mensagem é enviada; se falhar no caminho, é perdida. Prioriza velocidade.
• At Least Once (Pelo menos uma vez): A mensagem é reenviada até haver confirmação. Evita perda de dados, mas pode gerar duplicatas.
• Exactly Once (Exatamente uma vez): O sistema garante que a mensagem será processada uma única vez. É o cenário ideal, porém o mais complexo e custoso de se implementar devido ao alto processamento necessário de coordenação.

7. Backpressure (Pressão de Retorno)

Imagine um sistema raspador de dados (Web Scraper) que baixa 20 imagens por segundo (Produtor), mas o serviço de compactação dessas imagens só consegue processar 5 por segundo (Consumidor). Sem um controle, a memória ou a fila do consumidor vai estourar. Backpressure é o mecanismo de comunicação reversa que permite ao Consumidor avisar o Produtor: "Estou cheio, diminua a velocidade de envio", salvando a estabilidade da infraestrutura.

8. Thundering Herd Problem

Esse problema ocorre quando um recurso muito requisitado que estava guardado em cache expira repentinamente. No exato segundo da expiração, milhares de usuários que estavam lendo do cache tentam acessar o banco de dados principal de forma simultânea. Essa avalanche repentina de requisições pode derrubar o banco de dados instantaneamente.

9. Celebrity Problem (ou Hot Shard)

Para escalar bancos de dados, costuma-se dividi-los em pedaços menores chamados shards. Se o seu sistema armazena dados de usuários comuns divididos igualmente, o tráfego flui bem. Mas se uma celebridade gigantesca cai em um shard específico, todo o tráfego da rede social vai se concentrar naquela única máquina. Esse nó específico se torna um "Hot Shard", exigindo estratégias avançadas de distribuição para não colapsar.

10. Circuit Breaker (Disjuntor)

Inspirado nos disjuntores elétricos residenciais, este padrão monitora chamadas para serviços externos. Se uma API externa começa a falhar repetidamente, o Circuit Breaker "abre o circuito" e impede que novas requisições percam tempo tentando bater naquela API indisponível. Em vez disso, ele retorna imediatamente um erro amigável ou um caminho alternativo, protegendo os recursos internos do seu próprio sistema.

11. Feature Flags

Feature Flags são interruptores condicionais inseridos no código que permitem ativar ou desativar uma funcionalidade dinamicamente sem a necessidade de realizar um novo deploy. São extremamente úteis para realizar testes com pequenos grupos de usuários (testes beta) ou lançar atualizações de forma gradual. Contudo, desenvolvedores seniores alertam: esquecer de remover as flags antigas transforma o código em uma gambiarra difícil de manter.

12. Schema Evolution

Sistemas evoluem e as estruturas de seus dados mudam. Schema Evolution refere-se à habilidade de alterar o formato de uma tabela de banco de dados, de uma API ou de uma mensagem de evento mantendo a retrocompatibilidade. Isso garante que sistemas legados ou parceiros externos que ainda usam a estrutura antiga não quebrem quando você lançar uma atualização.

13. Migrations Conscientes

Muitos juniores cometem o erro clássico de enviar uma alteração de banco de dados (Migration) adicionando um novo campo obrigatório (Constraint NOT NULL) ao mesmo tempo em que sobem o código novo da aplicação. Durante o processo de alteração, o banco de dados pode sofrer um travamento completo (lock). Seniores planejam migrações críticas de forma faseada para mitigar riscos, utilizando passos intermediários descritos a seguir.

14. Backfill

O Backfill é o processo de preencher de forma incremental e segura dados retroativos em campos novos que foram criados no banco de dados. Em vez de travar o banco atualizando milhões de linhas de uma vez só, o desenvolvedor sênior cria o campo como opcional e roda rotinas em lotes pequenos (batches) em horários de menor movimento para popular o histórico.

15. Dual Rights (Escritas Duplas)

Estratégia usada em migrações complexas de infraestrutura onde a aplicação passa a salvar as informações simultaneamente em duas fontes de dados diferentes (o banco antigo e o banco novo). Isso permite validar a consistência e o comportamento do novo ambiente em tempo real sem desligar o sistema antigo.

16. Shadow Tables

Shadow Tables (Tabelas Espelho) funcionam como cópias ocultas que replicam as operações das tabelas principais em produção. Elas servem para testar migrações massivas em larga escala, permitindo que os desenvolvedores analisem a performance e possíveis erros de uma alteração sem impactar a experiência do usuário real.

17. Algoritmos de Rate Limit

Rate Limit é o ato de limitar quantas requisições um cliente pode fazer para proteger a API contra abusos ou ataques. Existem quatro principais maneiras de fazer isso:

1. Fixed Window: Define uma janela rígida de tempo (ex: 100 requisições por hora). Se estourar o limite, bloqueia até a virada da hora cheia.
2. Sliding Window: Uma janela de tempo móvel e dinâmica que avalia o histórico recente do usuário segundo a segundo, evitando abusos nas bordas do relógio.
3. Token Bucket: Um balde virtual acumula fichas (tokens) em uma taxa constante. Cada requisição gasta uma ficha. Permite que o usuário faça rajadas rápidas de requisições se o balde estiver cheio, mas o bloqueia quando as fichas acabam até que novas caiam.
4. Leaky Bucket: Semelhante ao balde de fichas, mas as requisições entram no balde e saem por um pequeno furo na base em uma velocidade perfeitamente constante e controlada, suavizando picos de tráfego.

18. Cache Invalidation

Existe uma famosa frase na computação que diz: "Só existem dois problemas difíceis na engenharia de software: invalidação de cache e escolher nomes para coisas". Guardar dados na memória (Cache) acelera o sistema, mas saber o momento exato de apagar esse cache quando o dado original muda no banco — para evitar que o usuário veja informações obsoletas — é um dos maiores desafios de arquitetura.

19. Cold Start

Muito comum em arquiteturas Serverless (como AWS Lambda), o Cold Start (Início Frio) é a latência ou demora que acontece quando uma função que estava desligada recebe uma requisição após muito tempo ociosa. O provedor de nuvem precisa criar uma máquina virtual do zero, baixar o código e iniciar o ambiente antes de responder ao usuário, gerando um gargalo inicial de performance.

20. Design para a Falha (Design for Failure)

Os desenvolvedores juniores programam assumindo que a rede nunca vai oscilar, que o banco de dados estará sempre online e que as APIs externas nunca vão falhar. Já os desenvolvedores seniores programam assumindo o oposto: tudo o que puder falhar, vai falhar em algum momento. O conceito de Design para a Falha dita que a arquitetura do sistema deve ser resiliente o suficiente para continuar funcionando (mesmo que de forma limitada ou degradada) quando partes dela colapsarem, utilizando mecanismos de redundância, retentativas inteligentes (com recuo exponencial) e caminhos de fallback automatizados.

Considerações finais

O maior aprendizado que diferencia os níveis de maturidade técnica é entender que não existem soluções mágicas, existem tradeoffs (compensações). Cada escolha arquitetural resolve um problema ao custo de introduzir uma nova complexidade. O papel de um desenvolvedor sênior é olhar para o cenário de negócios, analisar os prós e contras de cada conceito listado e escolher a ferramenta que melhor equilibra custo, segurança e escalabilidade.

Feito!

O Guia do Full Cycle Developer: Por que escrever código virou Commodity na era dos agentes de IA

Se você acompanha o mercado de tecnologia, certamente já ouviu que "a programação acabou" ou que "qualquer um agora é desenvolvedor". Desde o impacto global gerado em 30 de novembro de 2022, ferramentas baseadas em Large Language Models (LLMs), como Claude Code, Gemini, ChatGPT, Perplexity e etc, transformaram radicalmente a nossa rotina.

No entanto, há uma grande confusão no ar. Antes de entendermos o novo papel do desenvolvedor, precisamos dar um passo atrás e ajustar os termos técnicos para não cair em clichês generalistas.

Desmistificando o Termo "IA"

Hoje, a sigla IA (Inteligência Artificial) tem sido usada erroneamente como um guarda-chuva para absolutamente tudo. Para quem está iniciando na área, é vital compreender que a IA é, na verdade, um amplo subcampo da Ciência da Computação.

Dentro desse universo, temos ramificações profundas:

• Machine Learning (Aprendizado de Máquina): Algoritmos que aprendem a partir de padrões de dados.
• Deep Learning (Aprendizado Profundo): Redes neurais artificiais complexas que baseiam os modelos de linguagem modernos.
• Fine-Tuning (Ajuste Fino): O processo de treinar um modelo existente em um conjunto de dados específico para especializá-lo em uma tarefa.

Por isso, quando geramos código no VS Code ou no terminal, não estamos usando "a IA" de forma genérica. O termo correto é ferramenta / agente de IA ou ferramenta do provedor de LLM. O que você tem em mãos é um modelo de linguagem avançado atuando como um assistente, e não uma consciência mágica que resolve problemas de negócios sozinha.

O cliente não lê código: O foco no negócio

Com a sintaxe democratizada por essas ferramentas de LLM, escrever código isolado virou commodity. O cliente final, aquele que financia o projeto, não se importa com a stack utilizada, com a metodologia aplicada, e muito menos lê as linhas de código do repositório.

O que importa para o cliente é uma única coisa: o sistema atende ao que foi solicitado e resolve o negócio dele?

É aqui que o mero digitador de código perde espaço e se destaca o verdadeiro Engenheiro de Software. O ciclo de valor de um projeto maduro começa muito antes do banco de dados e termina muito depois do código pronto.

O Ciclo do Desenvolvimento Moderno (Full Cycle)

Para entregar valor real hoje, o profissional precisa dominar o fluxo de ponta a ponta, assumindo a postura de um Full Cycle Developer. Esse ecossistema se divide em etapas claras:

1. Engenharia de Requisitos e Prototipagem

Antes de modelar uma única tabela ou abrir a IDE, o processo começa com o desenho na folha de papel ou ferramentas como o Figma.

• Escrita de Requisitos: Definição clara dos Requisitos Funcionais (RFs) e Não Funcionais (RNFs).
• Validação Visual: O protótipo de tela permite que o cliente aprove o fluxo de negócio antes que a equipe gaste tempo e recursos com a modelagem ou codificação.

2. Arquitetura e Modelagem

Com o escopo e protótipos aprovados pelo cliente, inicia-se a engenharia de dados: desenhar a modelagem das tabelas do banco de dados consciente e escolher os padrões arquiteturais corretos que garantam a manutenibilidade do sistema.

3. Implementação e Testes de Valor

Aqui, as ferramentas do provedor de LLM brilham, atuando de forma altamente produtiva. No entanto, o desenvolvedor dita as regras e garante a qualidade:

• Testes Unitários de Negócio: Cada funcionalidade implementada deve vir acompanhada de testes unitários que garantam o valor do negócio e impeçam que bugs cheguem em produção por falta desses testes.
• Métricas de Qualidade: Integração contínua com ferramentas como o SonarQube para assegurar uma cobertura mínima de 80% do código implementado.

4. DevOps e Deploy Automatizado

O ciclo se fecha quando a solução está em produção gerando valor. O desenvolvedor moderno precisa ter conhecimentos além da engenharia de software tradicional, integrando práticas de DevOps para preparar o ambiente com pipelines de CI/CD automatizadas em uma VPS ou plataforma cloud.

Se o sistema não está em produção de forma segura e automatizada, o trabalho não terminou.

O verbo mudou: Da Construção para a Orquestração

A pergunta clássica que muitos fazem é: "Existe um programador que consegue codar com maior eficiência que a IA?"

A resposta correta é: Depende do seu prompt. A ferramenta de IA é um amplificador do seu conhecimento. Se você tiver experiência em engenharia de software e DevOps, sabe aplicar um prompt assertivo que obtém resultado de um Engenheiro de Software Sênior. Do contrário, o resultado será equivalente ao de um desenvolvedor júnior ou .

Podemos resumir essa dinâmica na seguinte relação matemática:

Resultado Final = Conhecimento de Engenharia × Capacidade da Ferramenta de IA

No fim das contas, o que são as ferramentas de IA das LLMs? Elas agem como um estagiário ou desenvolvedor júnior brilhante que não tem preguiça para programar e segue rigorosamente o que você colocou no prompt. As ferramentas evoluem, mas a habilidade de traduzir problemas de negócios complexos em softwares estáveis, escaláveis e testados continua sendo uma competência essencialmente humana.

Se o operador tiver conhecimento zero de arquitetura, boas práticas e negócios, a ferramenta do provedor de LLM entregará um código genérico, desconexo e difícil de manter. Por outro lado, nas mãos de um profissional sênior que sabe instruir o agente com contexto técnico e revisar o código de forma crítica, a tecnologia se torna um amplificador brutal de produtividade.

As ferramentas evoluem a cada semana, mas a habilidade de traduzir problemas de negócios complexos em softwares estáveis, escaláveis e testados continua sendo, e sempre será, uma competência essencialmente humana.

Feito!

Instalando o Odysseus na VPS do jeito certo

Sobre o projeto: O Odysseus é uma plataforma avançada de Inteligência Artificial (IA) de código aberto. O principal objetivo da ferramenta é fornecer uma interface de chat e orquestração de Modelos de Linguagem (LLMs) totalmente auto-hospedada (self-hosted), permitindo que desenvolvedores e empresas mantenham total privacidade, controle e soberania sobre seus dados e prompts, sem depender obrigatoriamente de infraestruturas de terceiros. A ideia é utilizar LLMs local, mas pode integrar com Open Router, que inclui diversos LLMs.

Este guia descreve o procedimento técnico para configurar o Odysseus em um VPS Linux através do clone do repositório, build local com Docker Compose, isolamento de rede e criptografia SSL.

1. Atualizar o sistema e instalar as dependências

Acesse o seu servidor via SSH e execute os comandos abaixo para garantir que o sistema operacional esteja atualizado e com o Git, Docker e Docker Compose instalados:

sudo apt update && sudo apt upgrade -y
sudo apt install git docker.io docker-compose-v2 -y
sudo systemctl enable --now docker

2. Configurar o Firewall (UFW)

Proteja a rede permitindo conexões apenas nas portas estritamente necessárias para o funcionamento seguro do serviço:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable

3. Clonar o repositório e configurar o ambiente (.env)

Como a imagem não está disponível centralizada no Docker Hub, faremos o download do código-fonte e faremos o build local do container. Clone o repositório, acesse o diretório clonado e renomeia o .env.example para .env de configuração:

git clone https://github.com/pewdiepie-archdaemon/odysseus.git
cd odysseus
cp .env.example .env

Linhas essenciais no arquivo .env

Abra o arquivo .env com nano .env e certifique-se de configurar e validar estas variáveis críticas:

Chave secreta de criptografia da aplicação (MUDE para uma string longa e segura)

APP_SECRET=MUDE_PARA_UMA_CHAVE_ALTA_E_SEGURA_AQUI

Colocar o seu passoword de admin, no lugar de "-"

ODYSSEUS_ADMIN_PASSWORD=${ODYSSEUS_ADMIN_PASSWORD:-}

Nota: Certifique-se de que a variável de porta está mapeada explicitamente para responder apenas internamente (127.0.0.1:7000) para evitar que o container fique exposto diretamente à internet sem a proteção do proxy reverso.

4. Construir e iniciar os containers

Com o ambiente configurado, execute o comando abaixo para subir e iniciar a aplicação em segundo plano (modo daemon):

docker compose up -d --build

5. Configurar o Nginx como Proxy Reverso

Instale o Nginx para receber as requisições HTTP/HTTPS da internet e repassá-las internamente para a porta do Docker:

sudo apt install nginx -y

Crie o arquivo de configuração para o seu domínio em /etc/nginx/sites-available/odysseus com o seguinte conteúdo:

server {
listen 80;
server_name dominio.com;

location / {
proxy_pass http://127.0.0.1:7000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

Ative a configuração criando o link simbólico e reinicie o servidor web:

sudo ln -s /etc/nginx/sites-available/odysseus /etc/nginx/sites-enabled/

sudo systemctl restart nginx

6. Instalar o certificado SSL (HTTPS)

Criptografe o tráfego de dados e garanta a segurança dos prompts utilizando um certificado digital gratuito da Let's Encrypt através do Certbot:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d seu-dominio.com

7. Definir permissões estritas no diretório

Por fim, bloqueie o acesso direto às pastas de dados geradas no host para outros utilizadores do sistema operacional:

chmod 700 ./odysseus_data

Feito!

O mito dos novos LLMs: Descubra onde está o segredo dos LLMs de agentes de IA

Se você tem acompanhado o mercado de Inteligência Artificial (IA) recentemente, deve ter notado um padrão. A cada poucas semanas, um grande provedor de nuvem ou laboratório de IA anuncia um novo modelo com gráficos impressionantes, prometendo revolucionar o desenvolvimento de software. No entanto, quem entende o que acontece "por debaixo dos panos" já percebeu a realidade: as LLMs brutas estagnaram em termos de capacidade cognitiva pura.

Os benchmarks inflados apresentados pelos influenciadores e vendedores de cursos com uso de ferramentas de IA tornaram-se falácias para iludir quem não possui uma base técnica sólida. O verdadeiro salto de desempenho e autonomia não vem mais do tamanho da rede neural, mas sim da engenharia aplicada ao redor dela.

A estagnação das LLMs e a ilusão dos benchmarks

Aumentar o número de parâmetros ou treinar modelos com mais dados textuais parou de trazer os retornos exponenciais de antes. Quando uma empresa anuncia que seu novo modelo superou o anterior em 2% ou 3% em um benchmark como o MMLU ou HumanEval, isso quase sempre se traduz em zero impacto no mundo real.

Esses testes tornaram-se ambientes controlados e, muitas vezes, os dados dos próprios benchmarks acabam vazando no conjunto de treinamento dos modelos. Para o desenvolvedor que precisa resolver problemas complexos de arquitetura, segurança ou depuração em sistemas legados, o modelo bruto continua cometendo as mesmas alucinações de sempre.

O Verdadeiro Segredo: O Harness Aplicado ao Agente

Se o modelo base não é mais o diferencial, onde está o segredo? A resposta está no harness (a armadura ou infraestrutura de orquestração) que envolve a LLM. Um agente de elite só é eficiente porque possui um ecossistema robusto de ferramentas, gerenciamento de estado e loops de feedback que estendem a capacidade do modelo.

O que influenciadores vendem como "a genialidade do Claude Code", por exemplo, nada mais é do que uma excelente engenharia de software local. O segredo do sucesso dessas ferramentas comerciais inclui:

• Sistemas de busca especializados: Ferramentas nativas de indexação e busca de código baseadas em AST (Abstract Syntax Tree) ou ferramentas como grep otimizado.
• Edição por Diff: Em vez de pedir para a LLM reescrever um arquivo inteiro de 2000 linhas (o que gera falhas e estouro de contexto), o harness intercepta a resposta e aplica apenas modificações cirúrgicas (diffs).
• Ambientes de Execução Isolados: A capacidade de executar testes unitários em tempo real, ler os erros do terminal e corrigir a si mesmo antes de entregar o código ao usuário.

Criando suas próprias Skills sem depender de terceiros

Quando você entende esse conceito, percebe que pode construir seu próprio sistema de agentes modulares. Você pode criar "Skills" específicas para cada propósito do ciclo de desenvolvimento, encapsulando regras de negócio e ferramentas customizadas.

+-------------------------------------------------------+
|                    SEU HARNESS CORE                   |
+-------------------------------------------------------+
                           |
        +------------------+------------------+
        |                  |                  |
        v                  v                  v
+---------------+  +---------------+  +---------------+
| SKILL: STACK  |  | SKILL: QA     |  | SKILL: SECURITY|
| - Frontend    |  | - Testes Unit |  | - SAST / DAST |
| - Backend     |  | - Regressão   |  | - Sandboxing  |
+---------------+  +---------------+  +---------------+

Ao isolar essas especialidades, você remove a dependência de plataformas proprietárias. Se uma Skill de segurança (Security) for bem blindada com ferramentas de análise estática e validação rigorosa, você obtém uma capacidade equivalente ou superior aos recursos restritos de grandes corporações.

A soberania tecnológica contra bloqueios comerciais

Depender exclusivamente de ferramentas prontas de terceiros coloca seu fluxo de trabalho sob risco constante. Interrupções repentinas no fornecimento de recursos avançados por motivos regulatórios ou comerciais deixam desenvolvedores dependentes sem alternativas imediatas.

A alternativa técnica viável é construir sua própria infraestrutura de agentes. Utilizando protocolos de integração abertos e plugando modelos open-weight altamente eficientes dentro de um harness proprietário, você garante autonomia total sobre suas ferramentas de desenvolvimento.

Considerações finais

O mercado de marketing da IA continuará tentando vender o próximo modelo como o "melhor agente do mundo". Cabe aos engenheiros de software e arquitetos de soluções olhar além do hype, compreender que a inteligência está na orquestração e focar na construção de harnesses robustos, seguros e soberanos.

Feito!

Por que 90% dos Programadores Júnior não conseguem emprego? (E como não ser um deles)

Se você passou os últimos meses estudando, terminou cursos, enviou dezenas de currículos e não obteve retorno, ou pior, travou na hora da entrevista técnica, saiba que você não está sozinho. Existe uma crença de que o mercado de tecnologia está completamente fechado para iniciantes, mas a realidade é diferente: vagas existem, o que falta são candidatos com o nível mínimo de preparo prático.

O mercado saturou de pessoas que assistem a centenas de horas de vídeo, mas nunca escreveram uma linha de código do zero. Para ter sucesso, você precisa entender que as empresas não querem saber quantos certificados você tem, mas sim o que você é capaz de construir com o que aprendeu.

O Grande Insight: Seu Código é o Seu Currículo

Em profissões como arquitetura ou design, os profissionais apresentam portfólios com seus projetos e layouts. Na programação, o seu portfólio é o seu código, e o lugar dele é no GitHub. Enviar um currículo sem o link do seu portfólio de código é o mesmo que tentar uma vaga de design sem mostrar nenhuma arte.

O link do seu perfil deve estar no topo do seu currículo, se possível na primeira linha e em negrito. É a primeira coisa que um recrutador técnico vai olhar.

Os 6 Motivos que Impedem a Contratação de um Júnior

1. Falta de Base Prática

Muitos profissionais iniciantes dominam frameworks modernos, mas falham miseravelmente em conceitos fundamentais. Se você sabe usar ferramentas avançadas, mas não entende como funciona um loop ou uma estrutura de dados, você cairá no primeiro teste técnico.

2. Projetos Inacabados e Clones de Tutoriais

Ter um perfil cheio de repositórios com apenas um commit demonstra que você começa as coisas e nunca as termina. Vale muito mais ter um único projeto simples, mas que esteja completamente funcional e resolvendo um problema real, do que dez projetos inacabados ou copiados de tutoriais.

3. Não Saber Explicar o Próprio Código

Com a facilidade das ferramentas de Inteligência Artificial, ficou simples gerar códigos complexos. No entanto, os recrutadores identificam isso facilmente na entrevista ao pedir para você explicar o funcionamento de um trecho específico. Se você não conseguir explicar com calma o que escreveu, a empresa saberá que a IA fez o trabalho por você.

4. Ignorar o Banco de Dados (SQL)

Muitos cursos focam excessivamente na linguagem de programação e ignoram os bancos de dados. Saber o básico de SQL é obrigatório para quase totalidade das vagas de júnior. Você não precisa ser um especialista em infraestrutura de dados, mas precisa dominar comandos fundamentais como:

• SELECT para consultar informações
• INSERT para inserir dados
• UPDATE para atualizar registros
• DELETE para remover dados
• Joins para relacionar tabelas

5. Currículos Desonestos ou Humildade Excessiva

Dizer que tem nível avançado em uma tecnologia sem dominar nem a lógica básica vai te desclassificar na primeira entrevista técnica. Por outro lado, o excesso de humildade e a insegurança extrema também afastam os recrutadores. A empresa já sabe que você é júnior; o que ela busca é alguém com fundamentos firmes e capacidade de aprender.

6. Invisibilidade no Mercado

Para ser contratado, você precisa existir na internet de forma profissional. Muitas vagas em empresas pequenas e médias ocorrem por indicação e visibilidade. Participar de comunidades, fóruns e interagir no LinkedIn ajuda a construir sua presença.

O Portfólio Ideal por Área de Atuação

Para se destacar, os projetos no seu portfólio precisam falar a mesma língua da vaga para a qual você está se candidatando:

Sistemas Corporativos (ERP)

É um dos mercados com maior volume de vagas. Para essa área, seu portfólio precisa conter um CRUD completo (cadastro, tela de interface, validações e conexão com o banco de dados). Criar uma aplicação simples de contas a pagar e receber, com um recurso que exporte relatórios para PDF ou Excel, aumentará drasticamente suas chances de contratação.

Desenvolvimento Web

É a área mais concorrida. Mostre que você consegue entregar uma aplicação do início ao fim construindo um sistema que integre front-end, back-end (uma API própria) e banco de dados. Implemente recursos reais como autenticação com login e senha protegidos por hash. Além disso, faça o deploy do projeto em servidores gratuitos para que o recrutador possa testar o sistema funcionando na prática.

Desenvolvimento Mobile

Uma área com escassez de profissionais qualificados. Crie um aplicativo funcional e, no arquivo explicativo do repositório, insira imagens ou um vídeo demonstrando o funcionamento dele. É importante demonstrar que o aplicativo consome dados de uma API externa (como uma busca de CEP) e armazena informações localmente no dispositivo.

Plano de Ação Prático

Se você deseja mudar o rumo das suas candidaturas, siga estes passos:

• Faça uma limpeza no seu perfil de código, removendo exercícios soltos ou cópias de cursos.
• Escolha uma aplicação simples e desenvolva ela inteiramente por conta própria, do começo ao fim.
• Escreva uma boa documentação explicando o que o projeto faz, as tecnologias utilizadas e como executá-lo.
• Estude e domine os comandos básicos de SQL.
• Pare de acumular novos cursos e comece a construir coisas reais com o conhecimento que você já possui.

O mercado de tecnologia não está fechado para bons profissionais, mas está saturado para quem acredita que apenas assistir a aulas é o mesmo que aprender a programar. Quem entra no mercado é quem tem código real para mostrar.

Feito!

Instalando o Ollama + Open WebUI com segurança do jeito certo

Guia passo a passo para implantar Ollama + Open WebUI em uma VPS Linux com Docker, isolamento de rede e HTTPS.

Visão Geral

Este guia replica a instalação segura do Ollama com o Open WebUI em uma VPS limpa (Ubuntu 22.04 ou 24.04), utilizando Docker e isolamento de rede. Nesta configuração, o Ollama ficará restrito a uma rede interna fechada, nenhuma porta sua é exposta ao host. O Open WebUI será o único ponto de entrada, protegido por autenticação (login/senha) e, opcionalmente, por HTTPS.

Passo 1: Atualizar o Sistema e Instalar o Docker

Acesse sua VPS via SSH e instale o Docker e o Docker Compose:

Atualizar a lista de pacotes do sistema

sudo apt update && sudo apt upgrade -y

Instalar dependências necessárias

sudo apt install -y curl apt-transport-https ca-certificates software-properties-common

Adicionar a chave GPG oficial do Docker

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Adicionar o repositório do Docker

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update

Instalar o Docker e o Docker Compose

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Iniciar e habilitar o serviço do Docker

sudo systemctl start docker
sudo systemctl enable docker

Nota: O pacote docker-compose-plugin fornece o comando docker compose (sem hífen). Certifique-se de usá-lo como docker compose nos passos seguintes.

Passo 2: Criar a Estrutura de Diretórios e o docker-compose.yml

Para garantir a segurança, utilizaremos o Docker Compose para criar uma rede isolada. A porta 11434 do Ollama não será mapeada para a VPS (usamos apenas expose, omitindo o parâmetro ports), impedindo qualquer acesso externo a ela.

1. Crie uma pasta para o projeto e entre nela:

mkdir -p ~/ollama-webui && cd ~/ollama-webui

2. Crie o arquivo docker-compose.yml:

nano docker-compose.yml

3. Cole o conteúdo abaixo:

version: '3.8'

networks:
  ai-network:
    driver: bridge

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
# SEGURANÇA: porta 11434 NÃO exposta no host.
# Acessível apenas internamente para containers na rede 'ai-network'.
    expose:
      - "11434"
    restart: unless-stopped
    networks:
      - ai-network

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    volumes:
      - open_webui_data:/app/backend/data
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_AUTH=true
    restart: unless-stopped
    depends_on:
      - ollama
    networks:
      - ai-network

volumes:
  ollama_data:
  open_webui_data:

Atenção: O mapeamento 127.0.0.1:8080:8080 faz o Open WebUI responder apenas localmente na VPS. Nenhuma porta fica acessível pela rede externa sem um proxy reverso (Nginx). Isso é intencional, o Nginx com HTTPS será configurado nos passos seguintes.

Pressione Ctrl+O, Enter para salvar e Ctrl+X para sair.

Passo 3: Inicializar os Containers

sudo docker compose up -d

Verifique se os containers estão rodando:

sudo docker ps

Passo 4: Garantir a Segurança no Firewall da VPS

Se você utiliza o UFW (firewall padrão do Ubuntu):

Permitir SSH (essencial para não perder o acesso à VPS)

sudo ufw allow ssh

Permitir apenas a porta HTTP (temporário, até configurarmos o HTTPS)

sudo ufw allow 80/tcp

Ativar o firewall

sudo ufw enable

Nota: Após configurar o HTTPS no Passo 6, remova a regra da porta 80 (ou mantenha-a, o Certbot a utiliza para renovação automática) e libere a 443.

Passo 5: Primeiro Acesso e Configuração

Abra o navegador e digite o endereço IP da sua VPS: http://seu_ip_da_vps. A tela de login do Open WebUI será exibida. Clique em Sign Up (Cadastrar).

⚠️ Muito Importante: O primeiro usuário cadastrado torna-se automaticamente o Administrador global do sistema. Guarde bem essa senha.

Baixar modelos pelo terminal (Recomendado)

Para baixar um modelo, execute o comando dentro do container do Ollama. O Open WebUI reconhecerá e listará o modelo automaticamente na interface:

sudo docker exec -it ollama ollama run llama3

Substitua llama3 pelo modelo desejado: gemma2, mistral, phi3, etc.

Por que baixar pelo terminal? Para modelos muito grandes, o download pelo terminal permite acompanhar a porcentagem real sem o risco de a aba do navegador desconectar ou expirar.

Passo 6: Adicionar SSL/HTTPS com Nginx + Certbot

Para evitar que senhas e conversas trafeguem em texto puro (HTTP), configure um domínio na sua VPS e gere um certificado digital gratuito com o Nginx e Certbot.

6.1 Instalar Nginx e Certbot

sudo apt install -y nginx certbot python3-certbot-nginx

6.2 Criar a Configuração do Nginx

Crie o arquivo de configuração para o seu domínio (substitua seu-dominio.com):

sudo nano /etc/nginx/sites-available/open-webui

Cole o conteúdo abaixo:

server {
   listen 80;
   server_name seu-dominio.com;

   client_max_body_size 100M;

 location / {
  proxy_pass http://127.0.0.1:8080;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  # WebSockets — necessário para streaming de texto em tempo real
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

  # Desativa buffer para resposta aparecer palavra por palavra
  proxy_buffering off;
  proxy_read_timeout 600s;
  }
}

6.3 Ativar o Site e Reiniciar o Nginx

Ativar o site

sudo ln -s /etc/nginx/sites-available/open-webui /etc/nginx/sites-enabled/

Remover a configuração padrão (evita conflitos)

sudo rm /etc/nginx/sites-enabled/default

Testar a sintaxe

sudo nginx -t

Reiniciar o Nginx

sudo systemctl restart nginx

6.4 Obter o Certificado SSL Gratuito

sudo certbot --nginx -d seu-dominio.com

O Certbot fará perguntas simples (como seu e-mail) e configurará o redirecionamento automático de HTTP para HTTPS.

6.5 Atualizar o Firewall

Liberar HTTPS

sudo ufw allow 443/tcp

Opcional: remover a permissão da porta 80 (mantenha se quiser renovação automática do Certbot)

sudo ufw delete allow 80/tcp

Considerações finais

Ollama e Open WebUI estão blindados dentro do servidor:

• Ollama isolado em rede interna — sem porta exposta ao host.
• Open WebUI acessível apenas via localhost:8080, protegido por autenticação.
• Nginx como proxy reverso com HTTPS (SSL), tráfego criptografado.
• Firewall configurado permitindo apenas SSH (22) e HTTPS (443).
• Modelos baixados via terminal dentro do container com segurança.

Feito!

Como escalar sistemas no mundo real

Muitos desenvolvedores acreditam que a escalabilidade horizontal se resume a criar cópias de um servidor e colocar um balanceador de carga na frente. No entanto, o desenvolvimento de sistemas resilientes exige um entendimento profundo de redes, do Modelo OSI e do comportamento da sua aplicação.
Com base no conteúdo técnico de especialistas em arquitetura de software, este artigo detalha os fundamentos essenciais para você dominar o balanceamento de carga e escalar sistemas na vida real.

1. Escalabilidade Vertical vs. Escalabilidade Horizontal

Antes de distribuir o seu sistema em várias máquinas, é preciso entender a ordem natural de evolução de uma infraestrutura.

Escalabilidade Vertical (Scale Up)

Consiste em adicionar mais recursos computacionais ao servidor existente, como mais memória RAM, maior poder de processamento (CPU) ou armazenamento. É o primeiro passo recomendado antes de qualquer alteração arquitetural.
Contudo, ela possui limites físicos óbvios, torna-se extremamente cara a partir de certo ponto e mantém um problema crítico: o SPOF (Single Point of Failure). Se essa máquina única falhar ou o data center cair, a aplicação inteira fica fora do ar.

Escalabilidade Horizontal (Scale Out)

É a estratégia de criar réplicas do servidor da sua aplicação para trabalharem em conjunto. Um Load Balancer (balanceador de carga) é posicionado na ponta para receber todas as requisições dos usuários e distribuí-las entre as réplicas. Isso remove o ponto único de falha e permite o uso de hardware mais simples e barato.

Uma dúvida comum é: se a aplicação precisa de escala por não aguentar o tráfego, por que o Load Balancer, que também é um servidor único, aguenta?
A resposta está no nível de operação. Uma aplicação web tradicional consome muito tempo iniciando frameworks, processando regras de negócio e consultando bancos de dados. O Load Balancer foi projetado exclusivamente para extrair o máximo do hardware em baixo nível, atuando apenas como um direcionador ultraveloz sem executar lógicas pesadas.

2. Camadas de Operação: Camada 4 vs. Camada 7

Os balanceadores de carga não funcionam todos da mesma forma. Eles operam em diferentes camadas do Modelo OSI, e essa escolha muda completamente o comportamento do tráfego.

Camada 4 (Layer 4 - Camada de Transporte)

Opera ao nível de protocolos raiz como TCP e UDP. Este balanceador é considerado "cego", pois não abre e não analisa o conteúdo da requisição; ele enxerga apenas o IP de origem e o IP de destino.
Por não interceptar o pacote, entrega altíssima velocidade, baixíssima latência e grande vazão de dados (throughput). É ideal para:

• Jogos online em tempo real (FPS).
• Aplicações de streaming de vídeo ou chamadas (como Google Meet), que utilizam UDP e aceitam pequenas perdas de pacotes.
• Arquiteturas de mensageria massiva baseadas em conexões persistentes de WebSockets (como o WhatsApp).

Camada 7 (Layer 7 - Camada de Aplicação)

Opera diretamente no nível do protocolo HTTP. Ao contrário da Camada 4, ele intercepta a requisição, desempacota o conteúdo e consegue ler a URL, os headers, os cookies e os tokens de autenticação (como JWT).
Embora adicione uma pequena latência pelo processamento, ele permite um roteamento contextual inteligente. É recomendado para 90% das aplicações web tradicionais, e-commerces e microsserviços, permitindo regras como:

• Se a URL contiver /pedidos, envie para o Cluster A.
• Se a URL contiver /pagamentos, envie para o Cluster B.
• Aplicação centralizada de Rate Limiting e segurança.

3. Configuração Prática no Nginx

Para tirar o conceito do papel e implementar um balanceador de carga em Camada 7, o arquivo de configuração nginx.conf pode ser estruturado de maneira simples. No exemplo abaixo, o bloco upstream backend agrupa as três instâncias da aplicação rodando localmente (nas portas 8001, 8002 e 8003). O servidor do Nginx escuta na porta 8080 e repassa o tráfego usando a diretiva proxy_pass:

4. Algoritmos de Balanceamento e Complementações no Nginx

A escolha do algoritmo correto de distribuição de carga define o sucesso da infraestrutura. Veja abaixo como complementar o bloco upstream do seu Nginx para alterar a estratégia de balanceamento:

Round Robin (Circular)

É o algoritmo padrão (default) do Nginx. Ele distribui as requisições de forma estritamente sequencial e circular. Não exige nenhuma palavra-chave adicional, bastando listar os servidores como no exemplo base:

http { 

upstream backend {

    server localhost:8001;

    server localhost:8002;

    server localhost:8003;

}
server {
     listen: 8080;
     location / {
        proxy_pass http://backend;
     } 

  } 

} 

Weighted Round Robin (Ponderado)

Utilizado quando os servidores possuem capacidades de hardware diferentes. Adiciona-se o parâmetro weight para definir a proporção de carga que cada um deve receber. No exemplo abaixo, a porta 8001 receberá três vezes mais requisições que as outras duas:

  

http { 
  
     upstream backend {

    server localhost:8001 weight=3;

    server localhost:8002;

    server localhost:8003;

    } 

  server {
     listen: 8080;
     location / {
        proxy_pass http://backend;
     } 

  } 

} 

Least Connections (Menor número de conexões)

Direciona a nova requisição sempre para o servidor que tiver menos conexões ativas no momento da chamada, sendo ideal para aplicações com processamentos pesados e demorados. Para ativá-lo, basta adicionar a diretiva least_conn; no topo do bloco:

http { 
  
upstream backend {

    least_conn;

    server localhost:8001;

    server localhost:8002;

    server localhost:8003;

}
server {
     listen: 8080;
     location / {
        proxy_pass http://backend;
     } 

  } 

} 

Outros Algoritmos Notáveis

• Least Response Time (Menor tempo de resposta): Identificado pela diretiva least_time (disponível apenas no Nginx Plus), direciona o tráfego com base na latência e saúde em tempo real do servidor.


• Sticky Round Robin (Sessões Coladas): Utiliza mecanismos como cookies ou a diretiva ip_hash; para garantir que um usuário específico seja sempre direcionado para a mesma instância. Essencial para escalar monólitos que guardam estado de sessão em memória (stateful).

Considerações finais

A arquitetura de software de alta disponibilidade é guiada por escolhas e compensações (tradeoffs). Conexões de Camada 4 mantêm o cliente preso a uma conexão TCP aberta de forma persistente, o que é inviável para navegação web comum, mas indispensável para tempo real. Por outro lado, a Camada 7 oferece inteligência de roteamento à custa de mais processamento.
Dominar esses fundamentos de rede e saber configurar o algoritmo correto para a natureza do seu tráfego é o que separa um desenvolvedor comum de um verdadeiro engenheiro de sistemas escaláveis.

Referência

https://nginx.org/en/docs/http/load_balancing.html

Feito!

O Imposto Oculto da IA: Por que usar prompts em português na ferramenta de IA custa 62% mais caro?

Se você utiliza prompt na ferramenta/agente de IA no seu dia a dia, seja programando com o Claude, gerando relatórios no ChatGPT ou criando automações com o Gemini, existe um detalhe invisível na sua conta que provavelmente está passando despercebido.

Você sabia que, para transmitir a mesmíssima informação, você pode estar gastando muito mais recursos (e dinheiro) do que um usuário americano? Um dado impressionante: usar prompt em português chega a ser 62% mais caro do que em inglês. E não, isso não tem a ver com a cotação do dólar ou planos de assinatura diferenciados para o Brasil. A explicação é puramente técnica.

Abaixo, explicamos como esse "imposto do idioma" funciona e o que você pode fazer para otimizar seus gastos e sua produtividade.

O que são Tokens e por que eles controlam o seu bolso?

Para entender o problema, primeiro precisamos entender a moeda de troca das grandes ferramentas de IA: o token.

As IAs não leem textos como nós (palavra por palavra) e também não cobram por caractere. Elas fatiam o texto em pedaços chamados tokens. Uma regra geral para o inglês é que um token equivale a mais ou menos 4 caracteres ou 0,75 palavras. Toda vez que você envia uma pergunta (input) ou recebe uma resposta (output), você paga por token.

Além disso, cada modelo tem um limite de memória interna, a chamada janela de contexto. Quanto mais tokens você gasta, mais rápido a ferramenta/agente de IA "esquece" o que foi dito no início da conversa ou estoura o limite do seu plano de desenvolvimento.

Por Que o Português é "Penalizado"?

O grande X da questão está em como os modelos de IA são treinados. Eles utilizam um algoritmo chamado BPE (Byte Pair Encoding), que analisa volumes gigantescos de texto na internet para identificar quais combinações de letras aparecem com mais frequência, transformando-as em tokens únicos.

Como a esmagadora maioria da internet e dos dados de treinamento está em inglês, o algoritmo é extremamente eficiente nesse idioma. Palavras inteiras em inglês costumam virar um único token. Já no português, por ser menos frequente na base de dados global, as palavras são frequentemente "fatiadas" em vários pedacinhos menores.

O Exemplo Prático do Vídeo:

Na ferramenta de testes, a frase em inglês "Palmeiras don't have world championship" gerou apenas 7 tokens.

A tradução exata em português, "Palmeiras não tem mundial", gerou 11 tokens para transmitir exatamente o mesmo significado.

Embora o português ainda se saia melhor do que idiomas como o árabe ou o chinês (que sofrem penalidades ainda maiores), o multiplicador médio para a nossa língua é de 1.62. Ou seja: você consome 62% mais tokens para dizer a mesma coisa.

Anthropic vs. OpenAI: O peso do design

Outro insight valioso é que esse custo varia de acordo com a empresa criadora do modelo. A Anthropic (criadora do modelo Claude, muito elogiado por desenvolvedores) tende a ser ainda mais cara para idiomas que não são o inglês do que a OpenAI (do ChatGPT).

Isso não ocorre por má intenção; é uma consequência direta das escolhas de design do tokenizador e de onde essas empresas focaram a maior parte do orçamento e dos dados de seus treinamentos iniciais.

Como agir? As 3 estratégias para o seu dia a dia

Sabendo disso, você tem três caminhos claros para escolher, dependendo do seu contexto profissional e financeiro:

• 1. Adotar o inglês como padrão

  Se você já domina o inglês ou trabalha em ambientes globais, faça seus prompts e comandos 100% em inglês. Se você usa ferramentas como o Claude Code ou ChatGPT/Codex para programar, manter o código, as instruções e a documentação em inglês vai salvar uma quantidade massiva do seu orçamento de tokens.

• 2. A abordagem híbrida

  Não se sente confortável conversando em inglês o tempo todo? Sem problemas. Você pode manter os artefatos pesados em inglês (aqueles arquivos de contexto, como um README.md, regras de negócio ou especificações técnicas que a IA precisa ler repetidamente a cada mensagem) e fazer as suas perguntas cotidianas no chat em português. O maior ganho está em economizar nos arquivos estruturais que ficam fixos na memória da IA.

• 3. Aceitar o Custo e Focar no Resultado

  Se você tem barreiras com o inglês ou se o seu projeto é pequeno e o custo não faz diferença no orçamento final, ignore os tokens e continue usando o português. No fim do dia, a clareza da sua comunicação e a velocidade da sua entrega valem mais do que alguns centavos economizados à custa de lentidão cognitiva.

Considerações finais

À medida que os modelos de IA se tornam mais poliglotas e treinados com dados globais, a tendência é que essa diferença diminua. Mas no cenário atual da tecnologia, o idioma que você escolhe para falar com a máquina dita o preço que você paga e a eficiência do contexto que ela retém.

E você? Costuma usar prompts em inglês ou português no seu projeto? Já tinha reparado na velocidade com que os seus créditos evaporam em nossa língua nativa?

Feito!