Mundo da Computação Integral

Do "Pedreiro de Software" à mente pensante

2026-10-16T18:00:00.000-03:00

Se você acompanha a comunidade de tecnologia nos últimos meses, certamente já sentiu aquela ponta de ansiedade. Com o avanço rápido das ferramentas de Inteligência Artificial generativa, surgiram discussões frequentes em fóruns e redes sociais: "Será que a IA vai acabar com a profissão do programador?" ou "Ainda vale a pena investir anos em um curso de Ciência da Computação, Engenharia de Software ou Tecnologia em Análise de Desenvolvimento de Sistemas?"

Essa angústia é legítima, mas deriva de uma visão limitada sobre o que realmente significa trabalhar com tecnologia. O presente artigo aborda reflexões essenciais sobre essa transição e desmistifica o futuro da carreira e mostrando por que a computação vive, na verdade, o seu momento mais promissor.

1. A Computação não é uma Ciência "Fim", É uma Ciência "Meio"

Para entender o valor real de um profissional da computação, primeiro precisamos compreender a natureza da área. Cursos como Medicina, Direito, Psicologia e Contabilidade são ciências-fim: eles resolvem problemas diretamente dentro do seu próprio domínio de atuação.

A Computação, por outro lado, é uma ciência-meio. Ela existe para dar suporte, otimizar e alavancar o avanço de todas as outras áreas do conhecimento humano. Como as necessidades do mercado e da sociedade continuam se multiplicando, a demanda por pessoas capazes de modelar e resolver esses problemas através do código nunca vai acabar.

A própria Inteligência Artificial não surgiu do nada: ela foi criada por mentes da área de computação. As próximas inovações disruptivas que virão depois da IA também nascerão pelas mãos de quem domina essa ciência.

2. Você está sendo treinado para ser "Engenheiro", não "Pedreiro"

Uma das analogias mais marcantes vem de do exemplo da vivência na Engenharia Civil. Nas aulas de laboratório sobre resistência de materiais, os estudantes aprendem na prática a virar concreto, colocar água na medida certa e testar a resistência dos blocos até estourarem. Porém, vem a provocação que muda tudo:

"Vocês aprenderam a mexer no concreto, mas não foram treinados para ser pedreiros. Vocês foram treinados para ser engenheiros civis — a mente pensante por trás do projeto."

Na tecnologia acontece exatamente o mesmo. Digitar linhas de código repetitivas é equivalente a mexer o concreto. Por muito tempo, o mercado chamou de desenvolvimento o que era apenas um trabalho braçal de sintaxe. Fazer uma faculdade ou se aprofundar em Ciência da Computação não serve para ensinar você a apenas bater código, mas sim para prepará-lo para ser a mente pensante por trás da solução.

3. O fim da "Manufatura" e o nascimento da Indústria de Software

Até pouco tempo atrás, o mercado não operava sob uma verdadeira "indústria" de software, mas sim em um modelo de manufatura de software. Quase tudo era feito à mão, linha por linha, em um processo puramente artesanal.

Os agentes de Inteligência Artificial vem para mudar isso:

A IA é o robô da linha de montagem: Ela assume as soldas repetitivas e a construção pesada (o famoso vibe coding sem estrutura).
O Humano é o arquiteto: É quem decide o que construir, garante a qualidade, desenha os limites e gerencia a lógica de negócio.

Quando um setor se industrializa, o custo de produção cai e a velocidade aumenta. Isso não destrói o mercado; pelo contrário, permite que mais empresas e pessoas tenham acesso a softwares avançados, aumentando o tamanho da pizza para quem sabe liderar a construção desses produtos.

4. Para onde deve ir o foco do Desenvolvedor agora?

Se o agente de IA escreve trechos de código com facilidade, continuar atuando apenas como um codificador mecânico torna sua posição vulnerável. Para se destacar, o profissional deve focar seu aprendizado nos seguintes pilares:

Engenharia e Arquitetura de Software: Dominar Clean Architecture, SOLID, microsserviços, desacoplamento e padrões de projeto (design patterns).
Processos e Qualidade: Entender ciclo de vida de desenvolvimento, Spec-Driven Development (SDD), Test-Driven Development (TDD) e observabilidade.
Entendimento do Negócio: Saber traduzir dores de negócio (da medicina, finanças, logística) em especificações técnicas precisas.
Cybersegurança: Proteção de sistemas, redes e dados contra ataques digitais, garantindo a confidencialidade, integridade e disponibilidade das informações. Implementação de estratégias e tecnologias para mitigar ameaças virtuais e assegurar a continuidade das operações digitais. Conjunto de práticas e políticas essenciais para defender a infraestrutura tecnológica contra acessos não autorizados e vulnerabilidades.

Considerações finais

Longe de estar morrendo, a Computação está sendo libertada do trabalho braçal. Pela primeira vez na história, os profissionais de tecnologia estão sendo descorrentados da digitação repetitiva para focar no que realmente importa: pensar, criar e transformar ideias em produtos de alto impacto..

Se você está estudando ou pensando em entrar na área, o recado é claro: não tenha medo. Abrace a IA como sua melhor ferramenta de montagem e especialize-se em ser a mente pensante da engenharia de software. O futuro da computação pertence aos arquitetos.

Feito!

Como escrever códigos limpos e escaláveis na prática

2026-10-15T18:00:00.000-03:00

Se você é desenvolvedor de software, com certeza já passou por aquela situação frustrante: o projeto começa simples e organizado, mas à medida que ganha novas funcionalidades, mexer em uma linha de código parece um jogo de Jenga, a qualquer momento, tudo pode desmoronar.

A boa notícia é que existe uma bússola para evitar o famoso "código espaguete": os princípios SOLID. Neste artigo, aborda como esses conceitos transformam a arquitetura de software no dia a dia.

Os principais insights para você aplicar hoje mesmo no seu fluxo de desenvolvimento.

O que é o SOLID?

Criado por Robert C. Martin (o famoso Uncle Bob), S.O.L.I.D. é um acrônimo para cinco princípios de design de código e programação orientada a objetos (POO). O objetivo principal é ajudar desenvolvedores a criarem softwares fáceis de manter, refatorar e testar.

O Problema do Código Acoplado

O vídeo demonstra como o alto acoplamento é a causa raiz da maioria das dívidas técnicas em projetos. Quando componentes dependem excessivamente uns dos outros:

Alterar uma regra de negócio quebra funcionalidades aparentemente não relacionadas.
Escrever testes unitários torna-se uma tarefa dolorosa e complexa.
A adição de novas features desacelera drasticamente com o tempo.

Os 5 Princípios na Prática

S — Single Responsibility Principle (SRP): Uma classe deve ter apenas um motivo para mudar. Em outras palavras, ela deve possuir uma única responsabilidade no sistema. Se uma classe envia e-mails, acessa o banco de dados e calcula o frete, ela está acumulando papéis demais.
O — Open/Closed Principle (OCP): Entidades de software devem estar abertas para extensão, mas fechadas para modificação. Você deve conseguir adicionar novas funcionalidades sem precisar alterar o código existente e já testado.
L — Liskov Substitution Principle (LSP): Subclasses devem conseguir substituir suas classes pai sem quebrar o comportamento do sistema. Se B é subclasse de A, então o programa deve funcionar perfeitamente quando substituímos A por B.
I — Interface Segregation Principle (ISP): Uma classe não deve ser forçada a depender de métodos que não utiliza. É preferível ter várias interfaces específicas do que uma única interface genérica "gorda".
D — Dependency Inversion Principle (DIP): Módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações (interfaces ou classes abstratas). Detalhes de implementação devem depender de abstrações, e não o contrário.

Principais Insights para Desenvolvedores

1. SOLID não é teoria acadêmica, é economia de tempo

Aplicar SOLID não serve apenas para "deixar o código bonito". A verdadeira vantagem é econômica e prática: implementar uma alteração em um código desacoplado leva minutos, enquanto em um código acoplado pode levar dias e gerar bugs em produção.

2. Abstração facilita o teste automatizado

Ao aplicar o DIP (Inversão de Dependência), você isola a regra de negócio do banco de dados ou de APIs externas. Isso significa que você consegue criar mocks facilmente em testes unitários sem precisar subir um banco de dados real.

3. Pequenas refatorações evitam grandes desastres

Não é necessário reescrever o sistema do zero. O vídeo mostra que identificar pontos de acoplamento e refatorá-los gradualmente — isolando responsabilidades e criando interfaces — já traz ganhos imediatos de manutenibilidade.

Considerações finais

Escrever código limpo é uma habilidade que se aprimora com a prática constante. Ao incorporar os princípios SOLID no seu dia a dia, você não apenas melhora a qualidade das aplicações que constrói, mas também se torna um profissional muito mais valioso para qualquer equipe de tecnologia.

Feito!

Como resolver gargalos no Banco de Dados sem romper o domínio

2026-10-14T18:00:00.000-03:00

Em arquiteturas de microsserviços e sistemas de alta escala, um dos gargalos mais comuns surge no banco de dados. O padrão de projeto tradicional, focado em CRUD (Create, Read, Update, Delete), utiliza a mesma estrutura e as mesmas tabelas tanto para gravar dados quanto para consultá-los.

Conforme a aplicação cresce, essa abordagem unificada começa a dar sinais de cansaço: consultas analíticas com múltiplos JOINs pesados disputam recursos com inserções e atualizações críticas, gerando contenção de locks, alta latência e degradação geral de performance.

Para resolver esse problema estrutural, o padrão CQRS (Command Query Responsibility Segregation) propõe uma mudança fundamental de mentalidade. Neste artigo, é explicado os principais insights do "O guia completo de CQRS em como resolver gargalos no banco de dados".

O problema do modelo único (CRUD Tradicional)

No modelo tradicional, o mesmo modelo de dados serve a dois propósitos conflitantes:

Escrita: Requer validação rígida de regras de negócio, dados normalizados (3NF) para evitar redundância e garantir consistência transacional (ACID).
Leitura: Requer dados estruturados de forma simples, prontos para exibição na tela (UI/API), idealmente desnormalizados para evitar cruzamentos de tabelas dispendiosos.

Quando tentamos otimizar uma tabela para leitura (criando múltiplos índices, por exemplo), prejudicamos o desempenho das escritas. Quando otimizamos para escrita (normalizando excessivamente), tornamos as consultas lentas.

O Conceito de CQRS

O CQRS separa a aplicação em duas responsabilidades distintas:

1. Commands (Comandos / Escrita)

Objetivo: Alterar o estado do sistema (CriarPedido, AlterarEndereco).

Característica: Focado no domínio e na integridade das regras de negócio. Retorna apenas status de sucesso/falha, nunca o payload completo de dados.

Modelo de Dados: Normalizado e otimizado para gravações rápidas e consistentes.

2. Queries (Consultas / Leitura)

Objetivo: Retornar dados otimizados para apresentação.

Característica: Não altera o estado do sistema e não executa regras de negócio complexas.

Modelo de Dados: Desnormalizado, pré-formatado ou materializado exatamente na estrutura que o cliente (Front-end/Mobile) precisa consumir.

Principais Benefícios Arquiteturais

Benefício	Descrição
Escalabilidade Independente	Você pode escalar a infraestrutura de leitura (ex: réplicas de leitura, instâncias de cache ou NoSQL) de forma totalmente independente da base de escrita.
Alta Performance nas Consultas	Elimina a necessidade de `JOINs` complexos em tempo de execução, pois os dados de leitura já estão projetados e prontos no banco de consultas.
Código de Domínio Mais Limpo	O lado de escrita fica limpo de código referente a paginação, buscas avançadas e formatações para telas.
Segurança e Isolamento	Permite conceder permissões diferenciadas em nível de infraestrutura para operações de leitura e escrita.

Cuidados e Armadilhas: Quando NÃO usar

Embora seja um padrão poderoso, o CQRS introduz complexidade acidental se aplicado no contexto errado.

Regra de ouro: Não utilize CQRS para aplicações simples, CRUDs convencionais ou domínios onde o volume de leituras e escritas seja baixo e equilibrado.

Principais desafios ao adotar CQRS:

Consistência Eventual (Eventual Consistency): Se o modelo de leitura for atualizado de forma assíncrona (via mensageria e eventos de domínio), haverá um pequeno intervalo de latência até que o dado gravado no lado de escrita reflita na base de consulta.
Duplicação de Código e Infraestrutura: Exige manter dois modelos distintos e, eventualmente, duas bases de dados diferentes (ex: PostgreSQL para escrita e MongoDB/Elasticsearch para leitura).
Sincronização de Dados: É necessário implementar e monitorar mecanismos tolerantes a falhas para garantir que os eventos de atualização cheguem à base de leitura.

Exemplo Prático de Código

Abaixo apresentamos um exemplo conceitual em TypeScript demonstrando a separação das responsabilidades de escrita (Command) e leitura (Query):

// Command Handler - Responsável por alterar o estado
class CriarPedidoHandler {
  async handle(command: CriarPedidoCommand): Promise<void> {
    // 1. Valida regras de negócio do domínio
    const pedido = new Pedido(command.clienteId, command.itens);
    
    // 2. Persiste no modelo de escrita (Write Model - Relacional/Normalizado)
    await this.pedidoRepository.save(pedido);

    // 3. Publica evento para sincronização assíncrona
    await this.eventBus.publish(new PedidoCriadoEvent(pedido));
  }
}

// Query Handler - Responsável por ler dados otimizados
class ObterDetalhesPedidoHandler {
  async handle(query: ObterPedidoQuery): Promise<PedidoDTO> {
    // Consulta diretamente a base de leitura (Read Model desnormalizado)
    return await this.readDatabase.findPedidoById(query.pedidoId);
  }
}

Considerações finais

O CQRS é uma ferramenta arquitetural indispensável quando atingimos os limites do banco de dados relacional tradicional sob alta carga. Ele resolve o gargalo de I/O ao permitir que a leitura e a escrita cresçam de forma independente, mas exige maturidade da equipe para lidar com consistência eventual e sistemas distribuídos.

Feito!

O Primeiro "System 1 Model": Inovação Arquitetural Real ou Apenas Hype?

2026-10-09T18:00:00.000-03:00

No ecossistema de Inteligência Artificial, 2024 e 2025 foram marcados pelo avanço vertiginoso dos modelos do Sistema 2. IAs voltadas para o raciocínio lento, profundo e encadeado, como o OpenAI o1/o3 e o Claude 3.5 Sonnet. No entanto, a busca por modelos capazes de tomar decisões instantâneas no backend levou ao surgimento de uma nova categoria comercializada pela TypeSafe AI com o modelo Jev: o chamado System 1 Model (Modelo de Sistema 1).

Em uma análise detalhada feita no canal da desenvolvedora Fernanda Kipper, o modelo Jev foi posto à prova para responder à pergunta que todo desenvolvedor se faz diante de novidades do setor: isso serve para algo na prática ou é apenas marketing?

Entendendo a Analogia: Sistema 1 vs. Sistema 2

A terminologia tem origem na psicologia cognitiva, popularizada pelo prêmio Nobel Daniel Kahneman:

Sistema 2 (Raciocínio Lento e Analítico): É o cérebro que pondera, analisa variáveis complexas e resolve equações. Na IA, traduz-se em modelos autorregressivos que usam Chain of Thought (cadeia de pensamento). Eles entregam respostas brilhantes, porém com alta latência e alto custo por requisição.

Sistema 1 (Intuição Rápida e Automática): É o cérebro das reações reflexas e tomadas de decisão em milissegundos. Não há reflexão profunda, apenas uma resposta imediata baseada em padrões consolidados.

O Diferencial técnico do Jev: Como Funciona por Baixo do Capô?

Diferente das LLMs tradicionais, o Jev quebra o paradigma da geração de texto token por token. Em vez disso, ele foca exclusivamente em avaliação paralela de estado e decisão estruturada.

1. Sem Geração Autorregressiva de Texto

O Jev não conversa, não gera parágrafos nem tenta simular um Chatbot. Ele recebe o contexto (state) e responde a um conjunto de perguntas estruturadas em uma única passagem paralela.

2. Primitivas Tipadas (Type-Safety Nativa)

Em vez de depender de engenharia de prompt complexa ou torcer para que o modelo retorne um JSON no formato correto, as consultas no Jev são construídas sobre três primitivas fortemente tipadas:

Noul: Perguntas booleanas (Sim/Não) com indicação de probabilidade.

Choice: Escolha direta entre opções de um conjunto fechado.

Score: Avaliação em escala contínua ou ordinal (ex.: prioridade 1 a 5, risco baixo/médio/alto).

3. Latência e custos extremamente baixos

Como a arquitetura não precisa prever o próximo token sucessivamente, os tempos de resposta caem para a faixa de 70ms a 400ms. Além disso, o custo gira em torno de $0,042 por milhão de tokens de entrada sem custo de saída — valor ordens de grandeza inferior aos grandes modelos de linguagem.

Principais vantagens para o Desenvolvimento de Software

Confidence Scores Calibrados

Um dos grandes gargalos de LLMs comuns em pipelines de decisão é a dificuldade de saber se o modelo está "convicto" ou alucinando. O Jev devolve uma pontuação de confiança calibrada para cada decisão. Isso permite criar regras condicionais sólidas no código:

Se Confiança > 90% -> Aprova automaticamente no Backend

Se Confiança <= 90% -> Encaminha para modelo Sistema 2 ou Revisão Humana

Fim das Falhas de Parsing

Ao eliminar a geração de texto livre e adotar um schema garantido por construção, desaparecem os problemas com parsers JSON quebrados ou respostas fora do padrão especificado.

Veredito: É inovação real ou apenas Hype?

A resposta depende diretamente de onde você pretende aplicar essa tecnologia:

Cenário de Uso	Avaliação	Diagnóstico
Roteamento de Microsserviços e Triagem	Essencial	Excelente para classificar emails, moderar conteúdo, definir intenção de busca e encaminhar chamadas com baixíssima latência.
Geração de Conteúdo e Conversação	Inútil	Não substitui assistentes virtuais, pois não gera texto natural nem faz síntese de documentos.
Nomenclatura "System 1 Model"	Marketing Parcial	A técnica de amostragem paralela e calibração por RL é excelente, mas vendê-la como uma "nova revolução da IA" é, em parte, uma estratégia de posicionamento de produto.

Considerações finais

O Jev e os modelos de decisão instantânea não nasceram para matar os LLMs tradicionais, mas sim para trabalhar em conjunto com eles. Em uma arquitetura moderna de IA, o modelo Sistema 1 atua como o filtro rápido de entrada na infraestrutura, resolvendo 80% das decisões simples com custo e tempo insignificantes, enquanto reserva os modelos Sistema 2 para as poucas tarefas que realmente exigem raciocínio complexo.

Referências

https://docs.typesafe.ai/introduction

Feito!

Guia dos Fundamentos de Arquitetura para Decisões Inteligentes

2026-09-25T18:00:00.000-03:00

Quando começamos a programar no backend, é comum focar na sintaxe do framework ou no comando SQL correto. No entanto, à medida que os projetos crescem e o tráfego aumenta, a pergunta principal deixa de ser "como implementar essa funcionalidade?" e passa a ser "como organizar o sistema de forma sustentável?".

É exatamente aí que entra a Arquitetura de Software.

O que é Arquitetura de Software na Prática?

De forma técnica, a arquitetura de software é a organização fundamental de um sistema, englobando seus componentes, as relações entre eles e os princípios que guiam sua evolução.

No entanto, uma das definições mais precisas pertence a Martin Fowler: "Arquitetura é o entendimento compartilhado que os desenvolvedores especialistas têm do sistema."

Na rotina de desenvolvimento backend, a arquitetura define:

Responsabilidades: O que cada parte do sistema deve fazer.
Comunicação: Como esses componentes interagem e trocam dados.
Restrições de Negócio: Prazos, orçamento da empresa, capacidades da equipe e stack tecnológica disponível.
Qualidades do Sistema: Requisitos não-funcionais, como manter a resposta de uma API abaixo de 200ms.

Por que Decisões Arquiteturais são Críticas?

Muitos desenvolvedores acreditam que arquitetura serve apenas para deixar o código bonito. A verdade é que boas decisões impactam diretamente os indicadores do negócio:

Custo Financeiro e de Tempo: Mudar um sistema mal estruturado é lento e caro. Decisões de infraestrutura incorretas aumentam drasticamente a fatura dos serviços de nuvem.
Escalabilidade e Desempenho: Determina se a aplicação suportará milhares de usuários concorrentes sem cair.
Organização das Equipes: A estrutura do sistema reflete na maneira como os times de engenharia trabalham juntos (Lei de Conway).
Resolução de Problemas: Em arquiteturas excessivamente complexas ou mal divididas, a causa raiz de um bug pode estar em um serviço totalmente diferente de onde o erro é exibido.

As Duas Dimensões da Arquitetura

Ao desenhar um sistema, é importante separar as decisões estruturais das decisões de design de código.

1. Decisões Estruturais (Infraestrutura)

Tratam do formato de implantação e dos limites de execução:

Escolha entre Monólito, Microsserviços ou Serverless.
Utilização de mensageria assíncrona (Event-Driven Architecture).
Estruturação de API Gateways, réplicas de leitura para bancos de dados e estratégias de deploy.

2. Decisões de Design de Código (Internas)

Focam nas regras de dependência dentro da aplicação:

Adoção de padrões como Clean Architecture, Arquitetura Hexagonal (Ports and Adapters) ou MVC.
Exemplo Prático: Em um módulo de cobrança, definir uma interface de pagamento genérica. Se a empresa mudar o gateway de pagamento (de Stripe para Mercado Pago, por exemplo), altera-se apenas a classe adaptadora, mantendo a regra de negócio intacta.

5 Conceitos Fundamentais para Todo Dev Backend

Antes de tomar qualquer decisão arquitetural, existem 5 conceitos-chave que precisam estar claros no seu dia a dia:

Conceito	Pergunta Principal	Ponto de Atenção
Stateful vs. Stateless	O servidor precisa manter o estado do cliente em memória?	Servidores Stateless usam tokens de autenticação (`JWT`) e escalam horizontalmente com facilidade. Sistemas Stateful são reservados para necessidades em tempo real, como jogos multiplayer.
Síncrono vs. Assíncrono	O usuário/sistema precisa do resultado imediatamente?	Processamentos demorados (como validação de documentos) devem ser assíncronos para evitar estouro de timeout HTTP.
Acoplamento	Se o Componente B mudar, o quanto o Componente A será afetado?	O acoplamento de negócio é saudável; o acoplamento não-saudável (acessar direto o banco de dados do outro serviço) destrói a manutenibilidade do sistema.
Idempotência	O que acontece se a mesma requisição chegar duas ou mais vezes?	Uma operação idempotente gera o mesmo resultado sem efeitos colaterais duplicados. O uso de chaves de idempotência (ex: pressione `Ctrl` + `R` para tentar novamente sem reprocessar) previne cobranças duplicadas em APIs financeiras.
Estratégias de Cache	Quanto tempo de desatualização dos dados o negócio tolera?	Saldos bancários exigem tolerância zero a dados desatualizados (sem cache direto). Posts de blogs ou catálogos aceitam minutos de divergência.

Considerações finais

Entender de Arquitetura de Software é o que separa um programador que apenas executa tarefas daquele que desenha soluções escaláveis e sustentáveis para o negócio.

Da próxima vez que for iniciar um serviço backend, não saia apenas criando pastas e instalando bibliotecas. Pergunte-se: "Qual é a necessidade de escala, tolerância a dados desatualizados e modelo de comunicação do meu sistema?". A resposta a essas perguntas apontará o caminho correto.

Feito!

Como entregar valor de verdade nos seus primeiros 90 Dias como Desenvolvedor

2026-09-22T18:00:00.000-03:00

Entrar em um novo emprego ou conquistar o primeiro papel como desenvolvedor é incrível, mas costuma vir acompanhado de uma boa dose de ansiedade. É muito comum querer "mostrar serviço" logo na primeira semana, tentando resolver problemas gigantescos ou enviar centenas de linhas de código em um único Pull Request. No entanto, tentar abraçar o mundo no início costuma causar mais erros e frustrações do que resultados positivos.

Para ter uma transição suave e construir uma carreira sólida na nova empresa, o segredo é dividir os seus três primeiros meses em três fases estratégicas: Compreensão, Confiabilidade e Propriedade (Ownership).

O valor real de um desenvolvedor nos primeiros dias não vem da quantidade de código que ele escreve, mas sim do quanto ele entende o contexto e o negócio antes de agir.

Mês 1: Compreensão e Contexto

O foco total do primeiro mês deve ser absorver conhecimento sobre a empresa, a equipe e o produto. Não tente revolucionar a arquitetura nos primeiros 30 dias.

Entenda o motivo da vaga: A estratégia começa antes do Dia 1. Tente resgatar das entrevistas qual problema a equipe estava tentando resolver ao abrir a vaga. Isso dá uma pista direta do que eles consideram como sucesso.
Aprenda o Negócio: Identifique quem são os principais clientes, quais produtos geram mais receita e como a empresa ganha dinheiro. Desenvolvedores que entendem as regras de negócio entregam soluções muito mais inteligentes.
Busque por tarefas simples: Pegue tickets básicos, como trocar a cor de um botão ou alterar um texto. O objetivo aqui não é o impacto do código em si, mas entender o fluxo do time: como funcionam os Code Reviews, testes automatizados e o pipeline de CI/CD.
Aproveite a "visão de fora": Você nunca mais terá o olhar do recém-chegado. Aproveite esse período para documentar o processo de onboarding, atualizar manuais defasados e anotar gargalos nos processos antes que você se acostume com eles.

Mês 2: Confiabilidade (Reliability)

No segundo mês, após compreender a dinâmica da empresa, o foco se volta para a construção de confiança com seu gestor e seus pares.

Cumpra o que promete: Torne-se alguém previsível. Se estimou uma data ou aceitou um ticket, faça o possível para entregar dentro do alinhado.
Comunique impedimentos cedo: Encontrou um bloqueio técnico ou percebeu que a tarefa vai atrasar? Avise a equipe o quanto antes. O maior erro é guardar o problema para si e avisar apenas na reunião diária no dia da entrega.
Tenha autonomia de ponta a ponta: Ao assumir uma tarefa, acompanhe-a desde a fase de testes em staging até a validação em produção, sem precisar que alguém te lembre de fazer isso.

Mês 3: Sentimento de Dono (Ownership) e Proatividade

Chegando ao final do período de experiência, é hora de agir com mais autonomia e demonstrar impacto direto no produto e na equipe.

Domine uma área do projeto: Torne-se a pessoa de referência em algum módulo específico do sistema (por exemplo, no serviço de autenticação ou no fluxo de pagamentos).
Seja mais proativo e menos reativo: Em vez de apenas esperar pelas demandas prontas do formulário, identifique falhas na codebase, sugira pequenas melhorias de arquitetura e ajude no refinamento de novas tarefas.
Busque feedback real: Não espere a avaliação formal de 90 dias. Peça reuniões rápidas com seu gestor e colegas de time perguntando diretamente: O que posso melhorar ou ajustar no meu trabalho para o próximo mês?.

Considerações finais

Evoluir em uma empresa é uma maratona, não uma corrida de 100 metros. Entender o ecossistema no Mês 1, demonstrar consistência e confiabilidade no Mês 2, e assumir a responsabilidade pelas suas entregas no Mês 3 é a forma mais sustentável de garantir seu sucesso e crescimento como desenvolvedor.

Foque no processo, tire a pressão de saber tudo no primeiro dia e construa sua reputação passo a passo!

Feito!

Guia prático de economia de tokens com os modelos da OpenAI

2026-09-16T18:00:00.000-03:00

Quem utiliza ferramentas de IA integradas como o Codex e os modelos GPT no dia a dia do desenvolvimento de software sabe que a cota de tokens é um recurso sagrado. Em um momento de foco no desenvolvimento, poucas coisas são mais frustrantes do que ser bloqueado por excesso de requisições.

No presente artigo explico os principais insights práticos com 8 estratégias nativas, sem a necessidade de instalar nenhuma extensão ou dependência extra, para fazer sua cota render ao máximo e otimizar o seu fluxo de trabalho.

Cenário e limites da cota

A OpenAI aplica restrições de uso que variam de acordo com o plano contratado. No plano Plus e Business, a cota oscila entre 5 a 45 mensagens/prompts dependendo do consumo e do modelo selecionado. Entender o funcionamento das janelas temporais é essencial para evitar bloqueios inesperados.

8 Estratégias para economizar tokens e elevar a eficiência

1. Gerenciamento das Cotas de Limite (5 Horas vs. Semanal)

Muitos usuários ignoram a existência da janela temporária de 5 horas. Se você estourar essa cota menor durante uma sessão intensa de desenvolvimento, ficará temporariamente bloqueado no Codex, mesmo que ainda possua cota no limite semanal.

Administre o ritmo de envios para não travar seu trabalho no meio do expediente.
Fique de olho nas mensagens de aviso no painel antes de iniciar tarefas massivas.

2. Escolha o modelo adequado para cada tamanho de tarefa

Utilizar um modelo topo de linha para alterar uma simples cor de texto é a maneira mais rápida de queimar cota. Distribua o trabalho de forma inteligente:

Astra: Ideal para investigação de bugs difíceis, problemas desconhecidos e planejamento arquitetural.
Sol: Perfeito para a implementação contínua de funcionalidades longas e complexas.
Terra: Indicado para alterações rotineiras de código e refatoração leve.
Luna: A escolha certa para tarefas pequenas que não afetam regras de negócio (ex: mudar fontes, ajustar títulos e categorizar dados).

3. Teste o Astra em nível baixo (Low) antes do Sol em nível alto (High)

O nível de esforço de raciocínio (effort) impacta diretamente o consumo de tokens. O modo High faz o agente de IA pensar por mais tempo, queimando uma quantidade considerável da cota em cada resposta.

Insight valioso: Em muitos casos práticos, rodar o modelo superior Astra no Low entrega um resultado excelente de primeira, economizando até 5 prompts de um modelo inferior configurado em Sol no High.

4. Cuidado com o modo Fast (Ícone de raio)

Ao contrário de outros agentes de código onde o modo rápido simplifica o raciocínio para gastar menos, no Codex o modo Fast entrega a mesma resposta em menor tempo, mas cobra um custo significativamente maior em tokens.

Verifique no painel se o ícone de raio ⚡ Fast está desativado.
Mantenha o modo rápido desligado a menos que precise de uma resposta crítica imediatamente.

5. Prompts precisos valem mais do que esforço alto

Aumentar o effort do modelo quando ele erra uma tarefa raramente resolve o problema. Na grande maioria das vezes, o erro acontece porque a IA não tinha informações suficientes.

Perca alguns minutos aprimorando a especificação e o contexto no seu prompt.
Pergunte ao agente de IA: "Você tem alguma dúvida sobre os requisitos fornecidos?" antes de pedir a execução.
Defina uma regra clara de conclusão (Definition of Done), como: "Considere a tarefa concluída apenas se os requisitos foram atentidos e todos os testes unitários passarem e com porcentagem de >=80% de cobertura."

6. Solicite entregas fracionadas e em etapas

Pedir ao agente de IA que desenvolva uma aplicação inteira ou uma funcionalidade gigante de uma só vez satura a janela de contexto e estoura a cota rapidamente, resultando em códigos incompletos e retrabalho.

Solicite entregas pequenas e modulares.
Testes e aprove cada etapa antes de avançar para a próxima instrução.

7. Utilize arquivos de checkpoint para reiniciar sessões

Sessões muito longas acumulam todo o histórico do chat no contexto de entrada, fazendo com que cada nova mensagem custe milhares de tokens desnecessários.

Para trocar de sessão sem perder o histórico do projeto, siga estes passos:

No final da sessão atual, peça: "Crie um arquivo checkpoint.md na raiz com no máximo 20 linhas contendo o que foi concluído, decisões tomadas, comandos de testes e o que falta fazer."
Abra uma nova sessão, selecione o modelo desejado e envie: "Leia o arquivo checkpoint.md e execute apenas o requisito [REQUISITO-1.md]."
Sempre verifique se a nova sessão não alterou o modelo automaticamente para a opção padrão.

8. Resets manuais nas configurações da conta

Em atualizações de versão de modelos, a OpenAI costuma conceder resets da cota semanal para os usuários.

Acesse as opções navegando em Settings > Usage no seu painel.
Verifique se há algum botão de reset disponível.
Atenção: Guarde o reset para quando a sua cota semanal realmente tiver esgotado. Ativá-lo pela metade fará com que você perca o saldo restante.

Considerações finais

Economizar tokens é uma questão de postura e metodologia. Ao aplicar pequenas mudanças, como configurar corretamente os níveis de esforço, dividir tarefas em etapas e utilizar checkpoints de contexto, você garante uma experiência fluida no desenvolvimento auxiliado por agente de IA, extraindo a máxima performance dos modelos GPT e Codex sem interrupções indesejadas.

Feito!

O marco que mudou a Inteligência Artificial Generativa

2026-09-04T18:00:00.000-03:00

Se você já utilizou o ChatGPT, o Claude, o Gemini ou qualquer outro modelo de linguagem avançado, saiba que toda a tecnologia por trás dessas ferramentas deriva de um único artigo acadêmico publicado em 2017: "Attention Is All You Need".

No presente artigo, vamos desmistificar o resumo completo desse paper revolucionário, entender por que ele foi o divisor de águas no Processamento de Linguagem Natural (PLN) e explorar os componentes fundamentais que tornam a arquitetura Transformer tão poderosa.

O Problema das Redes Recorrentes (RNNs e LSTMs)

Antes do lançamento do artigo, os modelos de IA utilizados para tarefas de linguagem (como tradução automática) baseavam-se primariamente em RNNs (Recurrent Neural Networks) e LSTMs (Long Short-Term Memory).

Essas arquiteturas apresentavam dois grandes gargalos:

Processamento Sequencial: O texto precisava ser lido palavra por palavra, em ordem. Isso impedia a paralelização dos cálculos em GPUs, tornando o treinamento extremamente lento.
Perda de Contexto Longo: À medida que a distância entre as palavras aumentava, o modelo tendia a "esquecer" informações cruciais do início do texto.

Para resolver essa limitação, os pesquisadores do Google Brain e do Google Research propuseram uma mudança radical: eliminar completamente a recorrência e confiar exclusivamente em um mecanismo de atenção.

O Coração da Arquitetura: Self-Attention (Autoatenção)

O pilar central do artigo é o mecanismo de Scaled Dot-Product Attention. A ideia é calcular o grau de relação entre todas as palavras da frase simultaneamente, independentemente da distância em que estejam uma da outra.

Figura 1: Mecanismo de Scaled Dot-Product Attention e Multi-Head Attention. Fonte: Vaswani et al. (2017).

Como funciona o cálculo com Query (Q), Key (K) e Value (V)?

Para entender a matemática de forma intuitiva, pense no mecanismo de atenção como uma busca em um banco de dados:

Query (Q): O que uma palavra específica está "procurando" no restante da frase para entender seu próprio contexto.
Key (K): A "etiqueta" de identificação que cada palavra da frase oferece.
Value (V): A informação semântica contida na palavra.

A fórmula matemática oficial do Scaled Dot-Product Attention apresentada no artigo é:

Attention(Q, K, V) = softmax( (Q * K^T) / sqrt(d_k) ) * V

Onde o processo ocorre nas seguintes etapas:

Multiplicação Q * K^T: Gera a pontuação de afinidade entre cada par de palavras.
Escala por sqrt(d_k): Normaliza os valores dividindo pela raiz quadrada da dimensão das chaves, evitando gradientes excessivamente grandes durante o treinamento.
Função softmax: Converte as pontuações em probabilidades (pesos de atenção que somam 1).
Multiplicação por V: Aplica esses pesos de atenção aos valores semânticos, gerando o vetor final contextualizado.

As Inovações-Chave do Transformer

Figura 2: Arquitetura completa do Transformer (Encoder-Decoder). Fonte: Vaswani et al. (2017).

1. Multi-Head Attention (Atenção Multi-Cabeça)

Em vez de calcular a atenção apenas uma vez, o modelo divide as projeções de Q, K e V em múltiplas "cabeças" (heads). Pressione Ctrl + C ou navegue pelos dados para perceber que isso permite à rede neural prestar atenção em diferentes aspectos da frase simultaneamente (por exemplo, uma cabeça foca em relações gramaticais, enquanto outra foca em entidades ou contexto de longo prazo).

2. Positional Encoding (Codificação Posicional)

Como o Transformer processa todos os tokens de forma paralela, ele perde a noção nativa de ordem no texto. Para resolver isso, os autores adicionaram vetores contendo funções senoidais ao embedding inicial de cada token, injetando a informação da posição relativa de cada palavra.

3. Arquitetura Encoder-Decoder

O modelo original foi projetado para tradução automática, dividindo-se em duas partes:

Encoder: Processa e codifica o texto de entrada.
Decoder: Gera a saída token por token, utilizando uma variação chamada Masked Multi-Head Attention para garantir que o modelo não acesse os tokens futuros durante a geração.

Considerações finais

O artigo "Attention Is All You Need" não foi apenas uma melhoria incremental; foi a pedra fundamental para toda a era moderna dos Large Language Models (LLMs). Ao abandonar as redes sequenciais e colocar a atenção paralela no centro da arquitetura, os pesquisadores viabilizaram o treinamento de modelos em escala sem precedentes.

Referências

VASWANI, Ashish et al. Attention is all you need. In: Advances in Neural Information Processing Systems (NeurIPS), 30., 2017, Long Beach. Proceedings... Long Beach: NIPS, 2017. p. 5998-6008. Disponível em: <https://arxiv.org/abs/1706.03762>. Acesso em: 04 set. 2026.

Feito!

Entendendo os algoritmos de ordenação clássicos com Big O

2026-09-02T18:00:00.000-03:00

Quantas vezes você já precisou ordenar uma lista de elementos em sua aplicação e simplesmente chamou o método nativo .sort() da linguagem de sua preferência? Seja em JavaScript, Python ou Java, é extremamente comum confiarmos cegamente nessas abstrações no nosso dia a dia de desenvolvimento.

No entanto, você já se perguntou qual algoritmo está rodando por trás dessa instrução e até onde ele continua sendo eficiente? Em um cenário real com milhões de registros, confiar em um método sem conhecer sua complexidade computacional pode ser a diferença entre um sistema performático e um colapso total de processamento.

Exploraremos a teoria, a notação Big O e os pseudocódigos dos principais algoritmos de ordenação: Selection Sort, Quick Sort e Bubble Sort.

1. A Armadilha da Abstração e a Notação Big O

Quando trabalhamos com conjuntos pequenos de dados, como 30 ou 100 itens, quase qualquer algoritmo apresentará um tempo de resposta imperceptível. Porém, a engenharia de software exige que pensemos em grande escala.

Para medir o impacto do volume de dados no tempo de execução, utilizamos a Notação Big O. O termo O(n) indica que o tempo de execução cresce proporcionalmente ao número de elementos n da lista.

Regra importante: Ignorando as Constantes

Na análise assintótica do Big O, as constantes matemáticas são desconsideradas. Por exemplo, um algoritmo que faz O(1/2 * n²) operações é simplificado diretamente para O(n²). Isso acontece porque, quando n chega à casa dos milhões ou bilhões, cortar o tempo pela metade continua deixando o número na mesma ordem de grandeza astronômica.

2. Selection Sort (Ordenação por Seleção)

O Selection Sort é um dos algoritmos mais intuitivos e simples. A lógica consiste em percorrer a lista inteira, encontrar o menor (ou maior) elemento, posicioná-lo no início (ou em uma nova lista) e repetir o processo para os elementos restantes.

Complexidade de Tempo

Pior caso: O(n²)
Caso médio: O(n²)
Melhor caso: O(n²)

Como o algoritmo precisa realizar comparações aninhadas para cada item da lista, seu comportamento é quadrático em todos os cenários.

Pseudocódigo: Selection Sort

Veja a estrutura básica que você pode traduzir para a sua linguagem favorita:

funcao selectionSort(lista)
    n = tamanho(lista)
    
    para i de 0 ate n - 1 faca
        indiceMenor = i
        
        para j de i + 1 ate n - 1 faca
            se lista[j] < lista[indiceMenor] entao
                indiceMenor = j
            fimSe
        fimPara
        
        se indiceMenor != i entao
            trocar(lista[i], lista[indiceMenor])
        fimSe
    fimPara
    
    retornar lista
fimFuncao

3. Quick Sort: A Estratégia Dividir para Conquistar

O Quick Sort é um dos algoritmos de ordenação mais eficientes e utilizados na prática (inclusive compondo bibliotecas padrão de linguagens como C e Java). Ele opera através da estratégia de Dividir para Conquistar utilizando a recursão.

Como Funciona o Quick Sort

Caso Base: Listas com 0 ou 1 elemento já estão ordenadas por natureza. A recursão para aqui.
Escolha do Pivô: Seleciona-se um elemento da lista para ser a referência (pivô).
Particionamento: A lista é dividida em duas sublistas: uma com elementos menores que o pivô e outra com elementos maiores.
Recursão e Junção: O Quick Sort é chamado recursivamente para as sublistas, e o resultado final é combinado: [menores] + [pivô] + [maiores].

Complexidade de Tempo

Caso médio: O(n log n). O fator log n vem da divisão sucessiva do problema ao meio, enquanto o n deriva do loop de particionamento.
Pior caso: O(n²). Ocorre quando a escolha do pivô é ruim (por exemplo, escolher sempre o maior ou menor elemento em uma lista que já está ordenada).

Pseudocódigo: Quick Sort

Abaixo está a implementação conceitual recursiva do Quick Sort:

funcao quickSort(lista)
    se tamanho(lista) < 2 entao
        retornar lista // Caso Base
    fimSe

    pivo = lista[0] // Escolhendo o primeiro elemento como pivô
    menores = listaVazia()
    maiores = listaVazia()

    para cada elemento em lista[1..fim] faca
        se elemento <= pivo entao
            adicionar(menores, elemento)
        senao
            adicionar(maiores, elemento)
        fimSe
    fimPara

    retornar concatenar(quickSort(menores), pivo, quickSort(maiores))
fimFuncao

4. Bubble Sort (Ordenação por Bolha)

O Bubble Sort é frequentemente ensinado em cursos introdutórios. Ele percorre a lista repetidamente, comparando pares de elementos adjacentes e trocando-os de lugar se estiverem na ordem errada. Os maiores elementos "flutuam" para o final da lista como bolhas.

Complexidade de Tempo

Pior caso: O(n²)
Caso médio: O(n²)
Melhor caso: O(n) (quando a lista já está ordenada e há uma flag de controle de trocas).

Pseudocódigo: Bubble Sort

funcao bubbleSort(lista)
    n = tamanho(lista)
    
    para i de 0 ate n - 1 faca
        trocou = falso
        
        para j de 0 ate n - i - 2 faca
            se lista[j] > lista[j + 1] entao
                trocar(lista[j], lista[j + 1])
                trocou = verdadeiro
            fimSe
        fimPara
        
        // Se nenhuma troca ocorreu nesta passagem, a lista ja esta ordenada
        se nao trocou entao
            interromper
        fimSe
    fimPara
    
    retornar lista
fimFuncao

5. Tabela Comparativa de Desempenho

Para visualizar a diferença gritante de escala entre as complexidades de tempo, considere o impacto hipotético na execução ao ordenar um conjunto com 1.000 elementos:

Algoritmo	Complexidade (Caso Médio)	Complexidade (Pior Caso)	Desempenho Estimado (1.000 itens)
Selection Sort	`O(n²)`	`O(n²)`	Lento (~27 horas em escala comparativa)
Bubble Sort	`O(n²)`	`O(n²)`	Muito Lento (Loops Aninhados)
Quick Sort	`O(n log n)`	`O(n²)`	Muito Rápido (~996 segundos na mesma escala)

Considerações finais

Conhecer o que está por trás do método .sort() transforma a forma como escrevemos código. Embora na maioria dos casos as funções nativas sejam extremamente otimizadas, compreender o comportamento do Quick Sort, do Selection Sort e a mecânica das partições e da notação Big O fornece a autonomia necessária para diagnosticar gargalos e tomar decisões arquiteturais corretas ao trabalhar com grandes volumes de dados.

Agora que você possui o pseudocódigo em mãos, escolha a sua linguagem de programação principal (seja JavaScript, Python, C#, Java ou Go) e implemente cada um desses algoritmos para fixar o aprendizado na prática!

Feito!

Como fazer perguntas certas

2026-08-28T18:00:00.000-03:00

No universo do desenvolvimento de software, tecnologias mudam, requisitos evoluem, frameworks e linguagens se transformam. No entanto, uma habilidade permanece atemporal e crucial para a eficiência de qualquer profissional: a capacidade de obter informações precisas rapidamente. E o caminho mais curto para isso é saber fazer as perguntas certas.

O Problema da Pergunta Vaga (e por que ela falha sempre)

O exemplo mais clássico e desastroso de comunicação no dia a dia da tecnologia é a famigerada mensagem: "Oi, o aplicativo está dando erro. Você pode me ajudar?".

O exemplo do aplicativo dar erro, sem dizer qual é o problema ou onde ele ocorre, é típico de pessoas que não sabem se comunicar. Esse tipo de abordagem parte da falsa premissa de que quem vai responder sabe tudo de cabeça ou adivinhará o contexto por telepatia. Na realidade, ninguém sabe tudo; o que profissionais experientes possuem é padrão de reconhecimento acumulado. Quando você fornece a mensagem de erro exata e o contexto, fica exponencialmente mais fácil para quem responde apontar a solução mais provável.

Humano vs. Assistente de IA: A Regra é exatamente a mesma

O mesmo se aplica em como fazer perguntas certas para um humano e para um assistente de IA. Se você fizer essa mesma pergunta ruim de exemplo, nenhum humano e nenhum assistente de IA saberá responder. Já o exemplo de pergunta certa facilita tanto para o humano quanto para o assistente de IA.

A comunicação é importante para saber tirar dúvidas com um dev sênior ou com um assistente de IA, pois se não souber se comunicar bem de forma detalhada, fica difícil ajudar. Enquanto o desenvolvedor sênior perde tempo e contexto tentando extrair informações de você, a IA acabará gerando respostas genéricas, códigos irrelevantes ou alucinações. Em ambos os casos, o princípio de Garbage In, Garbage Out (Entrada ruim, saída ruim) se aplica perfeitamente.

Estrutura de uma pergunta eficiente

Uma boa pergunta economiza tempo e demonstra respeito pelo fluxo de trabalho do outro. Ela deve conter obrigatoriamente:

Contexto claro: Qual tarefa, ticket ou projeto você está executando.
O erro exato: Mensagem de exceção (ex: NullPointerException), logs relevantes ou comportamento retornado.
O que já foi tentado: Hipóteses que você já testou ou verificações que realizou no código.
Localização: A classe, endpoint ou função onde o problema ocorre.

O ciclo das 2 horas: Equilíbrio entre autonomia e dependência

Ao buscar suporte técnico, a maioria dos devs cai em dois extremos perigosos: ou passam dias travados sem perguntar nada (prejudicando a deadline e as dailies), ou perguntam a cada pequeno obstáculo sem sequer tentar pesquisar (tornando-se um fardo para a equipe).

Para encontrar o ponto de equilíbrio e manter a produtividade alta, adote a regra do Ciclo de 2 Horas antes de solicitar ajuda:

10 a 15 minutos: Busque por um código parecido ou uma funcionalidade similar dentro do próprio projeto para se basear.
5 a 10 minutos: Consulte a documentação interna/da linguagem ou questione seu assistente de IA preferido.
30 a 70 minutos: Tente implementar e debugar a solução na prática.

Se após esse tempo o problema persistir, é o momento exato de pedir ajuda a um colega, trazendo todo o contexto estruturado do que você aprendeu e testou nessas duas horas.

Exceções ao ciclo de 2 Horas

Existem cenários onde você não deve esperar o ciclo terminar para pedir suporte:

Tarefas com deadlines urgentes em ambiente de produção.
Devs iniciantes ou recém-chegados que receberam uma demanda crítica por engano.
Trabalhos que exigem atuação pareada (pair programming) ou em times globais.

Considerações finais: Documente tudo

Por fim, após resolver qualquer dúvida, seja com a ajuda do seu time ou do assistente de IA, documente tudo o que você aprendeu. Manter um registro simples de soluções serve como base de conhecimento para consultas futuras, ajuda seu "eu do futuro" e contribui para a evolução técnica de toda a equipe.

Saber se comunicar com clareza e fazer as perguntas certas é a ferramenta mais poderosa para acelerar sua carreira e se destacar como um desenvolvedor eficiente.

Feito!

Meu histórico do git parece um desastre, como eu conserto?

2026-08-27T18:00:00.000-03:00

O Problema

Você abriu o git log e encontrou algo assim:

fix stuff
wip
tentativa 2
eslint de novo
bug fix
como assim nao funciona
REVERT
feat: adds feature X (nao funciona ainda)
me ajuda por favor
fix: arruma o fix anterior

Seu histórico está bagunçado, commits inúteis poluem o repositório, e o pior: alguém pode ver isso no pull request.

A Causa

Falta de disciplina com mensagens de commit, commits demais para Changes pequenos, e uso incorreto do git add . commitando tudo junto.

A Solução

1. Reescreva os últimos N commits com rebase interativo

git rebase -i HEAD~5

Isso abre um editor com os últimos 5 commits. Você pode:

pick   abc1234 feat: adiciona login
squash def5678 fix: ajusta layout
squash ghi9012 wip: tentativa 2
pick   jkl3456 feat: adiciona logout

squash combina o commit no anterior. fixup faz o mesmo mas descarta a mensagem.

2. Corrija a última mensagem de commit

git commit --amend -m "feat: adiciona autenticação com JWT"

3. Desfaça o último commit mantendo as mudanças

git reset --soft HEAD~1

As mudanças ficam staged para você reorganizar com git add seletivo.

4. Desfaça completamente o último commit

git reset --hard HEAD~1

Cuidado: isso apaga as mudanças permanentemente.

5. Limpe dados sensíveis já commitados

git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch .env' \
  --prune-empty --tag-name-filter cat -- --all

Depois force o push:

git push origin --force --all

6. Organize com staging seletivo

git add -p

Isso abre um modo interativo onde você escolhe pedaços específicos do arquivo para commitar.

Antes vs Depois

Antes	Depois
fix stuff	feat: adiciona autenticação JWT
wip	feat: adiciona tela de login
tentativa 2	fix: ajusta validação do formulário
como assim nao funciona	test: adiciona testes unitários
REVERT	chore: atualiza dependências

Regra de Ouro

Uma mensagem de commit deve explicar o quê mudou e por quê. Se você não consegue explicar em uma linha, talvez deveria ser dois commits.

Nunca force push em branches compartilhadas sem avisar o time.

Feito!

Por que minha query SQL está demorando 30 segundos?

2026-08-25T12:00:00.000-03:00

O Problema

Você tem uma tabela pedidos com milhões de registros e precisa buscar pedidos de um cliente específico. A query simples assim demora uma eternidade:

SELECT * FROM pedidos WHERE cliente_id = 12345;

O MySQL retorna 30 segundos de espera. O PostgreSQL idem. O SQLite? Nem fala.

A Causa

Tabela sem índice na coluna cliente_id. O banco faz Full Table Scan — lendo todos os registros para encontrar os que correspondem ao critério.

A Solução

1. Adicione um índice

CREATE INDEX idx_pedidos_cliente_id ON pedidos(cliente_id);

Resultado: de 30s para 0.003s

2. Use EXPLAIN para analisar

EXPLAIN SELECT * FROM pedidos WHERE cliente_id = 12345;

Veja se o plano mostra Using index (bom) ou Using filesort/Using temporary (ruim).

3. Evite SELECT *

 Ruim
SELECT * FROM pedidos WHERE cliente_id = 12345;

Bom
SELECT id, valor, data FROM pedidos WHERE cliente_id = 12345;

4. Verifique os índices existentes

SHOW INDEX FROM pedidos;

5. Use composição de índices quando necessário

-- Para queries que filtram por cliente E data
CREATE INDEX idx_pedidos_cliente_data ON pedidos(cliente_id, data DESC);

Resultado Final

Métrica	Antes	Depois
Tempo de resposta	30s	0.003s
Full Table Scan	Sim	Não
Uso de memória	Alto	Baixo

Regra de Ouro

Se uma coluna aparece em WHERE, JOIN ou ORDER BY, considere criar um índice nela.

Índices não são mágicos — eles ocupam espaço em disco. Mas na maioria dos casos, o ganho de performance vale muito mais que o custo de armazenamento.

Feito!

15 anos de blog

2026-08-21T00:00:00.000-03:00

O blog está completando hoje, 21 de Agosto de 2026, 15 anos!

Gostaria de agradecer a todos pelo prestígio e a paciência de ler os posts que são publicados. Espero continuar compartilhando conhecimentos no blog para nossos leitores. Continuem prestigiando e divulgando o blog Mundo da Computação Integral, assim aumentamos nossa comunidade.

Seu Lint não esta configurado (e isso é um risco)

2026-08-20T18:00:00.000-03:00

Três revisores de código passaram por este bug. Nenhum viu.

O pull request tinha 200 linhas. Testes passando. Code review aprovado.

Mas escondido na linha 47, um simples == em vez de === estava desabilitando uma feature inteira de pagamento.

O JavaScript, com sua tipagem dinâmica, tratou o valor 0 como false.

E o que deveria ser uma verificação de status virou um gate que bloqueava todo o fluxo de checkout.

O time de suporte começou a receber tickets de "pagamento não processa".

A equipe de pagamentos revisou o gateway. Tudo normal.

O backend revisou a API. Tudo normal.

O frontend revisou o formulário. Tudo normal.

A solução levou 5 minutos. O debug levou 3 dias.

E o pior? Isso poderia ter sido evitado com uma configuração no ESLint:

"eqeqeq": ["error", "always"]

Uma linha no .eslintrc. Uma regra que impede exatamente esse tipo de bug.

Mas a equipe não tinha o lint configurado no CI. O commit passava sem verificação de qualidade.

Adicionamos:

Regra eqeqeq no ESLint, == vira erro, não warning.
Pre-commit hook com husky impede o commit se o lint falhar.
CI pipeline que rejeita PR com lint errors, nenhum merge sem qualidade.

A lição?

Bugs não são sobre código complexo. São sobre código simples que ninguém prestou atenção.

== e === parecem iguais. Mas um aceita 0 == false como true.

O outro te protege.

Qual foi o bug mais "besta" que você já encontrou em produção? Compartilha aí.

Feito!

Seu container está com o relogio errado (e você não sabe)

2026-08-19T18:00:00.000-03:00

Toda segunda-feira às 8h da manhã, a equipe recebia um tsunami de tickets de "não consigo logar".

O sistema de autenticação estava quebrando religiosamente, toda segunda-feira.

Depois de 3 semanas investigando, encontrei o culpado:

O JWT tinha expiresIn: "7d", parecia correto, né?

Mas o relógio do servidor de autenticação estava 3 minutos adiantado.

E o servidor que validava os tokens? Com o relógio correto.

Resultado: o token expirava antes de deveria. E a diferença foi acumulando com o drift do relógio.

Toda segunda-feira, o acumulado de 7 dias de drift ultrapassava o threshold de tolerância.

Usuários bloqueados. Help desk sobrecarregado. Time de DevOps no modo DETETIVE.

A solução foi simples, mas ninguém pensou nela antes:

Sincronizar NTP com chronyd dentro do container, porque container sem NTP é uma bomba relógio
Middleware de refresh com margem de 5 minutos antes da expiração, o token renovava antes de vencer, eliminando a janela de falha.
Monitoramento de drift de relógio entre servidores — se a diferença passar de 1 minuto, alerta automático.

A moral da história?

Às vezes o bug não está no código. Está na infraestrutura que sustenta o código.

Nós revisamos o JWT, testamos a lógica de expiração, validamos o fluxo de refresh. Tudo parecia perfeito.

O problema estava em algo que ninguém olhou: o relógio do container.

Você já perdeu horas debugando algo que parecia código, mas era infraestrutura?

Feito!

Você ainda programa como em 2023? A nova engenharia de agentes de IA em 2026

2026-08-13T18:00:00.000-03:00

Durante muito tempo, falar sobre IA no desenvolvimento de software significava, principalmente, aprender a escrever bons prompts.

Você tinha um problema, descrevia o contexto para uma LLM, fazia algumas perguntas, copiava o código gerado, ajustava o que fosse necessário e seguia para a próxima tarefa.

Esse modelo ainda funciona.

Mas ele já não representa o estágio mais avançado do desenvolvimento assistido por IA.

Em 2026, a discussão mudou.

O diferencial não está mais apenas em saber conversar com uma LLM, mas em compreender como construir sistemas que utilizam modelos de linguagem de maneira estruturada, previsível e integrada ao ciclo de desenvolvimento.

É nesse contexto que começam a ganhar força conceitos como Graph Engineering, Loop Engineering, sistemas de memória, SDD (Spec Driven Development), MCP e arquiteturas de agentes.

A pergunta, portanto, deixou de ser:

"Qual prompt devo escrever?"

E passou a ser:

"Como devo projetar o sistema que utiliza a LLM?"

O fim da era do prompt simples

O prompt continua sendo importante.

Porém, ele é apenas uma camada de um sistema muito maior.

Uma aplicação real possui regras de negócio, arquitetura, padrões de código, banco de dados, autenticação, testes, observabilidade, requisitos não funcionais e dezenas ou centenas de arquivos.

Nesse cenário, um prompt isolado começa a perder eficiência.

O agente precisa saber:

Qual é a arquitetura do projeto?

Quais padrões devem ser utilizados?

Quais arquivos podem ser modificados?

Quais regras de negócio existem?

Quais ferramentas estão disponíveis?

Como validar o resultado?

O que já foi executado?

Quais decisões foram tomadas anteriormente?

Quando deve parar ou pedir intervenção humana?

Isso transforma o problema.

Não estamos mais falando simplesmente de Prompt Engineering.

Estamos entrando no território da Engineering for AI Agents.

De Prompt Engineering para System Engineering

O prompt continua sendo importante. Porém, ele é apenas uma camada de um sistema muito maior.

Um agente moderno pode ser representado conceitualmente como:

Contexto → Modelo → Ferramentas → Memória → Execução → Feedback → Validação → Novo ciclo

O desenvolvedor passa a projetar esse fluxo.

Por isso, uma habilidade importante para os próximos anos será entender como uma LLM participa de um sistema maior.

O profissional não precisa apenas saber pedir:

"Faça isso."

Ele precisa conseguir especificar:

"Este é o objetivo, estas são as restrições, estas são as ferramentas disponíveis, este é o contexto relevante, estes são os critérios de aceitação e este é o mecanismo utilizado para validar o resultado."

Essa diferença parece pequena.

Na prática, ela muda completamente a forma de trabalhar.

Graph Engineering: quando o agente deixa de seguir apenas uma sequência

Um dos conceitos mais importantes nessa evolução é pensar o agente como um grafo de execução.

Em uma abordagem simples, temos:

Prompt → LLM → Resposta

Em um sistema mais sofisticado:

Entrada → Análise → Planejamento → Ferramenta → Observação → Decisão → Nova ferramenta → Validação → Resultado

Agora existem diferentes estados e caminhos possíveis.

Por exemplo, imagine um agente responsável por implementar uma funcionalidade.

Ele pode analisar a especificação, identificar os componentes envolvidos, consultar o código existente, verificar as dependências, alterar os arquivos necessários, executar os testes, analisar falhas, corrigir a implementação e executar novamente até que os critérios sejam atendidos.

Isso é muito mais próximo de um grafo de execução do que de um simples chatbot.

O desenvolvedor passa a pensar em nós, estados, transições, condições e ferramentas.

A pergunta deixa de ser:

"Qual prompt funciona melhor?"

E passa a ser:

"Qual fluxo de execução produz um resultado confiável?"

Loop Engineering: o agente precisa saber iterar

Outro conceito importante é o Loop Engineering.

Uma LLM, sozinha, gera uma resposta.

Um agente precisa conseguir trabalhar em ciclos.

Um loop típico pode ser:

Planejar → Executar → Observar → Avaliar → Corrigir → Executar novamente

Por exemplo:


Especificação
↓
Planejamento
↓
Implementação
↓
Executar testes
↓
Passou?
↓
Sim → Finalizar
Não → Analisar erro → Corrigir → Executar novamente

Essa arquitetura aproxima o agente de um processo de engenharia.

O objetivo não é simplesmente gerar código.

É produzir um resultado verificável.

Isso também explica por que agentes capazes de executar ferramentas, rodar testes, consultar documentação e analisar resultados são significativamente mais interessantes do que sistemas que apenas geram texto.

Memória: o agente não pode depender apenas do contexto imediato

Outro problema surge quando começamos a trabalhar com tarefas maiores.

Uma conversa possui contexto limitado.

Mesmo que modelos modernos suportem janelas de contexto enormes, isso não significa que devemos simplesmente colocar tudo dentro do prompt.

Um sistema de agentes pode utilizar diferentes mecanismos de memória.

Podemos pensar, por exemplo, em:

Memória de curto prazo

Informações necessárias para a tarefa atual.

Memória de longo prazo

Conhecimentos e decisões persistentes entre diferentes sessões.

Memória operacional

Estado atual da execução do agente.

Memória semântica

Informações recuperadas por similaridade ou significado.

Memória episódica

Registro de experiências, decisões e resultados anteriores.

Isso aproxima a arquitetura de agentes de conceitos tradicionais de sistemas distribuídos, bancos de dados e sistemas cognitivos.

E novamente surge uma mudança de mentalidade.

O desenvolvedor não pergunta apenas:

"Qual informação devo colocar no prompt?"

Ele começa a perguntar:

"Qual informação precisa existir, onde será armazenada e em qual momento deve ser recuperada?"

RAG não é apenas um mecanismo de busca

O mesmo acontece com RAG.

Inicialmente, RAG foi apresentado de forma relativamente simples:

Documento → Embedding → Vector Database → Similarity Search → LLM

Mas aplicações reais exigem muito mais.

É necessário decidir o que será indexado, como os documentos serão fragmentados, quais metadados serão armazenados, como será feita a recuperação, quais filtros serão aplicados e como diferentes estratégias de busca serão combinadas.

Isso transforma RAG em um problema de arquitetura.

Mais uma vez, estamos saindo do simples prompt e entrando na engenharia do sistema.

SDD: especificação antes da implementação

Outro movimento importante é o Spec Driven Development (SDD).

A ideia central é deslocar parte do foco do desenvolvimento para a especificação explícita do que deve ser construído.

Em vez de simplesmente dizer:

"Crie um endpoint para usuários."

Podemos definir algo muito mais estruturado:

Objetivo:

Criar endpoint para cadastro de usuários.

Regras:

E-mail deve ser único.
Senha deve ser armazenada com hash.
Nome é obrigatório.
API deve retornar HTTP 201 após criação.

Critérios de aceitação:

Usuário válido pode ser criado.
E-mail duplicado deve ser rejeitado.
Dados inválidos devem retornar erro de validação.
Testes automatizados devem cobrir os cenários principais.

A diferença é enorme.

A especificação deixa de ser apenas documentação para humanos.

Ela pode se tornar contexto operacional para agentes.

O agente recebe uma especificação, interpreta os requisitos, modifica o projeto e utiliza os critérios de aceitação para verificar seu próprio trabalho.

Isso cria uma relação interessante:

Especificação → Agente → Implementação → Testes → Validação

O código passa a ser uma consequência da especificação.

MCP e a conexão dos agentes com o mundo real

Um agente também precisa interagir com sistemas externos.

Git, bancos de dados, sistemas internos, ferramentas de observabilidade, documentação, IDEs e outros serviços podem fazer parte do ambiente de desenvolvimento.

É nesse contexto que protocolos como o Model Context Protocol (MCP) ganham importância.

A ideia não é simplesmente fornecer mais contexto ao modelo.

É estabelecer uma forma padronizada para conectar modelos e agentes a ferramentas e fontes de contexto.

Isso pode transformar uma LLM de um sistema que apenas responde perguntas em um componente capaz de interagir com o ambiente.


LLM / Agente
├── Git
├── Banco de dados
├── Documentação
├── APIs
└── Ferramentas

O agente deixa de estar isolado.

Ele passa a operar dentro do ecossistema de desenvolvimento.

O novo papel do desenvolvedor

Tudo isso não significa que o desenvolvedor deixou de programar.

Na realidade, significa que algumas habilidades tradicionais continuam importantes enquanto outras passam a ganhar ainda mais relevância.

Software Engineering

Arquitetura, padrões, testes, qualidade, segurança e manutenção continuam fundamentais.

LLMs

É necessário entender conceitos como tokens, contexto, inferência, embeddings, temperatura, modelos e limitações.

Agent Engineering

É necessário compreender planejamento, ferramentas, loops, estados, memória e mecanismos de validação.

Context Engineering

É necessário saber fornecer ao modelo o contexto correto, no momento correto, sem simplesmente despejar informações.

Specification Engineering

É necessário transformar requisitos ambíguos em especificações claras e verificáveis.

Evaluation Engineering

É necessário medir se o agente realmente está produzindo resultados confiáveis.

Esse último ponto será especialmente importante.

Porque gerar uma resposta convincente não significa gerar uma resposta correta.

O problema dos agentes "mágicos"

Existe uma tendência de tratar agentes de IA como uma espécie de mágica.

Você fornece uma tarefa e espera que o agente resolva tudo.

Essa abordagem pode funcionar em demonstrações.

Em sistemas reais, ela é perigosa.

Um agente precisa de limites, permissões, observabilidade, validações, políticas de segurança, tratamento de erros, controle de custos, controle de contexto, mecanismos de recuperação e intervenção humana quando necessário.

Um agente sem arquitetura pode simplesmente automatizar o caos.

Por isso, quanto mais autônomo o sistema, mais importante se torna a engenharia por trás dele.

O desenvolvedor de 2026

Talvez a principal mudança esteja justamente aqui.

O desenvolvedor de 2026 não deveria ser definido como alguém que "sabe usar ChatGPT".

Isso é apenas uma pequena parte da competência.

Um profissional moderno precisa conseguir olhar para uma tarefa e identificar:

Qual parte é código?

Qual parte é especificação?

Qual parte é contexto?

Qual parte exige recuperação de conhecimento?

Qual parte pode ser delegada a um agente?

Qual parte precisa de validação automática?

Qual parte continua exigindo decisão humana?

Essa capacidade de decomposição provavelmente será mais valiosa do que simplesmente escrever prompts sofisticados.

Programar como em 2023 já não é suficiente

Em 2023, aprender a utilizar uma LLM já representava uma vantagem competitiva.

Em 2026, essa vantagem diminuiu.

O conhecimento está se tornando mais profundo.

Não basta saber conversar com o modelo.

É necessário saber projetar o sistema que conversa, executa, recupera informações, utiliza ferramentas, mantém estado, valida resultados e aprende com o próprio fluxo de execução.

A evolução pode ser resumida assim:


2023
Prompt Engineering
↓
2024
Context + RAG + Tools
↓
2025
Agents + MCP + Workflows
↓
2026
Graph Engineering
Loop Engineering
Memory Systems
Spec Driven Development
Evaluation Engineering
↓
Próxima etapa
AI-Native Software Engineering

Isso não significa que o prompt morreu.

Significa que ele deixou de ser o centro da arquitetura.

O prompt é apenas uma interface.

O verdadeiro diferencial está no sistema ao redor dele.

O futuro pertence a quem entende a arquitetura

A próxima geração de desenvolvedores não será formada apenas por pessoas capazes de escrever código rapidamente com auxílio de IA.

Será formada por profissionais capazes de projetar sistemas nos quais humanos, código, modelos, ferramentas, dados e agentes trabalham juntos.

Essa é uma mudança de paradigma.

A IA está deixando de ser apenas uma ferramenta de geração de código e começando a se tornar uma camada arquitetural do próprio processo de desenvolvimento.

Por isso, talvez a pergunta mais importante para um desenvolvedor em 2026 não seja:

"Você sabe usar IA para programar?"

Mas sim:

"Você sabe construir uma arquitetura na qual a IA consegue programar de forma controlada, verificável e contextualizada?"

Se a resposta ainda for não, talvez esteja na hora de ir além do prompt.

Porque a era de simplesmente conversar com a IA está dando lugar à era de engenheirar sistemas com IA.

Feito!

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

2026-07-22T18:00:00.000-03:00

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:

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.
Checkpoints: Pontos de interrupção estratégicos onde o progresso é validado antes de liberar a próxima fase.
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.
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):

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.
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.
Nível 3 (Time-based): Execuções agendadas ou disparadas por gatilhos de tempo no ambiente, sem você estar presente.
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:

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.
O agente possui meios de checar seu próprio trabalho? Se não, adicione suítes de testes ou linters.
Qual contexto essencial está na sua cabeça, mas não foi documentado no repositório?
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

2026-07-17T18:00:00.000-03:00

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?

2026-07-15T18:00:00.000-03:00

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

2026-07-13T18:00:00.000-03:00

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:

Salvar o binário diretamente no banco de dados: Utilizando tipos como BLOB (Binary Large Object) ou BYTEA.
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

2026-07-02T18:00:00.000-03:00

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

Criar um usuário administrador: nunca use o usuário padrão da distro.
Autenticação por chave SSH: sem senha, sem risco de força bruta.
Desabilitar login como root: o alvo favorito dos bots.
Desabilitar login por senha: se não aceita senha, não adianta chutar.
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

2026-07-01T18:00:00.000-03:00

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:

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.
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.
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.
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

2026-06-24T12:00:00.000-03:00

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

2026-06-22T18:00:00.000-03:00

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

2026-06-16T12:00:00.000-03:00

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!