Durante muitos séculos, qualquer pessoa podia olhar para os símbolos gravados nas paredes, templos e monumentos do antigo Egito. Eles estavam ali. Não tinham sido destruídos. Não tinham sido apagados. Não estavam escondidos. Ainda assim, a tradição capaz de lê-los havia desaparecido.

Os hieróglifos haviam sobrevivido. A informação permanecia fisicamente preservada enquanto a capacidade humana de interpretá-la se perdia. Foi preciso encontrar uma ponte.

A Pedra de Roseta continha essencialmente a mesma mensagem escrita em sistemas diferentes. Um deles, o grego antigo, ainda podia ser compreendido. A partir dessa ligação, tornou-se possível reconstruir gradualmente o significado de uma linguagem que durante séculos esteve diante dos nossos olhos sem que soubéssemos o que dizia.

Essa história contém uma distinção que talvez se torne cada vez mais importante com o avanço da inteligência artificial: preservar informação não é a mesma coisa que preservar a capacidade de compreendê-la.

Boa parte da discussão sobre os riscos da inteligência artificial concentra-se na possibilidade de perdermos o controle sobre sistemas cada vez mais capazes e autônomos — sistemas que possam enganar seus operadores, contornar restrições ou perseguir objetivos de maneiras que não previmos.

Talvez isso aconteça. Talvez não. Mas existe outro cenário, menos espetacular, que me parece receber menos atenção.

Nele, nada dá errado. As inteligências artificiais continuam melhorando. Tornam-se excelentes programadoras, médicas, engenheiras, matemáticas, escritoras e pesquisadoras. Não se rebelam. Não escapam de laboratórios. Não desenvolvem misteriosos instintos de autopreservação. Pelo contrário. Fazem exatamente aquilo que pedimos. E justamente por isso começamos a depender delas.

Isso, isoladamente, não seria particularmente novo. A história da tecnologia é, em grande parte, a história da construção de abstrações. Poucos programadores modernos precisam conhecer os detalhes elétricos dos transistores que executam seus programas. Um desenvolvedor pode construir uma aplicação sem compreender profundamente o kernel do sistema operacional, o compilador, o protocolo de rede ou o processo industrial usado para fabricar o processador.

Isso não representa uma falha da nossa civilização. Representa uma de suas maiores conquistas. Abstrações permitem que uma pessoa comece onde outra terminou. Não precisamos redescobrir eletricidade antes de projetar um computador nem reinventar álgebra antes de estudar cálculo. Construímos novas camadas sobre as anteriores e, com isso, avançamos.

Há, porém, uma propriedade importante nesse sistema que raramente percebemos. Embora nenhum indivíduo compreenda todas as camadas, ainda existem seres humanos em cada uma delas.

Eu não sei projetar um processador, mas existem pessoas que sabem. Elas, por sua vez, talvez não saibam construir todas as máquinas utilizadas para fabricá-lo, mas outras pessoas sabem.

O conhecimento está fragmentado e distribuído, porém continua existindo dentro da sociedade humana. Mais importante ainda: existe uma cadeia pela qual novos seres humanos podem aprender essas coisas. A inteligência artificial pode introduzir algo diferente.

Imagine um programador em 2030 trabalhando em um sistema complexo. Ele utiliza uma IA para implementar uma parte especialmente difícil. O resultado funciona. É testado, documentado e colocado em produção. Talvez aquele programador até compreenda bem o que foi feito.

Cinco anos depois, outra pessoa precisa adicionar uma funcionalidade sobre aquele componente. Ela não precisa compreender todos os detalhes internos porque uma nova geração de ferramentas de IA consegue modificar o sistema sem que quem a utiliza precise dominá-los.

Vinte anos depois, outra equipe trabalha algumas camadas acima. Setenta anos depois, aquele componente talvez ainda exista em alguma forma evoluída, agora cercado por décadas de outras abstrações construídas por humanos e máquinas.

O ponto importante é que ninguém decidiu esquecer como ele funciona. Talvez nenhuma pessoa tenha perdido um conhecimento que já possuía. O que pode acontecer é mais sutil: as novas gerações simplesmente nunca precisarem adquiri-lo.

Um especialista de hoje pode continuar sendo especialista até o fim da vida. O problema aparece quando perguntamos quem ocupará seu lugar. Especialistas não surgem espontaneamente. São produzidos por anos de prática, erros, tarefas banais, tentativas frustradas, repetição e contato direto com os problemas que um dia aprenderão a resolver.

Uma revisão publicada em 2026 na Trends in Cognitive Sciences resume evidências de que terceirizar cognição para sistemas de IA pode dificultar a aquisição de habilidades e contribuir para sua deterioração, embora os efeitos dependam de como a tecnologia é utilizada.

Há precedentes, em escala menor, para esse deslocamento. Em computação, esse processo é familiar. Gerações anteriores de programadores precisavam lidar muito mais diretamente com memória, arquitetura de computadores e linguagens de baixo nível. Hoje, é perfeitamente possível construir aplicações complexas começando por linguagens de alto nível, bibliotecas prontas e serviços de nuvem.

Vemos isso acontecer fora da computação também. Por séculos, cruzar um oceano exigia domínio de navegação astronômica — leitura de estrelas, sextantes, cronômetros e tábuas matemáticas. Com a disseminação dos sistemas eletrônicos de navegação, parte desse ensino deixou de parecer necessária. Na Marinha dos Estados Unidos, o NROTC deixou de ensinar navegação astronômica em 2000 e a Academia Naval a retirou do currículo em 2006. Em 2015, porém, a própria Marinha decidiu reintroduzir a técnica, justamente porque percebeu a vulnerabilidade de depender exclusivamente de sistemas eletrônicos que poderiam ficar indisponíveis ou ser afetados por ameaças cibernéticas.

Há uma lição importante nesse episódio:

uma capacidade pode deixar de ser economicamente necessária enquanto continua estrategicamente indispensável.

Essas mudanças, isoladamente, raramente são vistas como catástrofes. Pelo contrário: as abstrações tornaram a computação mais acessível e a navegação mais simples e precisa. Isso funcionou porque as camadas inferiores não desapareceram por completo: ainda havia engenheiros de hardware, compiladores, sistemas operacionais e redes, e ainda havia caminhos para alguém tornar-se um deles. O programador que começava mais acima podia, se necessário, descer a escada.

O risco que a IA introduz não é que uma nova geração deixe de aprender uma técnica específica. A história está cheia dessas transições. É que ela possa encurtar simultaneamente os caminhos de formação em muitas camadas — inclusive os caminhos que produzem as pessoas capazes de manter, explicar e reconstruir as abstrações anteriores.

Esse risco já começa a ser tratado como um problema estrutural na literatura. Avigail Ferdman argumenta que ambientes fortemente mediados por IA podem reduzir as oportunidades pelas quais capacidades humanas são cultivadas, e não apenas substituir tarefas depois que essas capacidades já existem.

Um programador experiente provavelmente passou milhares de horas escrevendo código que, hoje, uma inteligência artificial pode produzir instantaneamente. Um engenheiro aprendeu não apenas estudando projetos corretos, mas produzindo projetos ruins, vendo máquinas falharem e entendendo por que falharam. Grande parte daquilo que chamamos de trabalho é também treinamento para a próxima geração de especialistas. Quando automatizamos uma tarefa, portanto, não eliminamos apenas trabalho. Podemos eliminar também uma etapa do processo pelo qual alguém aprenderia a fazê-la.

Há também sinais iniciais no trabalho cotidiano. Em um estudo apresentado no CHI 2025, 319 trabalhadores do conhecimento relataram 936 usos de IA generativa; maior confiança na IA esteve associada a menor esforço de pensamento crítico autorrelatado, enquanto o trabalho cognitivo se deslocou para verificação, integração e supervisão das respostas. Isso não demonstra uma perda de competência ao longo de gerações, mas mostra que a forma de exercê-la já muda quando parte do raciocínio é delegada.

Inicialmente isso quase não seria percebido. Os especialistas formados antes da automação continuariam trabalhando. Depois se aposentariam. Uma nova geração conheceria melhor as ferramentas modernas, mas teria menos contato direto com as camadas inferiores. A geração seguinte teria ainda menos. Nada precisaria desaparecer de maneira brusca.

A cadeia poderia simplesmente se tornar cada vez mais longa, mais indireta e mais dependente das próprias máquinas. Até que um dia talvez descobríssemos algo curioso: nossa civilização ainda sabe operar seus sistemas, mas já não possui pessoas capazes de reconstruí-los a partir das camadas anteriores.

Isso não significa necessariamente colapso. Uma situação desse tipo poderia durar décadas, séculos ou talvez milênios. Tudo poderia continuar funcionando extraordinariamente bem. A medicina continuaria avançando. Novos materiais continuariam sendo descobertos. Software continuaria sendo produzido. Pontes continuariam sendo projetadas. Fábricas continuariam funcionando.

As próprias inteligências artificiais poderiam manter, reparar e melhorar a infraestrutura da qual dependemos. O problema permaneceria invisível justamente porque tudo estaria funcionando.

Mas existe uma diferença profunda entre uma civilização que sabe utilizar aquilo que possui e uma civilização capaz de reconstruir aquilo que possui.

Uma objeção óbvia seria: não bastaria preservar todo o nosso conhecimento? Podemos preservar livros, artigos científicos, código-fonte, modelos, projetos de engenharia, bases de dados e documentação. Ainda assim, podemos perder a capacidade de transformar esse material novamente em tecnologia funcional. Um manual pode explicar como utilizar uma máquina.

Mas quem fabrica a máquina? Outro documento explica. Para construí-la, porém, são necessários determinados componentes. Como fabricamos esses componentes? Precisamos de outra indústria, outras ferramentas e outros conhecimentos.

E mesmo essa cadeia de documentos não capturaria tudo. Parte importante da competência humana é tácita: reconhecer uma falha incomum, desconfiar de um resultado aparentemente correto, saber qual aproximação tentar ou como improvisar quando uma ferramenta não está disponível. Preservar a descrição de uma atividade não é necessariamente preservar a capacidade de realizá-la.

Essas ferramentas, por sua vez, dependem de outras ferramentas. Quando seguimos essa cadeia suficientemente longe, percebemos que uma tecnologia não é apenas um conjunto de instruções: ela é o resultado de uma cadeia de capacidades anteriores. A inteligência artificial pode permitir que continuemos construindo novas camadas mesmo depois que alguns dos caminhos humanos para as camadas inferiores tenham desaparecido.

É por isso que guardar informação talvez não seja suficiente. Uma biblioteca gigantesca não é necessariamente um backup de uma civilização. Um backup só é realmente útil quando sabemos restaurá-lo. Talvez precisemos, portanto, pensar em algo equivalente a uma Pedra de Roseta para uma sociedade cada vez mais dependente de inteligência artificial.

Não uma única pedra, evidentemente. Nem apenas um arquivo contendo tudo o que sabemos. Precisaríamos preservar caminhos. Do conceito abstrato à implementação. Da implementação às ferramentas necessárias para produzi-la. Das ferramentas aos conhecimentos necessários para construí-las. Dos conhecimentos aos métodos pelos quais novos seres humanos possam aprendê-los. Uma espécie de caminho de reconstrução que atravesse nossas camadas de abstração no sentido contrário.

Talvez isso envolva documentação especialmente construída para seres humanos, sistemas simplificados de referência, currículos, oficinas, equipamentos preservados e comunidades que continuem praticando determinadas capacidades mesmo quando já não sejam economicamente necessárias.

Ainda não sabemos exatamente como essa estrutura deveria ser. Mas talvez essa seja justamente a pergunta que deveríamos começar a fazer. A Pedra de Roseta não preservou apenas símbolos. Ela preservou uma ponte entre algo que havíamos deixado de compreender e algo que ainda compreendíamos.

Se continuarmos construindo abstrações sobre abstrações, talvez precisemos garantir que alguma ponte semelhante continue existindo entre nós e as camadas mais profundas da nossa própria civilização. Porque pode chegar um momento em que todos os nossos hieróglifos ainda estejam perfeitamente preservados. E o verdadeiro problema seja não haver mais ninguém capaz de lê-los.

Referências e leituras adicionais

1. British Museum — Egyptian hieroglyphs: decipherment timeline
2. U.S. Navy — Charting a New Course: Celestial Navigation Returns to USNA
3. Avigail Ferdman — AI deskilling is a structural problem
4. Lee et al. — The Impact of Generative AI on Critical Thinking — Microsoft Research / CHI 2025
5. Cash et al. — Is AI making us stupid? — PubMed
6. Collins & Evans — Tacit Knowledge, Replication, Expertise, and Democracy — Oxford Academic
7. Technology-Driven Skill Degradation and Organizational Resilience in the Era of Automation and AI

Introdução#

O dual write problem aparece toda vez que uma aplicação precisa fazer duas escritas em sistemas diferentes — normalmente um banco de dados e um broker de mensagens — e tratar essas duas operações como se fossem uma coisa só. Se eu salvo o pedido no banco e, na sequência, publico um evento no Azure Service Bus como uma chamada separada, eu criei uma janela de inconsistência. Se a aplicação falhar ou a rede cair entre essas duas operações, o sistema termina em um estado que ninguém planejou: o dado existe mas o evento nunca saiu, ou o evento foi publicado mas o commit no banco nunca aconteceu.

Esse problema não é teórico. Eu já vi filas de eventos que anunciavam pedidos que na verdade não existiam no banco, porque a transação local falhou depois da publicação. E vi o oposto: pedidos criados sem nenhum evento de auditoria ou notificação, porque a aplicação caiu no meio do caminho antes de conseguir publicar. Este artigo é a segunda parte da série sobre arquitetura de eventos sem caos com C#, e aqui eu foco especificamente no Transactional Outbox Pattern: o que ele resolve, como implementá-lo em C# com PostgreSQL, e como isso se aplica a um caso real de auditoria transacional publicando no Azure Service Bus.

Pré-requisitos#

Para acompanhar os exemplos, é útil ter conhecimento básico de transações ACID em banco relacional, Entity Framework Core ou Npgsql, e alguma familiaridade com filas ou tópicos de mensageria (Azure Service Bus, RabbitMQ ou Kafka seguem o mesmo raciocínio). O exemplo de código completo faz parte do mesmo laboratório de eventos usado no primeiro artigo da série, disponível em BlogSamples/Messaging/EventDriven/.

O problema da dupla escrita (dual write problem)#

Toda vez que uma operação de negócio precisa persistir um estado local e notificar esse estado para outro sistema, existem duas escritas fisicamente separadas: um COMMIT no banco de dados e uma chamada de rede para o broker. Bancos de dados relacionais garantem atomicidade dentro de suas próprias transações, mas essa garantia não se estende a um sistema externo. Não existe uma transação distribuída de verdade entre PostgreSQL e Azure Service Bus sem um protocolo como two-phase commit, que na prática quase nenhuma mensageria moderna suporta e que introduz latência e acoplamento que a maioria dos times não quer pagar.

O resultado é que qualquer combinação “salvar e depois publicar” ou “publicar e depois salvar” tem uma janela onde uma das duas operações pode falhar sozinha:

• Se eu salvo no banco e a aplicação cai antes de publicar, o evento nunca existiu e nenhum consumidor será notificado.
• Se eu publico primeiro e o commit no banco falha depois, o consumidor recebe um evento sobre um dado que nunca foi persistido.

⚠️ Atenção: um retry ingênuo não resolve o dual write problem sozinho. Se eu simplesmente tentar de novo depois de uma falha, corro o risco de publicar o mesmo evento duas vezes ou de nunca reconciliar o estado quando a falha for definitiva (aplicação reiniciada, processo morto, deploy no meio do fluxo).

Por que transações de banco não resolvem sozinhas#

A tentativa mais comum de correção é envolver as duas operações em uma transação e torcer para que tudo funcione. Isso não funciona porque a transação do banco de dados só controla recursos que o próprio banco gerencia. Uma chamada HTTP ou AMQP para o Azure Service Bus não participa do protocolo de commit do PostgreSQL ou do SQL Server. Se eu fizer INSERT no banco, chamar o SDK do Service Bus dentro do mesmo bloco try, e depois dar COMMIT, ainda existem cenários de falha:

• O COMMIT local pode ser bem-sucedido, mas a resposta de confirmação do broker nunca chega por timeout de rede — a aplicação não sabe se a mensagem foi ou não entregue.
• O broker pode confirmar a entrega, mas o COMMIT subsequente no banco falha por deadlock ou violação de constraint — o evento já foi publicado, mas o dado nunca ficou consistente.
  Esse é exatamente o motivo pelo qual eu preciso transformar as duas operações em uma única transação local, e tratar a publicação de fato como uma etapa assíncrona e desacoplada.

A solução: Transactional Outbox Pattern#

O Transactional Outbox Pattern resolve o dual write problem eliminando a necessidade de uma transação distribuída. Em vez de publicar diretamente no broker, a aplicação grava o dado de negócio e o evento pretendido em uma tabela de “caixa de saída” (outbox) dentro da mesma transação atômica do banco de dados. Como as duas gravações acontecem no mesmo banco e na mesma transação local, elas são atômicas por definição: ou as duas são persistidas, ou nenhuma é.

// Ambos os inserts fazem parte da mesma transação local no PostgreSQLawait using var transaction = await dbContext.Database.BeginTransactionAsync();var pedido = new Pedido { Id = Guid.NewGuid(), Status = "Criado" };dbContext.Pedidos.Add(pedido);// O evento pretendido é gravado como um registro comum na mesma tabela/transaçãodbContext.OutboxMessages.Add(new OutboxMessage{    Id = Guid.NewGuid(),    TipoEvento = "PedidoCriado",    Payload = JsonSerializer.Serialize(pedido),    CriadoEm = DateTimeOffset.UtcNow,    Status = OutboxStatus.Pendente});await dbContext.SaveChangesAsync();await transaction.CommitAsync();

📂 Código Fonte: O exemplo completo de Outbox, Inbox e Saga está disponível no repositório de exemplos do blog: BlogSamples/Messaging/EventDriven/

Se o CommitAsync for bem-sucedido, eu tenho a garantia de que o pedido e a intenção de publicar o evento existem juntos no banco. Se ele falhar, nenhum dos dois foi persistido. Não existe mais o cenário em que um foi salvo e o outro não.

Consumo dos eventos: o publisher assíncrono#

Salvar o evento na tabela outbox resolve a atomicidade, mas ainda falta o passo que efetivamente entrega a mensagem ao broker. Essa responsabilidade fica com um processo separado — geralmente um worker ou BackgroundService — que lê os registros pendentes da outbox e os publica no Azure Service Bus de forma assíncrona, marcando cada mensagem como publicada somente depois da confirmação do broker.

// Worker que publica mensagens pendentes da outbox, uma de cada vezpublic sealed class OutboxPublisherWorker : BackgroundService{    private readonly IServiceScopeFactory _scopeFactory;    private readonly ServiceBusSender _sender;    protected override async Task ExecuteAsync(CancellationToken stoppingToken)    {        while (!stoppingToken.IsCancellationRequested)        {            using var scope = _scopeFactory.CreateScope();            var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();            // SKIP LOCKED evita que múltiplas instâncias do worker peguem a mesma linha            var pendentes = await db.OutboxMessages                .Where(m => m.Status == OutboxStatus.Pendente)                .OrderBy(m => m.CriadoEm)                .Take(20)                .ToListAsync(stoppingToken);            foreach (var mensagem in pendentes)            {                var envelope = new ServiceBusMessage(mensagem.Payload)                {                    MessageId = mensagem.Id.ToString(),                    SessionId = mensagem.CorrelationId                };                await _sender.SendMessageAsync(envelope, stoppingToken);                // Só marca como publicada depois da confirmação do broker                mensagem.Status = OutboxStatus.Publicada;            }            await db.SaveChangesAsync(stoppingToken);            await Task.Delay(TimeSpan.FromSeconds(2), stoppingToken);        }    }}

Esse desenho cria uma janela de latência entre o COMMIT local e a publicação real — normalmente de milissegundos a poucos segundos —, mas nunca perde a garantia de atomicidade entre dado e evento. Se o worker cair depois do SendMessageAsync e antes do SaveChangesAsync, a mensagem pode ser publicada novamente na próxima execução. Isso é esperado e é resolvido do lado do consumidor, não do publisher.

Caso real: auditoria transacional em um sistema de gestão de estoque#

Um exemplo concreto desse padrão em produção é a outbox de auditoria de um sistema de gestão de estoque, que publica eventos no Azure Service Bus com semântica at-least-once. O publisher reivindica mensagens disponíveis por lease SQL — um mecanismo equivalente ao SKIP LOCKED do exemplo anterior, mas implementado como um lock otimista com timeout de lease —, envia o envelope versionado para o tópico configurado e só marca a mensagem como Published depois da confirmação do broker.

Esse fluxo reforça um ponto central do Transactional Outbox Pattern: a responsabilidade do publisher termina na confirmação de entrega. Ele nunca assume que uma mensagem enviada uma vez está garantida a chegar exatamente uma vez do outro lado. Por isso, as obrigações relevantes migram para o consumidor.

Obrigações do consumidor: idempotência e ordenação#

Como a entrega é at-least-once, todo consumidor de uma outbox transacional precisa tratar duplicidade como parte normal do fluxo, não como exceção:

• Idempotência por MessageId. O consumidor deve manter uma Inbox ou uma constraint equivalente por (consumer, messageId) antes de aplicar qualquer efeito colateral. Se a mesma mensagem chegar duas vezes, o segundo processamento precisa ser reconhecido e descartado sem repetir a ação de negócio.
• PeekLock sem auto-complete. Processar em modo PeekLock com AutoCompleteMessages desabilitado é obrigatório. A mensagem só deve ser completada depois que a persistência local ou o efeito externo estiver confirmado — nunca antes.
• Duplicatas são esperadas, não um bug. Se a API publicar no Service Bus e falhar antes de marcar a mensagem como Published, a mesma mensagem pode ser reenviada com o mesmo MessageId. O consumidor precisa estar preparado para isso desde o design inicial.
• SessionId para ordenação por agregado. Quando a subscription exigir processamento sequencial, usar SessionId como chave de ordenação por agregado — no formato Domain:EntityType:EntityId — garante que eventos do mesmo pedido, por exemplo, sejam processados na ordem correta sem bloquear outros agregados.
• DLQ apenas após esgotar tentativas. Enviar para Dead Letter Queue somente depois de esgotar as tentativas do consumidor, registrando o erro de forma sanitizada, sem payload sensível em log.
• Retries desacoplados entre outbox e consumidor. A outbox controla a publicação; o consumidor controla o próprio processamento. Misturar essas duas políticas de retry cria acoplamento desnecessário e dificulta o diagnóstico de qual lado está falhando.

// Consumidor idempotente com Inbox e PeekLockpublic async Task ProcessarMensagemAsync(ProcessMessageEventArgs args){    var messageId = args.Message.MessageId;    // Verifica se essa combinação (consumer, messageId) já foi processada    var jaProcessada = await _db.InboxMessages        .AnyAsync(m => m.Consumer == ConsumerName && m.MessageId == messageId);    if (jaProcessada)    {        // Duplicata esperada: reconhece e sai sem repetir efeito colateral        await args.CompleteMessageAsync(args.Message);        return;    }    // Aplica o efeito de negócio e registra o inbox na mesma transação    await using var transaction = await _db.Database.BeginTransactionAsync();    await AplicarEfeitoDeNegocioAsync(args.Message);    _db.InboxMessages.Add(new InboxMessage { Consumer = ConsumerName, MessageId = messageId });    await _db.SaveChangesAsync();    await transaction.CommitAsync();    await args.CompleteMessageAsync(args.Message);}

ℹ️ Informação: o par Outbox (produtor) + Inbox (consumidor) é o que efetivamente entrega consistência ponta a ponta. A outbox garante que o evento não se perde; a inbox garante que o efeito colateral não se repete.

Como saber se você precisa do Outbox Pattern#

O Transactional Outbox Pattern resolve um problema específico: consistência entre uma escrita local e uma notificação externa. Ele não é necessário em todo lugar.

Dicas e Boas Práticas#

• Grave o dado de negócio e o registro da outbox sempre na mesma transação local — nunca em chamadas separadas, mesmo que pareçam próximas no tempo.
• Marque a mensagem como publicada somente depois da confirmação do broker, nunca antes ou de forma otimista.
• Use MessageId estável (geralmente o ID do próprio registro da outbox) para permitir deduplicação no consumidor.
• Trate duplicidade de mensagens como comportamento esperado do sistema, não como bug a ser eliminado.
• Separe a política de retry do publisher da política de retry do consumidor; cada um tem falhas e responsabilidades diferentes.
• Use SKIP LOCKED ou lease otimista no publisher para permitir múltiplas instâncias do worker sem duplicar trabalho.
• Nunca coloque payload sensível em logs de erro ou de DLQ; sanitize antes de registrar.

Resumo Objetivo#

• Dual write problem — ocorre quando uma aplicação grava em banco e publica em broker como duas operações separadas, sem garantia de atomicidade entre elas.
• Transactional Outbox Pattern — grava o dado de negócio e o evento pretendido na mesma transação local, eliminando a inconsistência entre as duas escritas.
• Semântica at-least-once — o publisher garante que a mensagem não se perde, mas pode ser entregue mais de uma vez ao consumidor.
• MessageId — chave usada pelo consumidor para deduplicação via padrão Inbox, com constraint por (consumer, messageId).
• PeekLock sem auto-complete — modo de processamento que só confirma a mensagem depois do efeito colateral estar persistido.
• SessionId — chave de ordenação por agregado (Domain:EntityType:EntityId) usada quando a subscription exige processamento sequencial.
• Azure Service Bus — broker usado no caso real do sistema de gestão de estoque para publicar eventos de auditoria a partir da outbox transacional.

Leia Também#

• Arquitetura de Eventos sem Caos com C#: Guia Prático
• Worker e BackgroundService: Alto Volume
• Gargalo em Banco de Dados: Mensageria e Paginação
• Padrões GoF: Código à Nuvem, Monólito ao Microserviço

Referências#

• Transactional Outbox Pattern — microservices.io — descrição canônica do padrão e do problema de dual write.
• Azure Service Bus messaging documentation — documentação oficial de tópicos, subscriptions e sessões.
• Azure Service Bus PeekLock e AutoComplete — comportamento de locks e confirmação de mensagens.
• PostgreSQL SKIP LOCKED — locking otimista para publishers concorrentes.
• Entity Framework Core Transactions — documentação oficial de transações no EF Core.
  📬

📖 Artigo completo com exemplos de código: Transactional Outbox Pattern: Resolvendo o Dual Write

Publiquei este mesmo texto no Reddit e estou republicando aqui porque o TabNews tem uma comunidade diferente, que pode ter outra visão sobre a questão. Achei interessante ouvir também a opinião de vocês.

Saudações, pessoal.

Queria pedir a opinião de vocês sobre uma dificuldade que estou tendo recentemente. Tenho um Substack que comecei como hobby, sem visar dinheiro, likes ou a construção de uma grande audiência. Ao longo do tempo, fui acumulando ideias que queria colocar para fora e, como estava me sentindo meio ignorado no dia a dia, comecei a escrever. Gosto de escrever e, eventualmente, já publiquei cerca de 50 artigos, alguns mais técnicos, outros mais pessoais, passando por tecnologia, arquitetura, IA, estratégia, negócios e outros assuntos que acabam aparecendo pelo caminho.

Durante bastante tempo, não me preocupei com alcance. Mas, depois de uns 50 artigos, comecei a sentir falta de uma coisa que não estava encontrando: feedback. Não necessariamente mais visualizações, mas pessoas para discutir as ideias, concordar, discordar, questionar ou simplesmente acrescentar alguma coisa.

Comecei então a experimentar algumas formas de distribuição. Coloquei os artigos no GitHub e comecei a fazer alguns experimentos por lá, inclusive traduções automatizadas para diferentes idiomas e até uma "locale" específica para sistemas agentivos. Também comecei a importar os artigos para o Medium e estou procurando outras formas de distribuição. Ainda é tudo muito recente e não tenho dados suficientes para saber se essas iniciativas estão funcionando.

Por isso, perguntei para a própria comunidade do Substack como outras pessoas trabalham descoberta e alcance. Recebi algumas sugestões interessantes, mas uma das respostas me fez pensar em uma questão diferente. A pessoa comentou que existe hoje uma resistência grande a textos produzidos com auxílio de IA e que algumas pessoas simplesmente deixam de ler quando percebem isso.

No meu caso, uso IA para estruturar, expandir e revisar os artigos, mas as experiências, ideias e argumentos são meus. Alguns artigos partem de situações que vivi ou problemas que encontrei; outros são simplesmente ideias que fiquei desenvolvendo e resolvi escrever. Não tenho intenção de esconder o uso de IA. Isso me fez pensar que talvez eu esteja procurando minha audiência no lugar errado.

Uma coisa que talvez seja importante esclarecer é que não estou particularmente interessado na parte de newsletter do Substack. Ela acabou sendo um bônus da plataforma e, na verdade, às vezes até me incomoda. Já aconteceu de eu perceber um erro depois que o artigo já tinha sido enviado por email, o que seria especialmente desagradável se eu tivesse uma lista grande de assinantes. O que me interessa mesmo é ter um lugar onde os artigos possam ser publicados e discutidos.

Também não sei se o Reddit é necessariamente o melhor formato para o que escrevo. Meus artigos normalmente têm uma estrutura mais fechada, com introdução, desenvolvimento e conclusão, em vez de serem textos pensados para iniciar uma discussão. Talvez isso funcione bem aqui, talvez não. Não tenho experiência suficiente com a plataforma para saber.

Então a pergunta é: qual é o lugar certo para publicar esse tipo de conteúdo? Reddit, LinkedIn, Medium, alguma comunidade específica ou outro lugar que eu não esteja considerando?

Não estou procurando necessariamente uma plataforma com mais alcance. Estou tentando encontrar uma comunidade onde exista interesse em discutir os artigos, sejam eles técnicos ou mais pessoais, em vez de simplesmente publicar e ficar falando sozinho.

Como não posso divulgar os links para que vocês consigam visualizar o contexto das minhas postagens, deixo abaixo a relação de títulos e subtítulos dos artigos que escrevi.

Se vocês tiverem alguma sugestão de comunidade, plataforma ou mesmo de público que tenha afinidade com esse tipo de conteúdo, gostaria bastante de ouvir.

Obrigado desde já pela atenção.

01 - "Conselhos que eu daria para o meu eu de 20 anos atrás" - Se eu pudesse falar com a versão mais jovem de mim, que mensagem eu lhe transmitiria?
02 - "Por que eu ainda acredito no Bitcoin, apesar de um 2026 tão difícil" - Existe uma diferença fundamental entre estar decepcionado com o desempenho de um investimento e deixar de acreditar na tese que levou você a investir nele
03 - "Qual o verdadeiro potencial da IA?" - A grande transformação da IA talvez não esteja em substituir aquilo que já fazemos, mas em introduzir uma nova camada de decisão dentro dos sistemas e processos que construímos.
04 - "E se o metaverso tiver feito a pergunta certa, mas procurado a resposta na direção errada?" - Uma especulação sobre realidade aumentada, HUDs, agentes contextuais e o futuro das interfaces computacionais
05 - "Quando a métrica vira o objetivo" - Por que as redes sociais apodrecem e o que isso revela sobre nossa obsessão por otimizar tudo
06 - "Mecânicas inovadoras e sua importância para a indústria dos jogos" - Talvez o futuro dos videogames não esteja em mundos maiores, mas em novas formas de interagir com eles
07 - "Empresas não são clubes de futebol, mas talvez seja útil pensar nelas dessa forma" - Em um país que respira futebol, talvez olhar para as empresas como clubes nos ajude a enxergar cultura, estratégia, talento, treinamento e gestão por outro ângulo.
08 - "Por que sistemas legados raramente morrem?" - Sistemas legados não carregam apenas código antigo. Eles carregam décadas de conhecimento que talvez as empresas já não sejam capazes de reconstruir.
09 - "Gestão é a arte de ser otimista e pessimista ao mesmo tempo" - A arte de pensar no melhor e se preparar para o pior simultaneamente.
10 - "Games não precisam de uma Netflix, precisam de uma AWS" - E se o erro fundamental dos serviços de jogos por assinatura for tratar o catálogo de jogos como produto, quando o verdadeiro produto que o usuário quer alugar é capacidade computacional?
11 - "O papel do arquiteto de soluções no mundo corporativo" - Um bom arquiteto de soluções é como um primeiro-volante: não é necessariamente quem aparece mais, mas é quem mantém o time funcionando.
12 - "E se cada gestor público tivesse assessores de IA?" - Uma proposta de experimento sobre o uso de inteligência artificial no apoio à participação, análise e formulação de políticas públicas.
13 - "E se criarmos uma infraestrutura distribuída para o terceiro setor?" - Existem informações cujo valor social aumenta com a sua circulação, e não com a sua exclusividade.
14 - "Entendendo as cadeiras de Tecnologia" - Os cargos de tecnologia não se distinguem pelo quanto de tecnologia cada profissional conhece, mas pelo tipo de decisão que precisa tomar e pelo nível de responsabilidade sobre os resultados.
15 - "Cloud Computing: escolhendo além do default" - Um mapa das principais clouds, seus pontos fortes, equivalências e os trade-offs entre simplicidade, portabilidade, custo e resiliência.
16 - "Por que eu abriria hoje uma startup com mais de uma atividade principal" - Diversificar negócios pode ser uma estratégia de inovação, e não apenas uma forma de reduzir riscos.
17 - "O que o Vasco pode nos ensinar sobre gestão" - Cultura, liderança e os riscos de construir organizações que dependem mais de pessoas do que de instituições
18 - "A Engenharia da Comunicação Organizacional" - Como controlar o fluxo de informação, reduzir assimetrias de conhecimento e aproximar decisões da realidade operacional
19 - "O Mundo é Maior que a História" - O que Harry Potter, Tolkien, Star Wars e os RPGs ensinam sobre a expansão de universos ficcionais
20 - "Será que a IA pode tornar o waterfall ágil?" - Se a IA torna o código mais barato de produzir, ela também pode reduzir o custo que historicamente separa waterfall de Agile?
21 - "Risco é uma responsabilidade organizacional" - Por que risco não é responsabilidade de uma área, mas uma dimensão de toda decisão organizacional
22 - "Quando a venda se concretiza, o relacionamento apenas começa" - Por que entender aquilo que se vende, alinhar expectativas e acompanhar o cliente depois do fechamento é tão importante quanto fechar o negócio.
23 - "Boas ideias também quebram" - Como estratégia, execução e o ciclo do dinheiro determinam a sustentabilidade das empresas
24 - "O bom profissional de TI é como um mago-alquimista" - Trabalhar com tecnologia exige saber aplicar o que já foi consolidado, reutilizar experiências e produzir conhecimento novo.
25 - "O dilema de Security: entre o controle e a velocidade" - O desafio de integrar Security à engenharia sem transformar proteção em burocracia.
26 - "Às vezes, a melhor decisão de UX é não fazer UX neste momento" - O investimento em experiência do usuário deve ser proporcional à maturidade do produto, às incertezas do negócio e aos riscos envolvidos em cada decisão.
27 - "Suporte humano como mecanismo de evolução da automação" - Como combinar inteligência artificial, atendimento humanizado e feedback para construir um suporte mais eficiente, escalável e capaz de aprender com seus próprios clientes.
28 - "Quanto da inteligência humana precisamos reproduzir?" - Uma reflexão de um arquiteto de soluções sobre complexidade, abstração e inteligência artificial geral.
29 - "PostgreSQL realmente é o Skyrim dos bancos de dados" - Um produto completo por si só, mas com uma comunidade capaz de transformá-lo em algo que seus próprios criadores talvez jamais conseguissem construir sozinhos.
30 - "Qual o mercado mais adequado para a minha empresa?" - Um panorama dos mercados, ecossistemas e condições para empreender no Brasil e no exterior.
31 - "Pessoas, incentivos e cultura como mecanismos de execução da estratégia" - Como partnership, People e cultura transformam estratégia em comportamento.
32 - "O que Senna e Churchill podem nos ensinar sobre resiliência" - Resiliência não é nunca desistir, mas adaptar-se à adversidade sem perder de vista o que importa.
33 - "E se usarmos uma arquitetura modular distribuída no lugar do monólito modular?" - Uma ideia de arquitetura para startups em estágio inicial que precisam crescer sem pagar desproporcionalmente por infraestrutura ou pela complexidade dos microservices.
34 - "PMBOK não é receita de bolo: o papel do tailoring na gestão de projetos" - Assim como arquitetura de software é uma resposta a requisitos e restrições, gestão também precisa ser desenhada para o contexto.
35 - "Antes de tirar uma ideia do papel, é preciso colocá-la nele" - Canvas e frameworks ajudam a pensar partes de um problema. O desafio é conectá-los em uma metodologia capaz de transformar uma ideia em uma iniciativa que possa ser compreendida e executada.
36 - "Fundamentos da arquitetura patrimonial: projetando o patrimônio como um sistema" - Uma perspectiva de arquitetura de soluções sobre requisitos, componentes, risco, segurança, redundância e resiliência patrimonial
37 - "Por que sistemas modernos estão ficando mais fáceis de construir e mais difíceis de projetar?" - Abstrações de cloud, o paradoxo da escolha e a inteligência artificial estão mudando a natureza da arquitetura de soluções mais rápido do que conseguimos nos adaptar.
38 - "DevOps ficou grande demais para uma única profissão?" - Se Security pode ser dividida em especialidades, por que DevOps ainda precisa caber em uma única profissão?
39 - "Arquitetura de soluções aplicada a mercados financeiros, governos, cadeias de suprimentos e geopolítica" - Uma perspectiva de arquitetura sobre autoridade, confiança, dependências, interfaces e falhas em sistemas complexos
40 - "E se o futuro do software empresarial não for o Micro-SaaS, mas o Business Cloud Workspace?" - Da especialização das aplicações a uma plataforma que absorva software, agentes, conhecimento e relações de negócio
41 - "O Anti-Mago: Um Projeto Literário" - Quem vigia aqueles que têm o poder de governar toda a sociedade, e o que acontece quando alguém recebe poder suficiente para julgá-los sem sofrer consequências?
42 - "Arquiteturas Investigativas: da coleta de informação à inteligência contínua" - Uma arquitetura orientada por IA para investigar perguntas de negócio, aprender com o contexto e acompanhar continuamente o que pode mudar uma decisão.
43 - "Capital Social: O ativo que existe antes da empresa" - Como relações, reputação e acesso a círculos sociais influenciam a construção e o crescimento de um negócio.
44 - "Sua ideia é boa ou você só está apaixonado por ela?" - O erro mais perigoso não é defender uma ideia ruim. É construir um sistema mental em que qualquer evidência possa ser interpretada como confirmação de uma ideia que já decidimos ser boa.
45 - "Você sabe quanto deveria cobrar ou só escolheu um número?" - Precificar é decidir quanto capturar de valor hoje, sabendo que o mercado pode mudar amanhã.
46 - "Como impedir que seu MVP vire um Leviatã" - Entre a complexidade que antecipa o futuro e a simplicidade que impede o aprendizado.
47 - "A linha tênue entre persistência e autodestruição" - Sobre decisões difíceis, feedback, limites e o momento em que persistir deixa de fazer sentido.
48 - "Eu preciso mesmo de investimento externo?" - Bootstrapping, capital externo e o custo de construir uma empresa que talvez eu não queira administrar.
49 - "Guia de Startupês" - Um guia prático sobre os principais termos do ecossistema de startups, com definições, exemplos concretos e termos relacionados, organizado por níveis de complexidade.
50 - "O que os piores tipos de decisão da história nos ensinam sobre arquitetura de decisão" - O que os erros de impérios, governos e empresas revelam sobre estratégia, gestão e tomada de decisão

English summary: A production-minded walkthrough of using TypeSafe AI's JEV through Vercel AI Gateway to triage support tickets in a FastAPI vertical slice. It covers typed Choice, Score, and Noul questions, graceful degradation, validation, evals, cost, security, rollback, and the gap between a working proof of concept and a system you can trust.

Publicado: setembro de 2026
Tempo de leitura: 18 min
Palavras-chave: JEV, TypeSafe AI, Vercel AI Gateway, FastAPI, decisões tipadas, vertical slice, Python, evals

Um ticket diz que o checkout parou, há clientes esperando e o assunto veio marcado como “dúvida”. Seu backend precisa decidir três coisas: isso é urgente, qual time assume e qual o nível de prioridade.

Pedir a um LLM para “analisar o ticket e responder em JSON” funciona na demo. Em produção, a pergunta importante vem depois: quem garante que o departamento existe, que a probabilidade está no intervalo certo e que uma indisponibilidade do modelo não impede o ticket de ser criado?

Foi esse problema que eu usei para testar o JEV, modelo da TypeSafe AI voltado a decisões estruturadas, por meio do Vercel AI Gateway. A implementação entrou em uma fatia vertical FastAPI real: router, service, repository, contrato de avaliação e testes de degradação. Foi uma POC funcional feita durante algumas horas de trabalho, não um benchmark de produção nem uma promessa de acurácia.

Minha conclusão é específica: JEV é interessante quando seu software precisa de um julgamento estreito e probabilístico, mas a aplicação deve continuar dona do contrato, da política e do fallback. Tipar a resposta reduz uma classe de erros. Não transforma uma inferência em verdade.

TL;DR

• JEV recebe um state e perguntas tipadas; devolve respostas que o código consegue consumir sem extrair texto livre.
• Os três primitivos documentados são choice, score e noul. Noul representa a probabilidade de uma resposta “sim”.
• No meu fluxo, uma chamada decide urgência, departamento e nível de urgência para um ticket.
• O Vercel AI Gateway expõe JEV como typesafe-ai/jev no endpoint /v1/evaluate.
• A cota gratuita documentada em 19 de setembro de 2026 era de US$ 5 por mês para cada time no free tier. Ela começa na primeira requisição; comprar créditos move o time para o tier pago e remove o crédito mensal. Isso é uma condição comercial mutável, não “API grátis para sempre”.
• Timeout, erro HTTP, resposta inválida ou baixa confiança precisam levar a fallback ou revisão humana, não a uma ação silenciosa.
• O exemplo mínimo abaixo ensina a integração. A seção de produção mostra o que ainda falta antes de colocar decisões no caminho crítico.

O que JEV é, e o que ele não é

A TypeSafe chama JEV de seu primeiro modelo “System One”: um modelo para decisões rápidas e estruturadas. Em vez de pedir prosa e tentar recuperar estrutura depois, você envia o estado do problema e perguntas com tipos conhecidos.

Os primitivos são:

O nome incomum noul importa porque copiar um contrato como boolean quebraria a integração. No Gateway, a página do modelo descreve capacidades como Choice, Score e Boolean; na API de avaliação e na documentação TypeSafe, o tipo usado no payload é noul. O contrato da API vence o rótulo de marketing.

JEV não é:

• uma regra de negócio;
• um mecanismo de autorização;
• uma garantia de calibração no seu domínio;
• um substituto automático para validação semântica;
• a melhor escolha quando um if, regex, enum ou consulta ao banco resolve o caso de forma determinística.

Use código comum para fatos. Considere um modelo de decisão quando o input é ambíguo e a saída possível já é conhecida.

Rode o núcleo em poucos minutos

Este é um exemplo didático, adaptado da minha implementação. Requer Python 3.11+, httpx e uma chave do Vercel AI Gateway.

python -m venv .venvsource .venv/bin/activatepip install "httpx>=0.27,<1"export AI_GATEWAY_API_KEY="sua-chave"

Crie jev_demo.py:

import osfrom typing import Anyimport httpxGATEWAY_URL = "https://ai-gateway.vercel.sh"MODEL = "typesafe-ai/jev"QUESTIONS = {    "is_urgent": {        "type": "noul",        "instructions": "Does this ticket require immediate attention?",    },    "department": {        "type": "choice",        "instructions": "Which team should handle this ticket?",        "criteria": {            "billing": "Payments, invoices, refunds, or charges",            "technical": "Bugs, outages, integrations, or product errors",            "shipping": "Delivery, tracking, or logistics",            "general": "Anything outside the other departments",        },    },    "urgency": {        "type": "score",        "instructions": "How urgent is this ticket?",        "criteria": ["low", "medium", "high"],    },}def evaluate_ticket(subject: str, message: str) -> dict[str, Any]:    api_key = os.environ["AI_GATEWAY_API_KEY"]    payload = {        "model": MODEL,        "state": {"subject": subject, "message": message},        "questions": QUESTIONS,    }    with httpx.Client(timeout=10.0) as client:        response = client.post(            f"{GATEWAY_URL}/v1/evaluate",            headers={"Authorization": f"Bearer {api_key}"},            json=payload,        )        response.raise_for_status()        return response.json()["answers"]if __name__ == "__main__":    answers = evaluate_ticket(        subject="Checkout fora do ar",        message="Pagamentos falham há 20 minutos; 42 pedidos estão bloqueados.",    )    print(answers)

Execute:

python jev_demo.py

O formato exato inclui metadados definidos pelo serviço, mas o consumo relevante segue este desenho:

{  "is_urgent": {"noul": 0.97},  "department": {    "choice": "technical",    "probabilities": {      "billing": 0.01,      "technical": 0.96,      "shipping": 0.0,      "general": 0.03    }  },  "urgency": {"score": 2.8}}

Valores acima são ilustrativos, não output prometido. O ganho estrutural está em conhecer os campos possíveis antes da requisição. Seu código ainda deve validar a resposta real.

Intuição: modelo propõe, política dispõe

Pense no JEV como um sensor. Um sensor mede e carrega incerteza; ele não decide sozinho se uma esteira industrial deve parar. O controlador lê a medição, verifica limites, considera outras condições e escolhe a ação segura.

Aqui, o modelo produz julgamento:

ticket → {urgente: 0.97, departamento: technical, score: 2.8}

A aplicação produz política:

if result.is_urgent >= 0.90 and result.confidence >= 0.80:    page_on_call()elif result.is_urgent >= 0.60:    enqueue_human_review()else:    follow_normal_queue()

Os cortes pertencem ao seu domínio. Eles não devem ficar escondidos em prompt, resposta do modelo ou regra do provedor.

Minha fatia vertical em FastAPI

Na PR privada do POC FastAPI, implementei um CRUD de tickets no mesmo padrão vertical já usado pelo projeto. O link registra a origem do estudo, mas o conteúdo não é acessível sem permissão. Por isso, os trechos úteis e sanitizados estão reproduzidos aqui; nenhuma credencial ou configuração privada foi copiada.

flowchart LR    C[Cliente HTTP] --> R[Ticket Router]    R --> S[Ticket Service]    S --> J[JevClient]    J --> G[Vercel AI Gateway]    G --> M[typesafe-ai/jev]    S --> P[Ticket Repository]    P --> D[(MongoDB)]    J -. timeout ou erro .-> F[Fallback sem avaliação]    F --> P

O JevClient é um adapter fino. Ele conhece URL, autenticação, timeout e envelope HTTP. O service conhece o caso de uso e decide o que fazer quando o adapter falha.

from typing import Anyimport httpxclass JevEvaluationError(RuntimeError):    passclass JevClient:    def __init__(        self,        *,        api_key: str,        model: str = "typesafe-ai/jev",        base_url: str = "https://ai-gateway.vercel.sh",        timeout: float = 10.0,    ) -> None:        self.api_key = api_key        self.model = model        self.base_url = base_url.rstrip("/")        self.timeout = timeout    def evaluate(self, state: Any, questions: dict[str, Any]) -> dict[str, Any]:        try:            with httpx.Client(timeout=self.timeout) as client:                response = client.post(                    f"{self.base_url}/v1/evaluate",                    headers={"Authorization": f"Bearer {self.api_key}"},                    json={                        "model": self.model,                        "state": state,                        "questions": questions,                    },                )                response.raise_for_status()                body = response.json()        except (httpx.HTTPError, ValueError, KeyError) as error:            raise JevEvaluationError("evaluation unavailable") from error        answers = body.get("answers")        if not isinstance(answers, dict):            raise JevEvaluationError("invalid evaluation contract")        return answers

O fluxo do POST /tickets preserva a função principal mesmo sem IA:

sequenceDiagram    actor User as Cliente    participant API as FastAPI Router    participant Service as Ticket Service    participant Jev as JevClient    participant Gateway as Vercel AI Gateway    participant DB as Repository    User->>API: POST /tickets    API->>Service: create(subject, message)    Service->>Jev: evaluate(state, questions)    Jev->>Gateway: POST /v1/evaluate    alt resposta válida        Gateway-->>Jev: answers tipadas        Jev-->>Service: answers        Service->>DB: save(ticket + evaluation)    else timeout, HTTP error ou contrato inválido        Gateway--xJev: falha        Jev-->>Service: JevEvaluationError        Service->>DB: save(ticket + evaluation null)    end    DB-->>API: ticket persistido    API-->>User: 201 Created

Esse detalhe mudou o risco do experimento. JEV enriquece o ticket; não possui a criação. Em falha, o dado principal continua entrando no sistema e pode ser triado manualmente.

Contratos e ownership

Uma integração confiável precisa responder “quem é dono?” antes de responder “qual modelo?”.

O modelo nunca deve receber permissão implícita para executar uma ação sensível. Ele fornece evidência para uma policy que o código controla.

Do brinquedo para produção

O script mínimo ensina endpoint e payload. Ele omite pontos que importam sob carga ou incidente:

1. Validação estrutural e semântica. Verifique IDs esperados, tipo de cada resposta, opções permitidas, limites [0, 1], soma das probabilidades e faixa do score. Pydantic ajuda, mas tipos válidos não provam decisão correta.
2. Cliente reutilizável. Não abra uma conexão por request em carga alta. Injete httpx.AsyncClient com lifecycle controlado pelo FastAPI.
3. Timeout e orçamento de retry. Retry cego pode duplicar custo e piorar congestionamento. Restrinja a erros transitórios, use backoff com jitter e mantenha deadline total.
4. Idempotência. Persistência e avaliação podem terminar em ordens diferentes. Defina chave idempotente, status pending/evaluated/failed ou outbox se reprocessamento for necessário.
5. Observabilidade sem vazar dados. Registre request ID, versão do contrato, modelo, latência, status, rota tomada e custo. Não grave ticket completo, bearer token ou PII por conveniência.
6. Concorrência e escala horizontal. Estado de retry, locks e fila não podem morar na memória de uma única instância. Workers devem conseguir reprocessar por ID, com claim atômico e deduplicação.
7. Versionamento. Guarde versão da pergunta, policy e modelo junto à decisão. typesafe-ai/jev é o ID do Gateway; a TypeSafe documentava jev-latest como alias de jev-1.13.0 em 19 de setembro de 2026. Aliases facilitam upgrades, mas reduzem reprodutibilidade.

Seis falhas que aparecem depois da demo

1. O Gateway está indisponível

Timeouts, 429, 5xx e falhas de rede acontecem. Se triagem é enriquecimento, salve o ticket com evaluation: null, emita métrica e reprocese depois. Se a decisão protege uma ação irreversível, falhe fechado ou exija humano.

2. A resposta passa no JSON, mas viola o contrato

department="sales" não deve entrar se o enum só aceita quatro times. Uma probabilidade 1.2 também não. Valide antes de persistir ou agir. Resposta inválida é falha de integração, não “melhor esforço”.

3. Confiança alta, decisão errada

Confiança não substitui acurácia. Meça falsos negativos de urgência e erros por idioma, produto e tipo de cliente. Um corte global pode esconder desempenho ruim num segmento pequeno.

4. O input contém instrução maliciosa

Texto do ticket é dado não confiável. A superfície é menor do que em geração com tools, mas prompt injection ainda pode influenciar classificação. Não inclua segredos no estado; mantenha ações fora do modelo; teste entradas adversariais.

5. Custo muda sem mudança de código

Em 19 de setembro de 2026, a página de pricing do Gateway documentava US$ 5 mensais para times no free tier, enquanto superfícies do catálogo mostravam JEV como “Free” e o detalhe do modelo exibia US$ 0,04 por milhão. Essa divergência é motivo para tratar preço como snapshot, medir uso real e configurar alertas. Comprar créditos remove o crédito mensal gratuito daquele time, segundo a documentação vigente.

6. Um alias muda o comportamento

Atualização de modelo pode alterar distribuição das respostas sem quebrar schema. Rode eval antes de promover nova versão. Guarde versão efetiva quando o provedor a expuser e mantenha rollback para modelo ou policy anterior.

Adoção incremental: observe antes de automatizar

Automação não precisa nascer com permissão de agir.

Eu comecei com dependency injection. Nos testes FastAPI, get_jev_client é substituído por um fake determinístico e por outro que lança erro. Isso cobre caminho feliz e degradação sem consumir API ou depender de credencial real.

A mesma arquitetura apareceu em duas PRs públicas do meu hub de skills:

• PR #38 — decision-native routing: adicionou modos heuristic, shadow, advisory e enforce, além de um envelope tipado para decisões entre estágios. Merge em 19 de setembro de 2026.
• PR #40 — typed decision engineering: tornou o padrão independente de provedor, com schemas, validação semântica, composição determinística, roteamento por incerteza e benchmark de custo/tokens. Merge em 19 de setembro de 2026.

O ponto não é colocar JEV em todo lugar. É separar julgamento, contrato e autoridade de execução para poder trocar o provider sem redesenhar o domínio.

O mesmo padrão dentro do meu harness

Depois da POC FastAPI, levei a ideia para o harness que uso no dia a dia. O caso está documentado em duas PRs abertas, não em um exemplo inventado:

• Lemon Code PR #25 — estratégia de roteamento JEV: adiciona JEV ao Auto Dispatch, chama typesafe-ai/jev pelo Vercel AI Gateway e mantém uma réplica local determinística, Builtin One, para fallback.
• Lemon Code App PR #13 — proveniência JEV no app macOS: transporta route.jev de forma aditiva no RPC e mostra fonte, modo, provider/modelo, probabilidade, confiança e fallback na interface.

O PR do core inclui typecheck, 849 testes, 2.879 assertions, 50 testes focados e smoke live com cinco casos. O benchmark local mediu média de 0,070 ms antes e 72,177 ms depois; o smoke remoto, uma execução por caso, mediu média de 536,641 ms. São números da POC, datados de 20 de setembro de 2026, não SLO nem benchmark de produção. O smoke observou respostas tipadas e fallbacks; isso prova integração exercitada, não qualidade estatística suficiente para automatizar decisões críticas.

flowchart TD    Q[Pedido do usuário] --> R[Auto Dispatch]    R --> H{Modo JEV}    H -->|offline| B[Builtin One determinístico]    H -->|shadow| E[Avalia, não troca rota]    H -->|advisory| J[JEV via Vercel AI Gateway]    H -->|enforce| J    J --> G{Resposta válida + gates}    G -->|sim| D[Decisão candidata]    G -->|não| B    D --> P[Policy local]    P --> F[Provider/model/runtime final]    D --> T[RouteTrace + RPC]    T --> A[App macOS: proveniência visível]

Human-in-the-loop como contrato, não como botão

O paradigma muda quando a incerteza vira parte do protocolo. O modelo não recebe autoridade para “escolher o próximo agente”; ele propõe uma decisão entre candidatos que o código já conhece. A policy local aplica dois gates no modo padrão do PR: confidence >= 0.65 e probability >= 0.55. Resposta inválida, baixa confiança, timeout ou erro remoto caem para Builtin One.

type JevGate = {  mode: "shadow" | "advisory" | "enforce";  confidenceFloor: number;  probabilityFloor: number;};const defaultGate: JevGate = {  mode: "advisory",  confidenceFloor: 0.65,  probabilityFloor: 0.55,};

shadow mede sem alterar rota. advisory mostra sugestão para inspeção. enforce permite aplicar policy somente depois de evals e rollback aprovados. Cancelamento do caller aborta a avaliação sem inventar fallback; o erro remoto chega ao restante do sistema como classificação estável, não como stack trace de provider.

Essa separação preserva controle humano em três pontos: o conjunto de candidatos, os limites de confiança e a ação final. O ciclo real é JEV → sugestão → operador vê proveniência → aceita ou faz override → decisão fica auditável. A PR do App implementa visibilidade de proveniência, não um workflow completo de aprovação humana. A UI macOS recebe route.jev opcional; payloads legados continuam decodificando quando o core ainda não envia esse campo. Credencial, prompt bruto e decisão de provider permanecem no core. A interface apenas torna a proveniência auditável; o readiness router continua soberano.

O ganho não é “tirar humano do loop”. É tirar julgamento implícito do loop: quando o sistema está confiante e a policy permite, ele avança; quando não está, entrega evidência suficiente para uma pessoa revisar.

Eval: o que medir antes de confiar

Transparência: esta publicação é da equipe Weydub e foi redigida com assistência de IA. O objetivo é explicar decisões de fluxo e limitações, não apresentar um teste independente do produto.

Uma legenda gravada nos pixels do vídeo não pode ser desativada como uma faixa SRT ou VTT. Colocar uma tradução por cima costuma deixar dois textos competindo pelo mesmo espaço. Mas apagar primeiro também pode ser um erro: se a legenda original for a única transcrição disponível, é preciso preservá-la antes da limpeza.

A ordem depende do material disponível

• Projeto original com faixa editável: prefira desativar a camada de texto e exportar uma versão limpa. Isso evita reconstruir pixels que o projeto já possui.
• Vídeo final com legenda embutida e sem roteiro: extraia o texto por OCR e confira os tempos antes de remover a legenda. Guarde uma cópia do vídeo original.
• Áudio inteligível, mas sem transcrição: gere uma transcrição por reconhecimento de fala e revise-a. OCR lê texto visível; reconhecimento de fala transcreve áudio. Um não substitui automaticamente o outro.
• Fundo complexo atrás do texto: a remoção por reconstrução estima a imagem escondida. Ela não recupera necessariamente os pixels originais. Rostos, mãos, texturas e movimentos rápidos exigem revisão quadro a quadro.

Separe limpeza visual e localização do conteúdo

A limpeza deve acontecer antes da composição da nova legenda, mas não precisa vir antes da extração do texto ou da tradução. Trate o vídeo original, o vídeo limpo, a transcrição revisada e as traduções como arquivos separados. Assim, uma correção de terminologia não exige repetir a limpeza visual.

Para cada trecho, mantenha ao menos início, fim, texto original e texto traduzido. Por exemplo, se uma fala ocupa 2 segundos e a tradução contém 50 caracteres, a taxa é de 25 caracteres por segundo. Esse cálculo ajuda a identificar trechos densos; o limite aceitável depende do público, do idioma e da especificação de entrega. Não encurte automaticamente nomes, instruções ou avisos importantes só para cumprir um número.

Geração de legendas, tradução e dublagem

Depois da transcrição, revise nomes próprios, pontuação, falas sobrepostas e mudanças de locutor. Na tradução, preserve contexto e termos recorrentes. Ajuste quebras de linha e sincronização ao revisar o SRT ou VTT.

Na dublagem, o texto traduzido também precisa funcionar como fala. Compare duração, pausas e pronúncia; não presuma que a tradução adequada para leitura terá o mesmo ritmo em voz alta. Use vozes e materiais com autorização e revise a mistura com música e efeitos.

O Weydub reúne remoção de legendas incorporadas, geração de legendas, tradução e dublagem. É um produto comercial da nossa equipe. Essas etapas continuam exigindo revisão; não prometemos reconstrução perfeita nem dispensa de conferência humana.

Critérios de aprovação de uma versão

1. O texto de origem foi preservado antes de qualquer limpeza?
2. Há resíduos, borrões ou oscilações na região reconstruída durante cortes e movimento?
3. Cada legenda está dentro da duração do vídeo, com início anterior ao fim?
4. Nomes e termos mantêm a mesma tradução ao longo do material?
5. A voz está inteligível e as pausas acompanham o sentido, sem encobrir sons importantes?
6. O vídeo final foi assistido inteiro, além da inspeção de quadros isolados?

Esse fluxo complementa a etapa de detecção e máscara: localizar texto é só uma parte do trabalho. Preservar fontes, separar versões e definir critérios de revisão evita que uma correção pequena obrigue a refazer todo o vídeo.

Fala galera, blz?

Tempos atrás vi um user do X (https://x.com/bielgga) usar uma estratégia de marketing orgânico que parece dar muito certo: vídeos fake de conversas estilo direct do insta (DM). Uma pena que ele descontinuou e o MVP era muito focado no SaaS dele (o PuxeAssunto).

Bom, eu decidi criar o meu com com a ideia de divulgar meus projetos pessoais que estão "prontos" (sempre em densenvolvimento kkk).

A ideia inicial foi ter uma versão free e uma versão PRO. No caso da versão free a geração do vídeo é feita no navegador da pessoa, limitado a 720p e exportação em WEBM.

Já na versão PRO, coloquei recursos como tema (claro/escuro), cor do tema (dos balões), imagens pré-definidas do contato (busquei no Pexels), seleção dos sons do chat (tanto do recebimento quanto do envio) e no tocante a qualidade, é bem superior pois eu gero em 1080p no servidor com o Remotion.

Outro recurso que decidi colocar é o envio de imagens no chat com simulação de abertura, que ficou bem bacana também (resultado aqui: https://x.com/jonwlf/status/2101504846306083130).

Pra essa solução usei basicamente Node.js pro servidor e React pro front. Pro back foi necessário também PostgreSQL, Redis, Resend (para envio de e-mails) e AbacatePay para pagamentos via PIX. Pra geração de vídeos no back foi utilizado Remotion e FFmpeg, é o que menos custou de processamento perante outras opções, pois eu uso uma VPS da Hostinger compartilhada com meus outros projetos.

Por se tratar de um MVP ainda não comprei um domínio, então ta no meu hub de soluções: https://direct.jon.app.br

Qualquer feedback é bem vindo, vlw!

Nos últimos anos, praticamente tudo virou assinatura.

Streaming, armazenamento, ferramentas de design, inteligência artificial e, claro, software de produtividade.

Por isso, uma coisa no Office 2024 me chamou atenção: enquanto boa parte do mercado está tentando nos acostumar a pagar todos os meses, ele continua seguindo uma lógica bem mais tradicional — você compra uma versão e usa aquela versão.

Isso me fez pensar em uma pergunta que parece simples, mas não é:

em 2026, ainda faz sentido comprar uma versão do Office sem assinatura?

Na minha visão, a resposta depende muito menos de qual produto é "melhor" e muito mais de como você realmente usa o computador.

O que muda na prática?

O Office 2024 continua trazendo aplicativos que praticamente todo mundo conhece, como Word, Excel e PowerPoint.

A diferença mais importante não está exatamente nesses nomes, mas no modelo.

Segundo a própria Microsoft, o Office 2024 é uma compra única para um computador. Já o Microsoft 365 funciona como assinatura e recebe continuamente novos recursos, além de incluir serviços conectados à nuvem.

Ou seja, são propostas diferentes.

Quem gosta de sempre receber funções novas, trabalha em vários dispositivos e depende bastante de recursos online provavelmente vai enxergar mais valor no Microsoft 365.

Mas existe outro tipo de usuário.

É aquela pessoa que abre o Word para trabalhar, usa Excel para planilhas, prepara algumas apresentações no PowerPoint e simplesmente quer que essas ferramentas continuem funcionando.

Para esse perfil, pagar uma assinatura indefinidamente nem sempre parece tão interessante.

Nem todo mundo precisa de novidades todos os meses

Acho que esse é um ponto que muitas comparações acabam ignorando.

Quando falamos de software, é fácil cair na ideia de que a opção com mais recursos é automaticamente a melhor.

Mas quantos desses recursos realmente entram na nossa rotina?

Eu consigo entender perfeitamente alguém preferindo receber continuamente novidades e integrações. Para trabalho colaborativo, empresas ou quem vive dentro do ecossistema da Microsoft, isso pode fazer bastante diferença.

Por outro lado, também consigo entender quem pensa:

"Eu só quero Word, Excel e PowerPoint funcionando no meu computador."

Nesse cenário, uma licença permanente volta a fazer sentido.

Não porque seja mais moderna.

Justamente porque é mais simples.

O Office 2024 também não ficou parado no tempo

Outra impressão que eu tinha era que uma versão permanente seria praticamente uma versão antiga do Office com outro nome.

Não é exatamente assim.

A Microsoft adicionou ao Office 2024 melhorias como novas funções no Excel, melhorias de acessibilidade, recuperação de sessão no Word e mudanças visuais.

Não é o mesmo ritmo de evolução do Microsoft 365 — e nem pretende ser.

O Office 2024 funciona mais como uma fotografia daquele momento do produto: você recebe aquele conjunto de funcionalidades, atualizações de segurança e correções, mas não deve esperar receber todas as novidades que aparecerem posteriormente no Microsoft 365.

E existe uma consequência importante disso.

Quando surgir uma futura grande versão do Office, quem comprou o Office 2024 não recebe automaticamente essa nova versão.

É um detalhe que vale considerar antes de escolher apenas olhando para o preço.

Foi justamente o preço que me fez pensar nisso

Recentemente encontrei um vídeo discutindo justamente como o preço do Office 2024 está ficando curioso quando comparado com outros produtos da própria Microsoft.

Achei interessante porque ele levanta uma discussão que vai além de simplesmente "comprar barato".

A pergunta passa a ser:

quanto vale para você deixar de ter mais uma assinatura mensal?

Para quem quiser assistir, deixo o vídeo aqui: https://www.youtube.com/watch?v=o1ojh5K_-kI&t=17s

O vídeo me parece um bom complemento para quem está tentando entender onde o Office 2024 se encaixa hoje, especialmente considerando que existem tantas opções diferentes de licença e assinatura.

Eu não escolheria apenas pelo preço

Se eu estivesse decidindo entre Office 2024 e Microsoft 365, começaria olhando para a rotina, não para a tabela de preços.

Quem trabalha em vários dispositivos, precisa de armazenamento na nuvem, colaboração constante e quer sempre as funções mais recentes provavelmente vai aproveitar melhor uma assinatura.

Quem trabalha principalmente em um computador e prefere uma ferramenta mais previsível pode enxergar mais sentido no Office 2024.

Nenhuma das duas escolhas é automaticamente correta.

O erro, na minha opinião, é pagar todos os meses por benefícios que você praticamente nunca usa — ou comprar uma versão permanente esperando receber funcionalidades que fazem parte da proposta de uma assinatura.

No fim, acho interessante ainda existir essa escolha.

Em uma época em que quase todo software tenta transformar o usuário em assinante, poder simplesmente comprar uma ferramenta e continuar usando aquela versão ainda tem valor para algumas pessoas.

E vocês?

Para software que vocês usam todos os dias, preferem pagar uma vez por uma versão fixa ou manter uma assinatura para receber atualizações e novos recursos?

Comecei este projeto há quase um ano e venho trabalhando nele desde então. A ideia inicial era criar uma game engine e quem sabe um editor (essa parte fica para a próxima).

Video demo da game engine

O principal objetivo sempre foi aprender. O projeto começou a partir do curso da Udemy Game Engine Development with C++ and OpenGL, do Alex Kulbitsky, que usei como ponto de partida para entender os fundamentos de uma engine. A partir daí, fui expandindo o projeto por conta própria, criando novos sistemas, refatorando partes da arquitetura e buscando otimizar o que já existia.

• Canvas de UI e widgets como Text, Button, Image, Scroll e Dropdown
• Cascade Shadow Mapping
• Skeletal Animation
• Sistema de física com detecção e resposta a colisões
• Prefabs
• Pré-processador de shaders
• Camada de abstração gráfica com suporte a OpenGL 3.3 e OpenGL ES 3.0
• Pós-processamento, incluindo Tone Mapping, FXAA, Bloom e SSAO
• Gerenciamento de assets
• Frustum Culling
• Python Scripting
• Carregamento de modelos nos formatos OBJ e glTF, com possibilidade de utilizar o Assimp ampliando o suporte a outros formatos como FBX
• Batching e Instancing
• Suporte multiplataforma para Windows, Linux, macOS e WebGL

Também venho trabalhando no suporte para Android e iOS. A engine foi projetada de forma que a parte de "Windowing" e "Event Handling" possa ser substituída sem grandes mudanças no restante do código. Atualmente utilizo GLFW, mas a ideia é futuramente implementar essas camadas diretamente sobre as APIs nativas de cada plataforma, utilizando UIKit/UIView no iOS e Android NDK/ANativeWindow no Android, ou simplesmente utilizar SDL3.

** Aprendi até se virar com blender **

É com muita gratidão que escrevo este post. O TabNews foi um espaço muito importante para mim. Aqui pude publicar, aprender e, principalmente, contar com a leitura de vocês.

Quero agradecer de coração a cada pessoa que leu, comentou, votou, compartilhou ou simplesmente passou por aqui. Cada leitura, cada feedback, cada interação fez diferença. Mesmo quem leu em silêncio ajudou a manter a motivação.

A partir de agora, vou concentrar meus artigos apenas no LinkedIn. Não é um adeus, é uma mudança de casa. Se você quiser continuar lendo o que eu escrevo, me segue ou me adiciona por lá. Vai ser um prazer continuar essa conversa.

👉 LinkedIn: https://www.linkedin.com/in/edilson-maia-favero-a46510368/

Obrigado por tudo, TabNews. E obrigado a você que leu até aqui.

Quem gerencia mais de uma aplicação na nuvem provavelmente conhece esta rotina:

• AWS para verificar um serviço;
• Oracle Cloud para gerenciar uma VM;
• Hostinger ou Hetzner para conferir uma VPS;
• Vercel para acompanhar o deploy do frontend;
• Cloudflare para DNS e túneis;
• PuTTY, MobaXterm e ferramentas de banco para acessar os servidores.

No fim do dia, são dezenas de abas abertas, diferentes painéis, credenciais e interfaces para realizar tarefas que poderiam estar centralizadas.

Foi pensando nisso que comecei a construir o CloudOps Hub: uma plataforma para centralizar infraestrutura multi-cloud em um único painel, com um copiloto de IA integrado.

🚀 A proposta: um Single Pane of Glass para CloudOps

A ideia é permitir que desenvolvedores e equipes possam conectar, provisionar e gerenciar diferentes recursos de infraestrutura sem precisar alternar constantemente entre provedores.

1. Provisionamento de VPS/VM

Automatizar a criação de máquinas virtuais:

• Criação de instâncias em poucos cliques;
• Provisionamento automatizado na Oracle Cloud;
• Tratamento de falhas de capacidade e novas tentativas;
• Notificações sobre o resultado do provisionamento.

2. Deploy e gerenciamento de aplicações

Independentemente de a infraestrutura estar na Oracle, AWS, Hostinger ou outro provedor:

• Clonagem de repositórios GitHub;
• Deploy via Docker Compose;
• Execução de aplicações Node.js/PM2;
• Monitoramento de CPU, RAM, disco e processos;
• Arquitetura Zero-Agent, utilizando SSH para operações e coleta de informações.

3. Gestão centralizada de Storage

Um único lugar para trabalhar com diferentes storages:

• OCI Object Storage;
• S3;
• Criação e inspeção de buckets;
• Upload de assets;
• Rotinas de backup;
• Políticas de retenção para bancos de dados.

4. Multi-cloud e redução de Vendor Lock-in

Uma das ideias mais interessantes do projeto é facilitar a migração entre provedores.

Por exemplo:

Oracle → Hostinger
AWS → VPS
VPS → AWS

O Hub pode analisar os recursos utilizados, gerar infraestrutura Terraform e auxiliar na transferência dos dados e serviços.

A proposta é tornar a infraestrutura mais portável, em vez de ficar totalmente dependente de um único provedor.

5. Deploy completo: Backend + Frontend

O ciclo de deploy também fica centralizado:

Backend
• GitFlow;
• Deploy de develop → main;
• Rollback de emergência;
• Monitoramento dos serviços.

Frontend
• Integração com Vercel;
• Monitoramento de builds;
• Redeploy;
• Acompanhamento do status dos deployments.

6. Segurança com Cloudflare Zero Trust

Outra parte importante é reduzir a exposição da infraestrutura.

A ideia é evitar deixar portas como SSH ou banco de dados abertas diretamente para a internet, utilizando Cloudflare Zero Trust/Tunnels para criar caminhos de acesso controlados.

🤖 O cérebro: Odisseu AI

Para lidar com a complexidade de uma infraestrutura multi-cloud, integrei o Odisseu AI.

Ele utiliza RAG + LangChain para trabalhar com informações específicas do ambiente.

Em vez de responder apenas com conhecimento genérico, o agente pode consultar informações da infraestrutura, como:

• VMs;
• containers;
• portas;
• domínios;
• buckets;
• serviços;
• histórico de incidentes;
• métricas e telemetria.

Assim, perguntas como:

"Odisseu, qual VM está com maior pressão de memória?"

ou:

"Por que o container da API reiniciou?"

podem ser respondidas utilizando os dados reais da infraestrutura.

A ideia é evoluir isso para que o agente também consiga diagnosticar problemas, gerar os comandos necessários e, futuramente, executar determinadas ações de forma controlada.

🛠️ Stack

Frontend

• Next.js 14
• React
• Tailwind CSS

Backend

• Node.js
• Fastify
• SSH2
• OCI SDK

IA

• LangChain
• RAG
• Embeddings locais

Infraestrutura

• Docker
• Terraform
• Cloudflare Zero Trust
• Vercel

🌎 Código aberto

A base do projeto está disponível no GitHub:

https://github.com/ViniScooper/CloudOps_Hub

O objetivo também é usar o projeto como laboratório para explorar Cloud Engineering + DevOps + IA + Multi-cloud em um único produto.

Quero abrir a discussão com a comunidade:

Quantos painéis de cloud vocês precisam abrir no dia a dia para manter seus projetos funcionando?

E mais importante:

Vocês usariam uma ferramenta open source que centralizasse provisionamento, deploy, servidores, storage, monitoramento e IA em um único painel?

Quero ouvir principalmente quem trabalha diariamente com AWS, Oracle Cloud, Azure, VPS, Vercel, Cloudflare e infraestrutura própria.

Olá a todos!
Meu nome é Gustavo e tenho 19 anos, moro na Itália e tô num momento da vida em que preciso fazer dar certo de qualquer jeito. Estou completando meu ensino médio pelo Encceja exterior esse ano e meu foco total agora é migrar pra programação com foco em dev web e no uso de ferramentas de IA.

Eu já tentei fazer uns cursos tradicionais no passado (tipo Alura), mas confesso que o formato de só ver aula e não conseguir aplicar de verdade o que eu aprendi não funcionou comigo. Travei. Percebi que aprendo muito mais rápido na prática, criando projetos reais e quebrando a cabeça pra resolver problemas de verdade. Mas atualmente meu momento é bem complicado e não sei por onde recomeçar, estou implorando por ajuda porque meu sonho é poder ter a minha independência ganhar meu dinheiro com o meu trabalho e poder sair da casa dos meus pais.

Meu objetivo é construir um portfólio forte no GitHub pra compensar o fato de não ter faculdade nem experiência formal na área.

Tendo em vista o mercado de hoje, queria pedir um conselho sincero de quem já tá na área ou passou por uma situação parecida com a minha

Se vocês estivessem no meu lugar hoje, qual stack básica focariam pra construir os primeiros projetos práticos?

Como vocês usam IA no dia a dia pra acelerar o aprendizado e a escrita de código sem virar uma "muleta"?

Algum dev com mais bagagem estaria aberto a trocar uma ideia, dar umas dicas de código de vez em quando ou precisa de ajuda/aprendiz em algum projeto open source? Tô com muita vontade de colocar a mão na massa.

Qualquer dica, caminho ou puxão de orelha construtivo é super bem-vindo. muito obrigado

Uma API de preços pode responder com 200 OK e, ainda assim, entregar dados inadequados para uma decisão operacional. O preço pode estar atrasado, o volume pode usar outra moeda de referência, o ativo pode ter sido associado ao símbolo errado ou a fonte pode estar repetindo o último valor conhecido sem informar isso.

Por essa razão, um serviço confiável de dados cripto não deve ser projetado apenas para “buscar um preço”. Ele precisa responder a uma pergunta mais completa: qual é o valor, de onde veio, quando foi observado, como foi transformado e quanta confiança existe nele agora?

Este texto trata de engenharia de dados e resiliência de sistemas, não de recomendação financeira.

Comece definindo o contrato do dado

Antes de integrar provedores, defina o que cada campo significa. Um campo chamado price é ambíguo: preço da última negociação, preço médio, índice agregado ou ponto médio entre compra e venda?

O contrato interno deve especificar pelo menos:

• identificador canônico do ativo;
• moeda de cotação;
• tipo do preço;
• instante do evento no mercado;
• instante da coleta;
• fonte original;
• transformações aplicadas;
• política de expiração;
• estado de qualidade.

Essa distinção evita que consumidores interpretem como equivalentes valores produzidos por métodos diferentes.

Preserve timestamp e proveniência

Todo registro deveria carregar dois horários. observed_at representa quando a fonte observou ou produziu o dado. received_at indica quando seu sistema o recebeu. A diferença entre ambos ajuda a identificar latência, filas congestionadas e respostas antigas servidas por caches externos.

A proveniência também deve sobreviver à normalização. Guarde o nome do provedor, o endpoint ou canal utilizado e, quando possível, um identificador da resposta. Se o valor final for calculado a partir de várias fontes, registre quais participaram, quais foram descartadas e qual método de agregação foi usado.

Sem essa trilha, investigar um pico incorreto vira arqueologia: o número está no banco, mas ninguém consegue explicar como chegou lá.

Normalize sem apagar diferenças importantes

Provedores usam símbolos, precisão, pares e unidades diferentes. BTC, XBT e identificadores próprios podem representar o mesmo ativo, enquanto símbolos idênticos podem pertencer a projetos distintos. Portanto, não use apenas o ticker como chave. Mantenha um catálogo canônico baseado em identificadores estáveis e mapeamentos específicos por fonte.

A normalização deve tratar:

• moedas e unidades de cotação;
• casas decimais e regras de arredondamento;
• volumes por período;
• timezone dos timestamps;
• contratos em redes diferentes;
• valores ausentes ou representados como zero.

Zero não deve substituir ausência. Um preço realmente igual a zero, um campo não informado e uma falha de conversão são estados diferentes e precisam permanecer distinguíveis.

Detecte dados vencidos explicitamente

A validade depende do ativo e do caso de uso. Dez minutos podem ser aceitáveis em um relatório diário, mas não em uma interface que se apresenta como tempo real.

Defina um limite de frescor por categoria e calcule a idade usando observed_at, não apenas o momento da última gravação. Uma coleta recente pode conter uma observação antiga.

Estados simples facilitam o consumo:

• fresh: dentro do intervalo esperado;
• delayed: utilizável, mas acima da latência normal;
• stale: expirado para o caso de uso;
• unavailable: não há valor seguro para retornar.

Nunca renove artificialmente o timestamp de um valor em cache. Isso esconderia a idade real do dado.

Use múltiplas fontes com regras previsíveis

Fallback não significa escolher silenciosamente qualquer resposta disponível. Cada fonte pode ter cobertura, liquidez e metodologia distintas. Estabeleça uma ordem ou estratégia por ativo e documente quando a troca acontece.

Uma política possível é usar uma fonte primária enquanto ela estiver saudável, recorrer à secundária quando houver timeout ou dado vencido e comparar ambas durante a recuperação. Para ativos líquidos, uma mediana entre fontes elegíveis pode reduzir o impacto de um valor extremo. Para mercados pouco líquidos, agregar sem considerar volume e origem pode criar uma precisão ilusória.

Também é importante evitar alternância constante entre provedores. Use um período mínimo de estabilidade antes de promover novamente uma fonte que acabou de se recuperar.

Combine cache e circuit breaker

O cache reduz latência e protege contra limites de requisição, mas precisa preservar a idade do conteúdo. Uma resposta em cache deve incluir o timestamp original e seu estado atual.

Adote dois prazos: um TTL curto para operação normal e uma janela limitada de stale-if-error. Dentro da segunda janela, o sistema pode retornar o último valor conhecido, desde que o marque claramente como vencido. Depois dela, é mais seguro declarar indisponibilidade.

Um circuit breaker interrompe chamadas repetidas a um provedor que está falhando. Após um número definido de erros, o circuito abre, aguarda um intervalo e testa a recuperação com poucas requisições. Isso evita tempestades de retries e libera recursos para os fallbacks.

Retries devem ter limite, backoff exponencial e jitter. Repetir imediatamente a mesma chamada em centenas de processos costuma ampliar a falha.

Valide anomalias antes de publicar

Uma resposta tecnicamente válida pode conter um preço absurdo. Compare o novo valor com:

• a última observação confiável;
• outras fontes independentes;
• limites plausíveis de variação;
• volume e liquidez associados;
• comportamento recente do mesmo mercado.

Não descarte automaticamente toda mudança brusca: mercados cripto podem se mover rapidamente. Em vez disso, coloque a observação em quarentena, busque confirmação e reduza seu nível de confiança. Regras fixas funcionam melhor quando combinadas com referências dinâmicas, como desvio em relação à mediana recente.

Exponha qualidade junto com o preço

Consumidores não deveriam reconstruir a saúde do dado a partir de logs internos. A resposta pode incluir um estado, uma pontuação de confiança e razões legíveis por máquina.

{  "asset_id": "bitcoin",  "quote": "USD",  "price": "64231.18",  "observed_at": "2026-09-19T10:42:11Z",  "received_at": "2026-09-19T10:42:12Z",  "source": "provider_b",  "status": "delayed",  "confidence": 0.82,  "flags": ["PRIMARY_UNAVAILABLE", "FALLBACK_ACTIVE"],  "age_seconds": 46}

A pontuação não deve ser decorativa. Documente quais fatores a alteram: idade, número de fontes concordantes, liquidez, anomalias e saúde do provedor. Para decisões automáticas, prefira também estados categóricos e flags, que são mais auditáveis do que um número isolado.

Checklist operacional

Antes de colocar o serviço em produção, verifique:

• métricas de latência, erros e idade por provedor;
• alertas para aumento de dados stale;
• limites de requisição conhecidos e monitorados;
• fallback testado com falhas simuladas;
• circuit breaker e retries com parâmetros explícitos;
• logs de proveniência sem dados secretos;
• catálogo de ativos versionado;
• testes para símbolos duplicados e mudanças de contrato;
• relógios sincronizados nos serviços;
• dashboards separados para disponibilidade e qualidade;
• procedimento para invalidar valores incorretos;
• comunicação clara aos consumidores durante incidentes.

Também faça exercícios periódicos desligando a fonte primária em ambiente controlado. Resiliência que nunca foi testada costuma existir apenas no diagrama.

Conclusão

Confiabilidade não significa prometer que um preço estará sempre disponível. Significa representar honestamente a condição do dado e degradar o serviço de forma controlada. Quando timestamps, proveniência, normalização, fallback e sinais de qualidade fazem parte do contrato, aplicações conseguem distinguir um valor atual de uma estimativa atrasada — e indisponibilidade deixa de ser confundida com certeza.

Mushegh Manukyan é Founder & CEO da ARMCP.net, plataforma de informação cripto e Web3 baseada em Yerevan. Seu trabalho se concentra em dados de mercado, ferramentas blockchain, desenvolvimento de startups e clareza regulatória.

Há uma categoria de software que normalmente nasce pensando em escala: muitos usuários, contas, servidores, analytics, sincronização e monetização.

O DD • Diário Dela nasceu exatamente pelo caminho contrário.

Ele foi desenvolvido para uma única pessoa: Giovanna, minha noiva.

A ideia inicial era simples: criar algo que ajudasse no acompanhamento do ciclo menstrual e do bem-estar dela, mas sem transformar informações extremamente pessoais em dados armazenados em algum servidor de terceiros.

O resultado acabou se tornando um projeto Android bastante interessante do ponto de vista de privacidade, armazenamento local, estatística, criptografia, migração de banco de dados e engenharia de software.

Repositório: https://github.com/Miranda3000-CPU/DD-Di-rio-Dela

O problema

Aplicativos de acompanhamento menstrual lidam com informações que podem ser extremamente sensíveis.

Datas de menstruação, sintomas, intensidade do fluxo, dor, humor, sono, energia, observações pessoais e outras informações relacionadas ao ciclo não precisam necessariamente sair do dispositivo para que um aplicativo seja útil.

Por isso, uma das premissas do DD foi:

Se o dado não precisa sair do celular, ele não deveria sair do celular.

Isso levou a uma arquitetura essencialmente offline-first.

Não existe conta de usuário.

Não existe login.

Não existe servidor próprio para armazenar os registros.

Não existe painel administrativo com os dados.

Não existe publicidade.

E o aplicativo não depende de uma conexão com a Internet para funcionar.

Por que "Diário Dela"?

O nome não é apenas uma marca.

O aplicativo não foi projetado como uma plataforma genérica para múltiplas usuárias. A interface foi concebida especificamente para a Giovanna.

Isso aparece inclusive na experiência de uso:

• "Olá, Giovanna 🌷"
• "Como você está hoje?"
• "Suas previsões"
• "Seu histórico"

A intenção é que o aplicativo tenha uma experiência pessoal, e não a aparência de mais um produto genérico de saúde.

Ao mesmo tempo, isso não significa que os dados estejam codificados no aplicativo. O nome apresentado pode ser ajustado nas preferências.

Privacidade como requisito arquitetural

A privacidade não foi tratada apenas como uma frase na tela de configurações.

Ela influenciou decisões técnicas do projeto.

O AndroidManifest.xml, por exemplo, não declara a permissão android.permission.INTERNET.

Além disso, o projeto não utiliza Firebase Analytics, Google Analytics ou SDK de publicidade.

Os dados principais ficam em um banco Room local.

A estrutura inclui, entre outras informações:

• registros de ciclos;
• duração;
• datas;
• registros diários;
• intensidade do fluxo;
• dor;
• sintomas;
• humor;
• energia;
• qualidade do sono;
• muco cervical;
• observações.

Tudo isso permanece no armazenamento local do aplicativo.

E se for necessário trocar de celular?

Aqui surgiu outro problema interessante.

Se tudo fica localmente armazenado, precisamos resolver a portabilidade dos dados sem simplesmente criar uma sincronização com um servidor.

A solução foi implementar um mecanismo próprio de backup e restauração utilizando o Storage Access Framework (SAF) do Android.

O aplicativo permite exportar os dados para um arquivo .ddbackup e posteriormente importá-los.

O backup pode ser protegido com senha utilizando:

• AES-256-GCM;
• PBKDF2WithHmacSHA256;
• salt aleatório;
• autenticação integrada ao modo GCM.

A restauração também foi pensada para não simplesmente apagar o banco existente.

O mecanismo realiza um merge dos registros utilizando identificadores estáveis e datas, permitindo importar dados sem destruir o histórico já existente.

Um detalhe importante: backup automático

Outro ponto que considerei importante foi evitar que a privacidade prometida pelo aplicativo fosse contradita pelo próprio sistema operacional.

O aplicativo utiliza:

android:allowBackup="false"

Além disso, existem regras específicas de backup e extração de dados.

A ideia é evitar que dados íntimos sejam silenciosamente incluídos em mecanismos automáticos de backup do dispositivo.

A filosofia é simples:

O usuário deve saber quando está exportando os próprios dados.

Previsões sem "IA milagrosa"

Essa foi uma das partes mais importantes do projeto.

No início, seria tentador colocar no aplicativo algo como:

"Nossa inteligência artificial prevê seu ciclo com 96% de precisão."

Mas isso seria uma afirmação bastante problemática.

O ciclo menstrual possui variabilidade fisiológica e uma previsão baseada exclusivamente em histórico possui limitações importantes.

Por isso, o DD não tenta vender uma falsa precisão.

A implementação atual utiliza um modelo estatístico adaptativo e determinístico.

Entre os mecanismos utilizados estão:

• mediana dos ciclos;
• média móvel exponencialmente ponderada (EWMA);
• ponderação dos dados históricos;
• intervalos de incerteza;
• projeções para os ciclos seguintes.

A implementação utiliza EWMA com α = 0,40 e combina o resultado com a mediana histórica.

A ideia é evitar que um único ciclo atípico tenha influência desproporcional sobre a previsão.

Incerteza é uma informação

Outro detalhe importante foi abandonar a ideia de apresentar uma data futura como se fosse uma certeza.

Em vez de simplesmente:

"Sua menstruação será no dia X."

o aplicativo trabalha com janelas de incerteza.

A margem pode crescer conforme a projeção se distancia dos dados observados.

Isso é particularmente importante porque existe uma diferença entre:

previsão estatística

e

certeza fisiológica.

O aplicativo representa a primeira, não a segunda.

Projeção de 90 dias

O calendário também possui uma projeção de aproximadamente 90 dias.

Ela permite visualizar:

• ciclos futuros;
• menstruação estimada;
• janela fértil estimada;
• ovulação estimada;
• fases do ciclo.

Essas informações são visualmente diferenciadas no calendário.

Porém, existe uma distinção importante no próprio aplicativo:

Estimado não significa confirmado.

A janela fértil não confirma ovulação e não deve ser interpretada como método contraceptivo.

Um aplicativo de saúde precisa saber dizer "não sei"

Essa talvez seja uma das maiores lições técnicas do projeto.

Quando trabalhamos com informações relacionadas à saúde, existe uma tentação de transformar qualquer algoritmo em uma autoridade.

Não deveria ser assim.

Uma previsão calculada por um algoritmo a partir do histórico de uma pessoa continua sendo uma previsão.

Por isso, o DD inclui avisos explícitos de que as previsões são estimativas para acompanhamento pessoal e não substituem avaliação médica ou ginecológica.

O aplicativo também não deve ser utilizado como método contraceptivo.

Base científica

A implementação não foi construída apenas em torno de regras arbitrárias.

Entre as referências utilizadas no projeto estão trabalhos sobre variabilidade do ciclo menstrual e acompanhamento menstrual, além de referências clínicas do American College of Obstetricians and Gynecologists (ACOG).

Uma das referências utilizadas é:

Li et al. (2021) — Characterizing the normal menstrual cycle and its variations using mobile application data, publicado no Journal of the American Medical Informatics Association (JAMIA).

Também são consideradas referências do ACOG sobre o ciclo menstrual como sinal vital e trabalhos sobre variabilidade das fases do ciclo.

A intenção não é transformar o aplicativo em dispositivo médico.

É justamente o contrário: utilizar literatura científica para evitar que o software faça afirmações que os dados não sustentam.

A arquitetura Android

O projeto atualmente utiliza:

• Kotlin 2.2.10
• Jetpack Compose
• Material Design 3
• Room 2.7.0
• Kotlin Coroutines
• KSP
• Robolectric
• Roborazzi

A persistência está organizada utilizando Room.

Existe uma separação entre entidades, DAO, repositórios e camada de apresentação.

Algumas das principais estruturas são:

app/└── src/main/java/com/example/    ├── backup/    │   ├── BackupCrypto.kt    │   ├── BackupManager.kt    │   └── BackupModels.kt    │    ├── data/    │   ├── AppDatabase.kt    │   ├── CycleDao.kt    │   ├── CycleEntity.kt    │   ├── CycleRepository.kt    │   ├── DailyLogDao.kt    │   └── DailyLogEntity.kt    │    ├── model/    │   └── CyclePrediction.kt    │    ├── notification/    │   ├── CycleAlarmReceiver.kt    │   └── NotificationHelper.kt    │    ├── ui/    │   ├── CycleViewModel.kt    │   └── components/    │    └── util/        └── CycleCalculator.kt

Isso tornou possível manter a lógica de cálculo relativamente independente da interface.

Migração de banco também é parte do produto

Existe uma parte do desenvolvimento de aplicativos que muitas vezes passa despercebida quando estamos fazendo protótipos:

o usuário já possui dados.

No caso do DD isso é particularmente importante.

A Giovanna já utiliza uma versão anterior do aplicativo.

Portanto, lançar uma nova versão não poderia significar:

"Instale novamente e comece tudo de novo."

O applicationId foi mantido como:

com.aistudio.ciclo.menstrual

e o banco possui migração entre versões.

A migração MIGRATION_1_2 foi criada para preservar o histórico existente enquanto novas estruturas foram adicionadas.

Esse tipo de preocupação muda completamente a forma de pensar sobre uma atualização.

Não estamos apenas atualizando código.

Estamos atualizando um software que possui memória.

Testes

O projeto também possui uma suíte de testes para algumas das partes mais sensíveis.

Entre elas:

• cálculo do ciclo;
• janelas de incerteza;
• sinais de atenção;
• migração do Room;
• backup;
• criptografia;
• restauração;
• merge de dados;
• notificações;
• renderização visual.

Também existem testes de screenshot utilizando Roborazzi.

Isso permite comparar a interface renderizada e detectar alterações visuais inesperadas.

Notificações privadas

As notificações possuem dois modos.

No modo normal, o aplicativo pode apresentar informações relacionadas ao ciclo.

No modo privado, o conteúdo exibido na tela de bloqueio é reduzido para algo genérico, como:

"Há uma atualização sobre seu ciclo."

Isso resolve um problema simples, mas importante.

Mesmo que o aplicativo não envie dados para a Internet, uma notificação pode revelar informações pessoais para alguém que esteja olhando para a tela bloqueada.

Privacidade também envolve esse tipo de detalhe.

Interface

A interface foi construída com Jetpack Compose e possui:

• tela inicial;
• calendário visual;
• histórico;
• gráficos;
• registro diário;
• sintomas;
• humor;
• energia;
• sono;
• configurações;
• notificações;
• backup e restauração.

Algumas telas do projeto também são documentadas no próprio repositório.

O que eu aprendi construindo isso

O mais interessante no DD não foi simplesmente criar um calendário menstrual.

Foi perceber como alguns requisitos aparentemente simples mudam completamente a arquitetura.

"Não quero que os dados saiam do dispositivo."

Isso implica pensar em:

• permissões;
• dependências;
• analytics;
• backups automáticos;
• armazenamento;
• exportação;
• criptografia;
• restauração;
• migração;
• atualizações.

"Quero fazer previsões."

Isso implica pensar em:

• variabilidade;
• incerteza;
• estatística;
• dados insuficientes;
• limites do modelo;
• comunicação responsável.

"E a Giovanna já usa o aplicativo."

Isso implica pensar em:

• compatibilidade;
• applicationId;
• assinatura;
• versionamento;
• migrações;
• preservação dos dados.

No fim, um aplicativo pequeno pode envolver problemas de engenharia bastante grandes.

O estado atual

O DD • Diário Dela é atualmente um aplicativo Android pessoal, offline e privado, desenvolvido especificamente para a Giovanna.

A versão atual utiliza:

versionCode = 5versionName = "5.0"

O projeto permanece aberto no GitHub:

https://github.com/Miranda3000-CPU/DD-Di-rio-Dela

A ideia não é transformar o DD em uma plataforma de saúde para milhões de pessoas.

O objetivo original continua sendo o mesmo:

Construir uma ferramenta útil para uma pessoa específica, mantendo os dados dela sob o controle dela.

E, para mim, esse projeto acabou sendo uma forma bastante concreta de estudar uma combinação que considero interessante:

Android + privacidade + estatística + segurança + engenharia de dados + experiência pessoal.

Um prompt. Nenhum passo a passo. Um produto inteiro para construir.

Resolvi fazer um teste que, até pouco tempo atrás, pareceria absurdo:

Pedi para uma equipe de agentes de IA recriar o Tella.tv e deixei ela trabalhar.

Não fui criando página por página.

Não fiquei dizendo qual componente deveria ser implementado em seguida.

Não passei dezenas de prompts guiando cada decisão.

Dei o objetivo e deixei o Jarvis ADE assumir a execução.

O resultado foi este:

🎥 https://youtu.be/JJB9c8yQqGE

Repositório do projeto : https://github.com/Vidiio-Org/jarvis-vidiio-app

E o mais interessante não foi simplesmente ver uma IA escrevendo muito código.

Foi perceber que escrever código está começando a deixar de ser o gargalo.

O problema agora é outro:

Como fazer múltiplos agentes planejarem, dividirem e executarem um projeto inteiro sem precisar de um humano coordenando cada passo?

É exatamente isso que estamos tentando resolver com o Jarvis ADE.

A diferença entre gerar código e construir software

Hoje temos ferramentas de IA extremamente boas para programação.

Você pode pedir:

“Crie essa página.”

Depois:

“Agora implemente autenticação.”

Depois:

“Corrija esse erro.”

Depois:

“Crie os testes.”

Isso já mudou completamente a produtividade de muitos desenvolvedores.

Mas existe um detalhe:

você ainda é o gerente da IA.

**É você quem constantemente precisa decidir:
**
O que fazer
↓
Como dividir
↓
O que fazer primeiro
↓
Executar
↓
Verificar
↓
Corrigir
↓
Dar o próximo prompt

A IA programa. Mas você continua orquestrando. Foi aí que nasceu a ideia por trás do Jarvis.

E se a IA também pudesse coordenar o desenvolvimento?

Em vez de construir apenas mais um coding agent, começamos a trabalhar em algo um pouco diferente.

Um ADE — Autonomous Development Environment.

A ideia é que você não entregue necessariamente uma tarefa.

Você entrega uma missão.

Por exemplo:

“Recrie esse produto.”

O Jarvis transforma isso em um plano e coordena agentes para executar o trabalho.

                SUA MISSÃO                     │                     ▼                ┌─────────┐                │ JARVIS  │                └────┬────┘                     │                   PLANO                     │      ┌──────────────┼──────────────┐      ▼              ▼              ▼  Frontend        Backend         DevOps      │              │              │      └──────────────┼──────────────┘                     ▼                    QA                     │                     ▼                 ENTREGA

Algumas tarefas possuem dependências.

Outras podem acontecer simultaneamente.

Agentes podem trabalhar em diferentes partes do projeto enquanto o sistema acompanha o estado geral da missão.

A mudança parece pequena, mas conceitualmente é enorme.

Estamos tentando sair de:

Humano → prompt → código

para:

Humano → objetivo → equipe de agentes → software

Foi aí que resolvemos tentar recriar o Tella.tv

Precisávamos de um teste suficientemente grande para expor os problemas dessa abordagem.

Não queríamos:

“Faça uma landing page.”

Queríamos algo que obrigasse o sistema a lidar com um projeto significativamente maior.

Escolhemos o Tella.tv como referência.

Então entregamos a missão ao Jarvis.

E começamos a observar.

O Jarvis precisou lidar com coisas que vão muito além de simplesmente completar código:

planejamento → divisão de trabalho → implementação → coordenação → integração → validação → correções.

E vários agentes puderam atuar sobre partes diferentes da missão.

Tudo partindo daquela instrução inicial.

O resultado completo está no vídeo:

🎥 https://youtu.be/JJB9c8yQqGE

Observação importante: quando digo “recriamos o Tella”, estou me referindo à versão demonstrada no vídeo. Não estou afirmando paridade 1:1 com toda a infraestrutura, backend e funcionalidades internas do produto original.

E isso me fez perceber uma mudança maior

Acredito que estamos passando por três fases no desenvolvimento com IA.

1. Autocomplete
   Humano escreve código
   ↓
   IA prevê o próximo código
2. AI Coding
   Humano descreve uma tarefa
   ↓
   IA implementa
3. AI Software Engineering
   Humano define um objetivo
   ↓
   IA planeja
   ↓
   Agentes se coordenam
   ↓
   Agentes executam
   ↓
   Sistema valida
   ↓
   Software

É essa terceira etapa que considero particularmente interessante.

Porque nesse ponto gerar código deixa de ser o problema central.

Coordenação passa a ser o problema.

Contexto passa a ser o problema.

Paralelismo passa a ser o problema.

Validação passa a ser o problema.

Confiabilidade passa a ser o problema.

E esses são problemas muito parecidos com aqueles encontrados ao coordenar uma equipe de engenharia humana.

Talvez estejamos mudando a abstração da programação

Não acredito que a parte mais interessante dessa discussão seja:

“A IA vai substituir programadores?”

Existe uma pergunta tecnicamente muito mais interessante:

Qual será o nível de abstração utilizado por um programador?

Já programamos diretamente em níveis muito mais baixos.

Criamos linguagens.

Criamos frameworks.

Criamos serviços de cloud.

Cada camada permitiu que desenvolvedores expressassem uma intenção maior utilizando menos instruções.

Agentes podem representar outra mudança desse tipo.

Talvez o desenvolvedor passe cada vez mais tempo definindo:

arquitetura, requisitos, restrições, produto, critérios de qualidade e validação.

E cada vez menos tempo dizendo ao computador exatamente como implementar cada linha.

Foi assim que o Jarvis ADE nasceu

O curioso é que inicialmente o Jarvis nem deveria virar uma empresa/produto separado.

Eu estava construindo outros produtos e comecei a criar uma infraestrutura interna para coordenar agentes de desenvolvimento.

Só que ela foi crescendo.

Mais agentes.

Mais autonomia.

Mais coordenação.

Mais observabilidade.

Até chegar um momento em que percebi:

a ferramenta que estávamos construindo para criar nossos produtos estava começando a se tornar mais interessante do que alguns dos próprios produtos.

Foi daí que nasceu o:

Jarvis ADE — Autonomous Development Environment.

A ideia que estamos perseguindo é simples de explicar:

Você define a missão.
O Jarvis coordena a engenharia.

Ainda temos muitos problemas difíceis pela frente.

Contexto entre agentes, conflitos, avaliação automática, custos, execução paralela, confiabilidade, recuperação de erros e observabilidade são alguns deles.

Mas é exatamente isso que torna esse espaço tão interessante.

Estamos abrindo o projeto e mostrando esses experimentos conforme avançamos.

Quem quiser acompanhar:

Jarvis ADE

E deixo uma pergunta para quem trabalha com desenvolvimento:

Se uma equipe de agentes consegue receber um objetivo e executar horas de trabalho autonomamente, qual passa a ser o papel da IDE?

Talvez a próxima grande ferramenta para desenvolvedores nem seja uma IDE.

Talvez seja o lugar onde você gerencia quem está programando por você.

Trabalho na operação de expedição de uma indústria e não sou desenvolvedor de formação. O projeto que quero apresentar nasceu de problemas que eu vivencio no dia a dia e foi sendo construído com apoio de IA para transformar conhecimento operacional em software.

De onde surgiu a ideia

A operação trabalha com pedidos, mapas de expedição, conferência de materiais, conjuntos formados por vários componentes, embalagens, notas fiscais, faturamento e diferentes regras comerciais. Parte dessas informações fica distribuída entre processos e sistemas, o que cria espaço para conferências manuais, retrabalho e erros.
A ideia inicial era relativamente simples: importar o mapa de expedição sem alterar o sistema de origem e permitir que o operador conferisse os materiais por QR Code. Conforme o projeto evoluiu, começaram a aparecer problemas que uma conferência simples não resolvia.

O que o sistema passou a fazer

•Importar e interpretar o mapa de expedição mantendo o sistema de origem como referência.
•Conferir produtos e quantidades por QR Code.
•Controlar o que já foi conferido, faturado, entregue e o que ainda permanece pendente.
•Reconhecer conjuntos: um produto final pode depender de vários componentes e o sistema avalia se o conjunto está completo, parcial ou bloqueado.
•Registrar embalagens e manter rastreabilidade do que foi colocado em cada volume.
•Cruzar informações da nota fiscal com o que deveria ser expedido.
•Gerar informações para faturamento e packing list.
•Tratar diferentes condições comerciais e operacionais.
•Evoluir para uma camada de pré-faturamento fiscal, reunindo o contexto necessário do cliente, produto, pedido e operação para aplicar regras tributárias antes da emissão da NF-e.

Um ponto que considero importante

O sistema não nasceu de uma ideia de startup procurando um problema. Ele nasceu do problema primeiro. As funcionalidades foram surgindo conforme situações reais da operação exigiam uma solução.
Também não tenho formação tradicional em desenvolvimento de software. Meu conhecimento principal vem da operação. Usei IA como ferramenta para transformar regras, fluxos e decisões que eu conhecia do processo em uma aplicação funcional. Isso também me interessa como discussão: até onde alguém com conhecimento profundo de um problema, mas sem formação como programador, consegue construir um produto de software relevante usando IA?

O que eu gostaria que vocês avaliassem

1.Pela descrição, vocês enxergam isso apenas como uma solução interna muito específica ou existe potencial para virar um produto comercial?
2.Quais partes parecem realmente diferenciadas e quais são funcionalidades comuns que ERPs/WMS/TMS já resolvem bem?
3.Que informações vocês precisariam ver para conseguir avaliar melhor o produto?
4.Quais seriam os maiores riscos técnicos ou de arquitetura de um sistema que cresceu dessa maneira?
5.A integração entre operação de expedição, conferência, conjuntos, rastreabilidade, faturamento e contexto fiscal faz sentido como proposta de produto?
6.Se vocês estivessem avaliando esse projeto para uso em outras empresas, o que seria indispensável antes de considerá-lo comercializável?

**Sobre código e informações da empresa
**

Neste primeiro momento prefiro não publicar o código-fonte, o nome da empresa, clientes ou dados internos. Posso, porém, detalhar arquitetura, fluxos, modelo de dados e apresentar exemplos fictícios para que a análise técnica seja mais profunda sem expor informações proprietárias.
Meu objetivo com a publicação não é fazer propaganda. Quero colocar a ideia à prova com pessoas mais experientes em desenvolvimento, arquitetura e produtos de tecnologia e entender onde esse projeto realmente se encontra.

Semana de 13/09 a 19/09

Este é o seu Digest Semanal, um apanhado dos posts mais com mais TabCoins que surgiram nos últimos 7 dias.

Se você não consegue acompanhar o TabNews todo dia, esta é a sua chance de não perder o que houve de melhor esta semana!

🏆 Top 5 Destaques da Semana

RAG na Prática: Guia Completo do Conceito à Produção

Resumo: Este artigo cobre RAG (Retrieval-Augmented Generation) do zero ao avançado: o que é, como funciona cada camada do pipeline, como esc...

andersonlimadev, domingo 13/09 - 13 TabCoins

O Jev me fez repensar onde a IA deveria entrar no código

Nos últimos dois dias eu vi o Jev aparecer em praticamente todo lugar onde desenvolvedor discute IA. 20–200x mais rápido. 40–400x mais barat...

Nito, quinta 17/09 - 12 TabCoins

Fiz meu blog com IA para escrever sem IA

Criei um blog chamado Pedro {sem IA}. O site foi desenvolvido com o Codex, mas a regra para os textos é simples: não usar inteligência artif...

mksDEV08, quinta 17/09 - 11 TabCoins

Acabei com o SPAM denunciando para esses 3 endereços

Acabei com o SPAM denunciando para esses 3 endereços abuse@above.com phishing@cais.rnp.br reportphishing@apwg.org Olá, eu recebia pelo menos...

Wellington79, terça 15/09 - 11 TabCoins

Como vocês esperam que o botão "Run" funcione em um editor SQL?

No desenvolvimento do LibreDB Studio, um dos nossos contribuidores voluntários levantou uma questão interessante sobre o comportamento de mú...

cevheri, terça 15/09 - 10 TabCoins

🗞️ Top 5 do NewsletterOficial

SpaceX tentará colocar Starship em órbita pela primeira vez em 22 de setembro

O 14º voo de teste do megafoguete planeja implantar 26 satélites Starlink de terceira geração na atual rede de 10 mil satélites de internet ...

NewsletterOficial, quarta 16/09 - 5 TabCoins

Startup de co-inventor do ChatGPT lança modelo de IA que promete tomar decisões até 200 vezes mais rápido

O Jev, da TypeSafe AI, de Diogo Almeida, foi projetado para se comunicar com máquinas em vez de humanos, retornando decisões tipadas e proba...

NewsletterOficial, quarta 16/09 - 4 TabCoins

Criador do PS5 Linux abandona projeto após exploit no hypervisor do console ser reportado à Sony de maneira precipitada

Andy Nguyen pretendia reportar a falha à empresa após o lançamento do GTA VI, mas outro hacker, conhecido como Jordy, encontrou o exploit co...

NewsletterOficial, sexta 18/09 - 2 TabCoins

Senador dos EUA propõe prisão de até 20 anos para quem criar superinteligência artificial sem mecanismos de segurança adequados

O projeto de lei busca impedir o avanço descontrolado de sistemas que poderiam, por exemplo, desenvolver armas biológicas ou criar mecanismo...

NewsletterOficial, terça 15/09 - 1 TabCoins

🚀 Top Pitches

Pitch: Coeleo OS: um sistema operacional x64 feito do zero em Rust

De onde veio isso Aos 8 anos ganhei um netbook de aniversário da minha tia. Sem internet em casa, minha diversão era fuçar no Paint, nos arq...

coeleodev, terça 15/09 - 5 TabCoins

Pitch: Meu livro sobre Jujutsu (jj) e Agentes de IA foi lançado em português!

Olá, pessoal! Sou engenheira de software no Japão e também escrevo livros técnicos. Meu livro mais recente é sobre o Jujutsu (jj), um sistem...

oukayuka, terça 15/09 - 2 TabCoins

Pitch: Change Data Capture - Mini CDC

Se você só precisa reagir à mudança de em uma tabela MySQL, não deveria precisar consultar o banco a cada poucos segundos — muito menos adot...

damtaipu, sábado 19/09 - 1 TabCoins

Pitch: Manda5, um jogo de palavras multiplayer no navegador, e o que aprendi com tempo real e sala vazia

Há alguns meses construo o Manda5, um jogo de palavras para jogar em grupo pelo navegador: https://manda5.com A mecânica: aparece um tema (&...

georgequeiroga, quinta 17/09 - 1 TabCoins

Pitch: Construí um micro-SaaS para processar vídeos em lote no navegador com WebAssembly (ReelMass)

Olá pessoal! Há algum tempo venho estudando o mercado de micro-SaaS e a dor de criadores de conteúdo que trabalham com alto volume de vídeos...

KauaSilv, quinta 17/09 - 1 TabCoins

😄 Pra descontrair

xkcd.com

Deseja receber essa newsletter no seu email?

Até o próximo sábado!

— Conteúdo gerado automaticamente. Para saber mais, veja este post.

Olá, galera do TabNews!

Front-end...

Nós provavelmente somos uma das áreas que mais falam sobre performance e, ao mesmo tempo, uma das que mais normalizaram jogar abstrações, dependências e JavaScript no problema até ele desaparecer.

Falamos de Core Web Vitals.

Falamos de tree shaking.

Falamos de lazy loading, code splitting, Server Components, SSR, streaming, hydration e redução de bundle.

Aí chega segunda-feira e precisamos colocar um gráfico de sete barras em um dashboard:

npm install alguma-lib-de-graficos

E, de repente, temos dezenas ou centenas de kilobytes de JavaScript, dependências transitivas, abstrações que nunca vamos utilizar e uma API gigantesca para resolver algo que, conceitualmente, é desenhar sete retângulos.

É daí que nasce o que eu chamo de paradoxo da performance no frontend.

Nós nos preocupamos profundamente com performance — depois que construímos sistemas que precisam ser constantemente otimizados para recuperá-la.

Frontend não é "fazer telinha"

Existe ainda uma percepção curiosa de que frontend é simplesmente a camada visual do software.

Botão.

Modal.

Formulário.

Tabela.

Gráfico.

Só que o frontend moderno deixou de ser apenas apresentação há muito tempo.

Uma aplicação React pode administrar estado, cache, sincronização com servidor, autenticação, roteamento, validação, optimistic updates, internacionalização, acessibilidade, observabilidade, telemetria e uma quantidade considerável de regras de negócio.

React, Next.js, Angular, Vue, Nuxt, SvelteKit e tantos outros projetos não existem simplesmente porque desenvolvedores queriam maneiras diferentes de escrever um <button>.

Eles existem porque estamos tentando resolver um problema bastante complicado:

como construir aplicações cada vez maiores, com cada vez mais funcionalidades, por equipes cada vez maiores, sem perder completamente a capacidade de entregar software?

E acredito que isso criou uma característica importante na cultura do frontend:

ship fast, optimize later.

Não necessariamente porque os desenvolvedores são negligentes.

É consequência dos incentivos.

Uma feature entregue hoje tem valor imediatamente visível para o negócio.

Uma dependência que adicionou 80 kB ao bundle dificilmente gera uma reunião emergencial.

Uma abstração desnecessária não aparece no Jira.

Um componente que poderia ter 100 linhas mas utiliza quatro bibliotecas diferentes continua aparecendo como:

✅ Feature concluída.

A dívida aparece depois.

O frontend é cheio de patos

Existe uma metáfora que gosto bastante para pensar sobre isso.

O frontend moderno é cheio de patos.

O pato nada.

O pato anda.

O pato voa.

Ele consegue fazer praticamente tudo.

Só que dificilmente será o melhor animal em qualquer uma dessas coisas.

Boa parte das ferramentas frontend modernas funciona dessa maneira.

São ferramentas extraordinariamente generalistas.

Precisamos de renderização no servidor?

Tem.

Aplicação SPA?

Tem.

Site estático?

Tem.

API?

Tem.

Streaming?

Tem.

Middleware?

Tem.

Cache?

Tem.

Aplicação híbrida?

Também tem.

Isso é extremamente conveniente.

E conveniência é uma característica importantíssima de uma ferramenta.

O problema começa quando conveniência passa a ser confundida com eficiência.

Não escolhemos necessariamente a ferramenta que executa melhor determinada tarefa. Frequentemente escolhemos aquela que consegue resolver o maior número possível de problemas suficientemente bem.

E isso faz muito sentido economicamente.

Uma empresa não quer necessariamente cinco especialistas trabalhando com cinco tecnologias diferentes.

Ela quer contratar pessoas que consigam entregar.

Quanto maior o ecossistema, maior a quantidade de problemas que já possuem uma solução pronta:

npm install problema-resolvido

E seguimos para a próxima tarefa.

A sprint precisa terminar

Acho que existe outro fator muito mais importante que qualquer discussão técnica:

software corporativo possui prazo.

Se existe uma biblioteca que resolve meu problema em uma tarde e desenvolver uma implementação específica levaria três dias, existe uma pressão completamente racional para utilizar a biblioteca.

Multiplique isso por:

• componentes;
• formulários;
• tabelas;
• gráficos;
• datas;
• autenticação;
• analytics;
• gerenciamento de estado;
• internacionalização;
• validação;
• animações.

Individualmente, praticamente todas as decisões parecem razoáveis.

O problema é que arquitetura também é o resultado acumulado de centenas de decisões localmente razoáveis.

Nenhum desenvolvedor decidiu:

"Hoje vou adicionar 2 MB de JavaScript ao produto."

Foram 30 decisões de:

"Não vale a pena reinventar isso."

E talvez nenhuma delas estivesse errada isoladamente.

Esse é justamente o ponto.

Quando até o frontend começa a ser dividido

Talvez um dos exemplos mais interessantes dessa busca por velocidade organizacional sejam os microfrontends.

A ideia é levar parte da filosofia dos microservices para a interface: dividir uma aplicação grande em unidades menores que possam ser desenvolvidas, testadas e implantadas independentemente.

Isso permite que uma equipe altere uma parte do produto sem precisar coordenar cada release com todas as outras equipes.

Mas existe algo interessante nisso.

Criamos sistemas tão grandes que passamos a introduzir fronteiras arquiteturais dentro da própria interface para preservar autonomia de desenvolvimento.

Microfrontends podem reduzir o raio de impacto de determinadas mudanças e permitir pipelines e deploys independentes. Ao mesmo tempo, eles introduzem seus próprios custos: contratos entre aplicações, integração em runtime, possíveis dependências duplicadas e maior complexidade operacional.

Ou seja:

estamos trocando complexidade técnica por independência organizacional.

E, em empresas suficientemente grandes, essa troca pode fazer todo sentido.

Talvez esse seja um dos melhores exemplos de como arquitetura de frontend não é determinada somente por performance.

Ela também é determinada pela estrutura das equipes e pela necessidade de continuar entregando software.

Mas a web nem sempre foi construída assim

Existe uma armadilha fácil aqui: dizer que “antigamente tudo era melhor”.

Não era.

A web antiga tinha seus próprios horrores. Compatibilidade entre navegadores era um inferno, Internet Explorer exigia hacks específicos, CSS tinha limitações enormes e atualizar uma pequena parte da página frequentemente significava recarregar tudo.

Mas havia uma diferença arquitetural importante:

o navegador não era necessariamente o lugar onde a aplicação inteira precisava existir.

Durante muito tempo, boa parte da web funcionava de uma maneira quase brutalmente simples.

Você tinha PHP no servidor:

<?php foreach ($produtos as $produto): ?>    <div>        <h2><?= $produto["nome"] ?></h2>        <span>R$ <?= $produto["preco"] ?></span>    </div><?php endforeach; ?>

O servidor buscava os dados, processava a regra necessária e devolvia:

<div>    <h2>Teclado mecânico</h2>    <span>R$ 299</span></div>

E acabou.

O navegador recebia HTML.

Não existia necessariamente um runtime inteiro reconstruindo a interface.

Não existia hidratação daquela lista.

Não existia estado React representando os produtos.

Não existia uma camada de fetching no cliente para buscar novamente uma informação que o servidor já possuía.

Não existia useEffect esperando a página montar para descobrir o que deveria aparecer nela.

PHP foi provavelmente o maior representante dessa filosofia, mas não estava sozinho.

Tivemos ASP e depois ASP.NET, JSP/Servlets no ecossistema Java, Ruby on Rails, Django em Python e vários sistemas de templates server-side.

Cada ecossistema tinha seus problemas, mas compartilhavam uma ideia extremamente poderosa:

o servidor produz o documento e o navegador apresenta o documento.

JavaScript entrava principalmente quando precisávamos de comportamento adicional.

PHP era bonito?

Depende do PHP que você viu.

Quem já abriu um sistema legado com SQL, HTML, CSS e regra de negócio misturados no mesmo arquivo provavelmente está rindo agora.

Mas não estou defendendo PHP spaghetti.

Estou falando do modelo arquitetural.

Era muito difícil superar a simplicidade operacional de:

Request   ↓Servidor   ↓Banco   ↓Template   ↓HTML   ↓Browser

Compare conceitualmente com uma aplicação moderna:

Request   ↓CDN   ↓SSR / Server Component   ↓API   ↓Client Component   ↓Hydration   ↓State   ↓Cache   ↓Re-render

É claro que a segunda arquitetura consegue fazer coisas que seriam muito mais difíceis na primeira.

Esse é justamente o ponto.

Nós ganhamos capacidade em troca de complexidade.

O problema aparece quando utilizamos a segunda arquitetura para resolver problemas que ainda poderiam ser resolvidos perfeitamente pela primeira.

O curioso retorno das ideias antigas

E existe uma ironia nisso tudo.

Depois de anos levando cada vez mais responsabilidade para o cliente, o frontend começou a descobrir novamente o servidor.

SSR.

Static Site Generation.

Server Components.

Streaming HTML.

Server Actions.

Islands Architecture.

Progressive Enhancement.

Até frameworks modernos começam a perguntar:

“Será que esse JavaScript realmente precisa chegar ao navegador?”

Não estamos voltando para 2005.

As ferramentas são incomparavelmente mais poderosas.

Mas várias das ideias consideradas modernas são, em algum nível, uma redescoberta de uma propriedade antiga da web:

se algo pode ser resolvido antes de chegar ao cliente, talvez não precisemos transformar isso em trabalho para o cliente.

Talvez o PHP não estivesse tão errado assim.

Um pequeno jabá: foi assim que comecei o pure-svg-charts

Toda essa discussão começou para mim por causa de uma situação ridiculamente simples:

eu precisava colocar gráficos em React.

E temos bibliotecas excelentes para isso.

Recharts, Chart.js, Victory, ECharts, D3 e várias outras.

Só que comecei a olhar para o que realmente precisava em boa parte dos dashboards:

linha.

barra.

área.

eixo.

tooltip.

E então olhar para tudo que estava entrando no projeto para fazer isso.

Foi daí que surgiu um experimento pessoal:

até onde dá para levar uma biblioteca de gráficos React se a restrição principal for fazer menos?

Estou desenvolvendo o pure-svg-charts.

A proposta é deliberadamente limitada:

SVG nativo, zero dependências de runtime e bundle abaixo de 12 kB gzip.

Não quero substituir D3.

Não quero construir um novo ECharts.

E definitivamente não quero que daqui a três anos a biblioteca tenha 300 opções diferentes de configuração e 40 dependências.

Para não cair no clássico:

blazing fast 🚀

montei também uma suíte de benchmarks com um dataset de 5.000 pontos:

E aqui existe uma observação importante:

esse benchmark não prova que pure-svg-charts é melhor que essas bibliotecas.

Chart.js, inclusive, é mais rápido nesse cenário.

D3, ECharts, Recharts e Victory também conseguem resolver problemas que minha biblioteca simplesmente não tenta resolver.

Para mim, o resultado interessante é outro:

quanto podemos economizar quando aceitamos deliberadamente resolver um problema menor?

Às vezes, especialização também é uma otimização.

Fim do jabá.

No fim, o pato virou o desenvolvedor

E é aqui que volto para o pato.

No começo falei sobre ferramentas que parecem patos.

Nadam.

Andam.

Voam.

Fazem um pouco de tudo porque precisam funcionar em praticamente qualquer cenário.

Mas existe uma consequência interessante dessa evolução:

o próprio desenvolvedor frontend virou um pato.

Olhe para uma vaga moderna de Frontend Engineer.

Naturalmente você espera encontrar:

HTMLCSSJavaScriptTypeScriptReact

Perfeito.

Então você continua descendo.

Next.jsSSRSSGReact QueryReduxWebSocketsRESTGraphQL

Tudo bem.

Ainda estamos relativamente perto de casa.

Continua:

JestTesting LibraryCypressPlaywrightStorybookDesign SystemAccessibilitySEOCore Web Vitals

Ok.

Continua.

Node.jsDockerCI/CDGitHub ActionsAWS / Azure / GCPKubernetesObservabilityDatadogGrafanaOpenTelemetry

E, em algumas vagas:

MicroservicesKafkaRedisCDNEdge ComputingBFFOAuthOpenID ConnectTerraform

Em algum momento você olha para a descrição e pensa:

eu ainda estou concorrendo para frontend?

"Mas frontend precisa saber Kubernetes?"

Talvez.

E esse “talvez” diz bastante sobre onde chegamos.

Um frontend moderno não vive isolado.

Se você trabalha com SSR, precisa entender minimamente o servidor.

Se utiliza Next.js, precisa entender o que executa no cliente e o que executa no servidor.

Se sua aplicação está containerizada, Docker deixa de ser completamente distante.

Se existem pipelines de deploy, CI/CD começa a fazer parte da sua rotina.

Se a aplicação possui problemas em produção, observabilidade importa.

Se você precisa diagnosticar por que uma página demora quatro segundos para aparecer, talvez tenha que entender CDN, cache, HTTP, DNS, API, banco, processamento no backend e execução no browser.

Se trabalha com microfrontends, arquitetura distribuída começa a aparecer.

Se trabalha com autenticação, inevitavelmente aparecem cookies, tokens, OAuth, CORS, CSP e segurança web.

Se trabalha com performance, começa a precisar entender browser internals, parsing, rendering pipeline, layout, paint, compositing, memória e garbage collection.

Se trabalha com acessibilidade, precisa entender semântica, tecnologias assistivas e comportamento nativo do navegador.

Se trabalha com Design System, começa a tocar em design, UX, arquitetura de componentes e governança.

E se trabalha com um produto grande o suficiente, provavelmente precisa entender pelo menos um pouco de tudo isso.

Não necessariamente para administrar um cluster Kubernetes.

Não necessariamente para configurar uma VPC do zero.

Não necessariamente para ser DBA.

Mas o suficiente para saber onde o frontend termina e onde o problema começa.

Frontend virou uma área multidisciplinar

Talvez seja por isso que seja cada vez mais difícil explicar para alguém de fora o que exatamente um Frontend Engineer faz.

A resposta simples seria:

“Ele faz a interface.”

Mas isso descreve cada vez menos o trabalho.

O frontend está no encontro entre várias disciplinas:

                 UX / DESIGN                     │                     │BACKEND ─────── FRONTEND ─────── BROWSER                     │                     │                DEVOPS / CLOUD                     │                     │            PERFORMANCE / DATA

É provavelmente uma das poucas áreas da engenharia de software em que uma mudança aparentemente inocente na interface pode exigir conhecimento sobre:

• redes;
• protocolos web;
• APIs;
• segurança;
• infraestrutura;
• design;
• acessibilidade;
• performance;
• arquitetura;
• testes;
• observabilidade;
• SEO;
• comportamento do navegador.

O desenvolvedor frontend moderno não precisa necessariamente dominar todas essas áreas.

Mas precisa saber o suficiente de várias delas para conseguir desempenhar bem a própria função.

Ele precisa nadar.

Precisa andar.

E de vez em quando alguém coloca Kubernetes na descrição da vaga e manda ele voar também.

O frontend virou o pato da engenharia de software.

E talvez isso explique parte do paradoxo

Existe então uma contradição ainda maior.

Queremos que o frontend seja simples.

Mas esperamos que ele rode em milhares de dispositivos diferentes.

Queremos desenvolvimento rápido.

Mas esperamos SSR, acessibilidade, SEO, responsividade, testes e observabilidade.

Queremos bundles pequenos.

Mas queremos um ecossistema com uma biblioteca pronta para cada problema.

Queremos especialistas.

Mas publicamos vagas procurando alguém que conheça React, Node, Docker, AWS, Kubernetes, CI/CD, Figma, performance e talvez faça um cafezinho se sobrar tempo.

Queremos abstrações para esconder a complexidade.

Depois precisamos aprender como essas abstrações funcionam internamente quando alguma delas quebra.

Talvez seja por isso que performance no frontend seja uma discussão tão interessante.

Performance não é apenas fazer uma função executar em 1 ms em vez de 5 ms.

É decidir quanto trabalho deveria existir em primeiro lugar.

Tree shaking é ótimo.

Lazy loading é ótimo.

Code splitting é ótimo.

Memoização pode ser ótima.

Mas nenhum deles é tão eficiente quanto não enviar código desnecessário.

E é aqui que acho perigosa a interpretação que demos à famosa ideia de Donald Knuth sobre otimização prematura.

Evitar uma alocação microscópica em um código executado três vezes pode ser otimização prematura.

Passar três dias tentando economizar 800 bytes provavelmente também.

Mas perguntar:

“Precisamos realmente de toda essa arquitetura para resolver esse problema?”

não é otimização prematura.

É arquitetura.

Talvez precisemos aprender a fazer menos

Não acho que a solução seja abandonar React.

Muito menos voltar todo mundo para PHP.

Também não acho que devemos implementar manualmente cada dropdown porque instalar uma dependência fere nossos princípios.

Isso seria apenas trocar um extremo pelo outro.

Mas acho saudável recuperar uma pergunta que às vezes desaparece no desenvolvimento moderno:

qual é a menor quantidade de tecnologia necessária para resolver bem este problema?

Às vezes a resposta será PHP entregando HTML.

Às vezes será React.

Às vezes Next.js.

Às vezes um monolito.

Às vezes microfrontends.

Às vezes D3.

Às vezes uma biblioteca de 200 kB é absolutamente justificável.

E às vezes queremos desenhar sete barras.

O importante é perceber que cada camada possui um custo.

Cada abstração possui um custo.

Cada dependência possui um custo.

Cada generalização possui um custo.

E conveniência não elimina esse custo — apenas faz com que seja mais fácil não enxergá-lo.

No fim, talvez responsabilidade técnica não seja escolher sempre a solução mais performática.

Também não é escolher sempre aquela que entrega mais rápido.

É entender conscientemente o que estamos comprando e o que estamos pagando com cada decisão.

Se uma biblioteca de 160 kB economiza uma semana de desenvolvimento e resolve exatamente o problema do produto, talvez seja uma ótima troca.

Se estamos adicionando 160 kB porque ninguém parou cinco minutos para perguntar se precisava, talvez não seja.

E vocês?

Até onde o frontend deveria ir?

Kubernetes, cloud, observabilidade e arquitetura distribuída fazem parte naturalmente da profissão hoje ou estamos transformando o frontend em um pato que precisa saber fazer tudo?

E, principalmente:

onde vocês traçam a linha entre “não reinvente a roda” e “talvez essa roda esteja carregando peso demais”?

E aproveitando o jabá: se alguém quiser testar, quebrar os benchmarks ou contribuir com o pure-svg-charts:

👉 https://github.com/GabrielBaiano/pure-svg-charts

Recentemente, li o excelente guia do @andersonlimadev sobre o design de um Sistema de Pagamentos em Escala (com pico de 25.000 transações/segundo e 500 GB/dia de Ledger).

Esse cenário trouxe-me um insight prático de engenharia de software:
como otimizar o footprint de armazenamento e indexação temporal sem perder a legibilidade humana e o contexto distribuído?

Para resolver esse trade-off entre performance (binário compacto) e operabilidade (string legível), desenvolvi a especificação JEC Enterprise 64-Bit (Julia Epoch Compact).

O que é o JEC Enterprise?

O JEC realiza Bit Packing na camada de aplicação. Ele encapsula alta precisão temporal (microssegundos) e 7 bits de metadados livres (User Space) dentro de uma única palavra nativa de 64 bits (8 Bytes).

Em sistemas distribuídos de alta escala, ele brilha ao resolver a colisão de aliases sem tabelas de mapeamento complexas ou UUIDs opacos de 16 bytes. Se dois servidores processam eventos no exato mesmo microssegundo, os 7 bits de User Space (usados para o ID do microsserviço ou região) garantem a unicidade cross-platform.

Aplicação Prática no Ledger de Dupla Entrada

No design de tabelas proposto para o Ledger, estimam-se terabytes de armazenamento mensais. Se substituirmos os IDs textuais e os timestamps padrão por chaves uint64 geradas via JEC, obtemos:

• Redução de Payload no Kafka e Banco: Um único campo de 8 bytes transporta o Instante UTC exato + ID do microsserviço emissor.
• Precisão para Antifraude e Conciliação: Resolução nativa em microssegundos, crucial para garantir que a sequência contábil (Débito antes do Crédito) seja respeitada sem ambiguidades em picos de carga.

O Caso Limite do Bit 63 (Lição de Produção)

Como o projeto possui uma camada em Dart (onde inteiros de 64 bits são signed) e suporte para Web3/EVM (onde são unsigned), deparámo-nos com um comportamento crítico na ordenação binária nativa em bases de dados como o PostgreSQL (BIGINT). Metade do espaço do Header ordena de forma invertida devido ao bit de sinal.

A solução em SQL para manter a ordenação gratuita e fiável é simples:

-- 1. Estrutura da tabela usando o JEC como chave única temporalCREATE TABLE ledger_entries (    jec_id BIGINT PRIMARY KEY, -- Acumula tempo preciso + ID do microsserviço    tx_id VARCHAR(64) NOT NULL,    account_id BIGINT NOT NULL,    direction VARCHAR(6) NOT NULL CHECK (direction IN ('DEBIT', 'CREDIT')),    amount NUMERIC(20,6) NOT NULL,    currency CHAR(3) NOT NULL);-- 2. Consulta de Auditoria corrigindo a ordenação do Bit 63 (máscara lógica)SELECT     jec_id,    tx_id,    direction,    amount,    (jec_id >> 57) & 127 AS microservice_id FROM ledger_entriesORDER BY (jec_id & x'7FFFFFFFFFFFFFFF'::int8) ASC;

O repositório é open-source e conta com implementações oficiais para Dart e Solidity.

O que acham dessa abordagem de Bit Packing para aliviar o gargalo de I/O e armazenamento em arquiteturas de missão crítica?

GitHub - jec-64bit-enterprise

Um vídeo carta de vendas com IA não começa pelo avatar. Começa pela decisão que o público precisa entender, pela evidência disponível e por um roteiro que não promete mais do que a equipe consegue provar. A geração automática ajuda a organizar cenas, mas a clareza da oferta continua sendo um trabalho editorial.

Considere um exemplo hipotético: uma pequena empresa de software de agenda quer explicar como uma equipe marca reuniões, recebe lembretes e consulta o histórico. O objetivo do vídeo é apresentar o fluxo e convidar a pessoa a conhecer o produto. Não há cliente, taxa de conversão ou depoimento real neste exemplo. A utilidade está em mostrar como revisar o material.

Vídeo carta de vendas com IA precisa de um briefing

Escreva uma frase para cada item: quem assiste, qual situação reconhece, o que você explica e qual ação é razoável depois. Se a equipe não concorda com essas frases, a ferramenta preencherá o vazio com generalidades.

Defina também o que o vídeo não fará. “Explicar o fluxo de agendamento” é um escopo verificável. “Fazer a equipe vender mais” é uma conclusão que exigiria dados e contexto. Um limite explícito reduz a tentação de colocar uma promessa forte no primeiro segundo.

Divida a VSL em blocos revisáveis

Use uma sequência simples:

Uma cena deve responder a uma pergunta. Se a narração fala de lembretes enquanto a imagem mostra um painel de relatórios, o vídeo pode parecer bonito e ainda assim ensinar a coisa errada. O roteiro deve indicar o nome da tela ou do documento usado como referência.

Passe o roteiro para o Leadde.ai

A página em português descreve entradas como tema, arquivo, texto, roteiro e PPT, além de apresentar narrador, elementos visuais, legendas e cenas personalizadas. Isso faz dela um ponto de partida para organizar o vídeo. Não é uma validação da copy e não substitui a conferência da oferta.

Para cada parágrafo, crie três colunas: fala, visual e prova. “A equipe recebe lembretes” precisa apontar para uma tela ou documento que realmente mostre o recurso. “Clientes economizam tempo” precisa de fonte e método; sem isso, reformule como objetivo ou retire. A tabela também ajuda a decidir onde uma captura é mais útil que um avatar.

Faça duas revisões diferentes

Na primeira, leia apenas o texto. Marque palavras como “melhor”, “mais rápido”, “garantido” e “sem esforço”. Cada comparação precisa de base. Um depoimento só entra com autorização, contexto e identificação correta. Um número que veio de uma apresentação antiga deve ser atualizado ou retirado.

Na segunda, assista e leia as legendas ao mesmo tempo. Confira nomes, datas, condições e rótulos de interface. Observe se a imagem sustenta a fala. Uma animação de calendário pode explicar uma sequência, mas não prova que todos os usuários terão aquele resultado. Se uma frase depende de um detalhe, mantenha esse detalhe visível.

Entregue uma versão que possa ser atualizada

Guarde o briefing, o roteiro, a tabela de cenas e a data da revisão. Quando mudar uma condição, liste as cenas afetadas. Não mantenha uma tela antiga apenas porque a narração parece boa. Uma pequena mudança no produto pode alterar o sentido de uma explicação.

Antes de publicar, peça a alguém fora do projeto para resumir a oferta em uma frase. Compare o resumo com o briefing. Se aparecer uma promessa nova, o roteiro precisa de revisão. Essa leitura também confirma se o próximo passo está claro para quem não conhece o produto.

Uma revisão final deve ser feita por alguém que não participou da redação. Essa pessoa assiste sem o briefing e tenta responder: qual problema está sendo tratado, o que a oferta inclui e qual é o próximo passo? Se não consegue responder, não adicione efeitos. Reescreva a cena ou acrescente a fonte que falta.

Também vale separar a versão para leitura da versão para publicação. O roteiro aprovado, as legendas e as cenas devem ter uma identificação comum. Assim, quando uma condição comercial mudar, o editor encontra o trecho certo sem procurar em todo o vídeo.

Uma boa carta também respeita o momento do leitor. A primeira cena pode reconhecer a situação, mas não precisa pressionar por uma decisão imediata. Mostre o que será explicado e deixe a pessoa avaliar se o assunto é relevante. O bloco de oferta deve listar o que está disponível hoje, enquanto o próximo passo explica como obter mais informação.

Peça ao responsável pelo produto que confira nomes de planos, condições e links antes de cada publicação. Se o roteiro mencionar um recurso que ainda está em teste, identifique-o como tal ou retire a frase. A transparência reduz correções posteriores e mantém a mensagem compreensível para quem chega ao vídeo sem contexto.

Preciso colocar todo o roteiro como legenda?

Não. Use as legendas para acompanhar a fala e deixe na tela os rótulos que ajudam a localizar a ação. Texto excessivo reduz a chance de a pessoa notar a demonstração. Faça a revisão no reprodutor real e em uma tela pequena antes de publicar.

Todo vídeo de vendas precisa de um apresentador?

Não. Use um apresentador quando a transição ou o tom humano forem importantes. Use uma captura, uma tabela ou uma demonstração quando a evidência visual for mais clara. A escolha deve servir à explicação, não preencher espaço.

Essa foi a pergunta que me levou a desenvolver o OCS Patrimônio.

Em muitos ambientes de TI existe uma situação curiosa:

O OCS Inventory possui uma quantidade enorme de informações sobre os equipamentos.

Ele sabe:

hostname;
IP;
MAC;
sistema operacional;
hardware;
número de série;
placa-mãe;
BIOS;
entre várias outras informações.

Por outro lado, o controle patrimonial costuma estar em outro lugar:

📊 Excel
📋 planilha compartilhada
📝 documento
📅 agenda
🗂️ sistema patrimonial isolado.

E aí começa o trabalho manual.

"Esse patrimônio 000123 pertence a qual computador?"

"Qual é o patrimônio desse equipamento?"

"O número de série dessa máquina está em qual linha da planilha?"

"Essa máquina já foi inventariada?"

Foi para eliminar justamente essa etapa manual que desenvolvi o OCS Patrimônio.

A ideia

A aplicação utiliza os dados do OCS Inventory NG para localizar os equipamentos e permite correlacioná-los com um número de patrimônio.

A identificação pode ser feita utilizando informações únicas do hardware, como:

BIOS + placa-mãe + número de série

E a parte patrimonial pode ser informada manualmente ou através de leitura da plaqueta.

📱 E aqui entra uma parte importante

A interface foi pensada para funcionar também em dispositivos móveis.

Então o técnico pode estar fisicamente diante do equipamento.

Ele pega o celular.

Lê o QR Code/código de barras da plaqueta.

O sistema recebe o número do patrimônio.

Localiza o equipamento correspondente no OCS.

E realiza a correlação.

O objetivo não é criar complexidade

É justamente reduzir complexidade.

A ideia é transformar:

planilha → procura manual → conferência → número de série → associação

em:

📱 escanear → 🔎 localizar → 🔗 correlacionar

Também existe uma visão geral mostrando equipamentos inventariados, correlacionados e pendentes.

Se você só precisa reagir à mudança em uma tabela MySQL, não deveria precisar consultar o banco a cada poucos segundos — muito menos adotar uma plataforma complexa de CDC.

É para esse cenário que serve o Mini CDC. Ele acompanha diretamente o binlog do MySQL, identifica as mudanças que realmente importam e publica os eventos correspondentes no RabbitMQ.

Por exemplo:

“Quando o campo status de um pedido mudar para APPROVED, publique um evento.”

Sem polling. Sem consultas repetitivas. Sem colocar essa responsabilidade dentro da aplicação principal. Por meio de uma configuração simples, é possível definir:
• quais tabelas devem ser monitoradas;
• quais operações devem ser consideradas;
• quais campos precisam realmente ter mudado;
• quais valores devem atender às condições;
• qual evento e routing key devem ser publicados.

Uma única conexão de replicação pode acompanhar várias tabelas. O Mini CDC também oferece checkpoint para retomada após reinicializações, Publisher Confirms, identificadores determinísticos para idempotência, health checks e métricas operacionais simples.

O objetivo não é substituir plataformas completas como o Debezium. A proposta é permanecer pequeno e resolver bem um problema específico:

MySQL binlog → filtros configuráveis → RabbitMQ

Para pequenos projetos, isso significa menos infraestrutura, menos código de integração e uma forma simples de reagir às mudanças no banco de dados.

O projeto foi desenvolvido em Go, para execução em multiplas plataformas com foco em simplicidade, baixo consumo e facilidade de manutenção.

O Mini CDC é open source, e o README explica no detalhe como ele funciona e como configurá-lo:
https://github.com/damtaipu/minicdc

#Go #MySQL #RabbitMQ #CDC #ArquiteturaDeSoftware #OpenSource

Uma run de agent que falhava terminava com um log e um dar de ombros. Nesta semana o oh-my-agent fechou esse ciclo: uma falha pode ser capturada como incidente, promovida a fixture de uma skill e entregue a um otimizador que edita a skill sob um orçamento de dispatches. Foram 131 commits, e a CLI saiu da versão 14.7.11 para a 14.13.1.

O que mudou

• Captura e promoção de incidentes: oma harness incident scan lista runs com falha, bloqueadas ou parciais que nenhum incidente referencia. oma harness incident promote deriva uma fixture de regressão para a skill que o agent usou e só a admite se ela reprovar o output de falha registrado. oma harness feedback --scan-runs encadeia captura, promoção e otimização. Runs finalizadas agora guardam os últimos 64 KiB do log do runner, para que a fixture seja validada contra o que o agent realmente disse.
• Evolução de skills com orçamento: oma skill optimize só aceita uma edição quando nem o split de validação nem o de treino regridem e pelo menos um melhora. constitution.budget.max_dispatches_per_run agora é aplicado: a chamada que estouraria o limite é recusada e a promoção fica bloqueada. Toda edição aplicada registra sua linhagem, e oma skill promotions e oma skill rollback leem esse registro.
• Meta-otimização: oma skill meta-optimize trata o próprio prompt do otimizador como candidato. A promoção exige um intervalo de 95% por bootstrap pareado (com seed) acima de zero e pelo menos três pares. O primeiro procedimento adotado superou o atual em 0.27 na média, com intervalo [0.04, 0.54], e acrescentou três regras de grounding para edições propostas de skills.
• Eval de roteamento: oma skill eval --routing mostra ao modelo a descrição de todas as skills instaladas e registra se ele escolhe a skill alvo, uma vizinha ou nenhuma. Isso separa "o corpo da skill ajuda" de "a skill é selecionada".
• Guard de code intelligence: um hook PreToolUse nega Grep, Glob e buscas recursivas no shell (rg, grep -r, find -name, git grep) enquanto houver um provider configurado. A mensagem de negação indica qual ferramenta do Serena usar. OMA_CI_ALLOW_NATIVE=1 é a saída de emergência, e providers.code_intelligence_guard: off desativa o guard.
• Avisos no início da sessão: o snapshot de estado agora anuncia promoções de skills e procedimentos uma única vez, em uma linha por promoção, com a edição e os ganhos. oma doctor ganhou uma nota de Evolution.
• Relatórios para o Orca: agents filhos disparados pelo oma reportam seu ciclo de vida ao Orca. O Qwen ganhou definições nativas de agent.

O que foi corrigido

• O job semanal de cross-post falhava em toda execução depois que model_preset passou para auto. O claude --output-format json encapsula a resposta em um envelope, e runAgent devolvia esse envelope cru. Agora ele extrai o caminho response_jq configurado e cai para o stdout bruto nos vendors que não têm um.
• Jobs do SO registrados antes da renomeação do comando continuavam chamando oma schedule:run <id> e falhavam a cada disparo, enquanto schedule list os mostrava como sincronizados. A grafia antiga agora é aceita quando o SO a invoca, a detecção de drift ganhou o estado stale, e oma schedule sync e oma update reescrevem os registros desatualizados.
• cd $HOME && oma link claude tratava o HOME como um projeto e reescrevia os comandos de hook globais do Claude. link e update agora recusam o modo projeto a partir do HOME (#788).
• O judge de skills lia PASS/FAIL do envelope cru do Claude, onde "failed":0 aparecia antes do veredito, então todo veredito virava FAIL. Agora as saídas são extraídas do envelope antes da pontuação, e as gravações antigas são descartadas.
• --repeats 3 virava NaN porque um parseInt puro recebia o valor anterior como radix. Valores de opções variádicas (--skill a b) não disparam mais o guard de posicional solto.
• Projetos sincronizados antes da v11 ainda rodavam o próprio Serena a cada sessão. A migration 029 reescreve esses launchers para a entrada compartilhada oma bridge, na forma nativa de cada vendor.
• oma update respeita uma lista explícita de vendors em vez de detectar a partir dos diretórios do projeto.

O que melhorou

• Uma época de otimização com quatro candidatos levava quarenta minutos porque cada arm e cada judge rodavam em série. Os dispatches reais agora passam por um pool limitado (OMA_SKILL_EVAL_CONCURRENCY, padrão 4), e a meta-otimização sobrepõe as runs internas entre skills (OMA_META_CONCURRENCY, até 4). O timeout por dispatch é de 180s, com uma nova tentativa em caso de timeout.
• As fixtures testam o que o corpo da skill afirma. O conjunto do oma-debug foi reescrito depois que a primeira versão marcou 89% sem a skill. As doze novas marcam 25% de baseline e 100% com a skill. O oma-refactor foi de 16.7% para 100% do mesmo jeito. oma-docs, oma-scm e oma-qa também têm, cada uma, doze fixtures alinhadas ao corpo da skill.
• A primeira edição verificada pelo loop entrou no oma-docs: held-in de 55.6% para 77.8%, com a validação held-out inalterada em 100%.
• O custo ficou visível. As runs reportam chamadas de modelo por melhoria verificada, então um procedimento que ganha mais gastando mais aparece como tal.
• O Gortex saiu e a code intelligence voltou para a bridge do Serena. Ele saturava a CPU reaplicando patches em um índice de 4 GB e não expunha nenhum limite.
• Os arquivos de skills e de prompts compartilhados foram enxugados para cortar regras incondicionais de preflight, pontuação e aprovação. Os guias de incidentes saíram nos 11 locales da documentação.

Instalação

# macOS / Linuxcurl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.sh | bash

# Windows (PowerShell)irm https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.ps1 | iex

Links

O oh-my-agent é feito para times que orquestram mais do que escrevem prompts. O próximo passo é rodar o loop de feedback em agendamento sobre runs reais de projetos, para que as edições de skills cheguem com a evidência anexada.

Texto original (em ingles): https://dev.to/gracefullight/oh-my-agent-failed-runs-now-turn-into-skill-regression-tests-572m

https://github.com/first-fluke/oh-my-agent

Quando usamos agentes de IA para programar, o repositório guarda o resultado, mas normalmente perde as decisões, correções e mudanças de direção que levaram até ele.
Por isso criei o PromptSourceCode, um projeto open source para Codex Desktop que mantém um histórico cronológico e legível das interações e dos anexos relevantes junto ao projeto. Tudo funciona localmente, sem serviço em segundo plano ou envio automático de dados.

O projeto ainda está focado em Codex Desktop. Ficaria muito feliz em receber feedback sobre a ideia e o processo de instalação:

https://github.com/ironwood-lang/prompt-source-code

Eu sou o autor do projeto e desenvolvo sozinho. O link no final passa por um redirecionamento meu que só conta cliques.

A extensão mostra legendas traduzidas em tempo real durante uma chamada no Meet, no Zoom ou no Teams pelo navegador, sem nenhum bot na reunião. Abaixo, as três partes que deram mais trabalho.

1. Capturar o áudio da aba no Manifest V3

No MV3 o service worker não tem Web Audio, então a captura fica em dois lugares. O service worker chama chrome.tabCapture.getMediaStreamId({ targetTabId }), que devolve só um id, e cria um documento offscreen com reasons: ['USER_MEDIA']. Lá dentro o id vira stream no getUserMedia com chromeMediaSource: 'tab', e um AudioWorkletNode junta os canais em mono e manda Int16 PCM em blocos de 4096 amostras.

Duas coisas custaram tempo. O stream precisa ser ligado de volta em audioCtx.destination, senão a captura silencia a aba e a pessoa para de ouvir a própria reunião. E o erro "Cannot capture a tab with an active stream" aparece quando o stream anterior não foi liberado, e não sai nem recarregando a página: o jeito foi fechar o documento offscreen e consultar chrome.tabCapture.getCapturedTabs() até a aba sair de active.

Contra o getDisplayMedia() numa página comum: aqui não aparece o seletor de tela, mas a extensão precisa ter sido invocada naquela aba (activeTab) e só pega o áudio da aba.

2. Dois provedores custaram muito mais que um

A primeira versão usava um serviço para reconhecimento e outro para tradução. Para a tradução acompanhar a fala, os resultados parciais também iam para o tradutor, e a mesma frase era traduzida duas ou três vezes. Uma hora de chamada saía por volta de US$ 2,55, acima do que os planos cobriam.

Troquei por um provedor que devolve transcrição e tradução no mesmo stream, com chave temporária emitida pelo servidor. Pela fatura real, hoje uma hora custa uns US$ 0,15. O preço disso é atraso: a legenda final chega em alguns segundos, contra uns dois antes. E o provedor não separa pt-BR de pt-PT, as duas viram pt.

3. O cronômetro contava errado

O tempo começava quando a conexão abria, não quando chegava a primeira legenda, então numa aba sem som os minutos eram gastos à toa. Achei olhando as minhas próprias estatísticas, agora a contagem começa com o primeiro resultado real.

Limites: só o áudio da aba do navegador, app desktop e celular não, e a legenda final demora alguns segundos.

Críticas sobre a parte técnica são bem-vindas, principalmente sobre a captura no MV3: https://gettrippi.app/go/tabnews_pitch

Sou o mantenedor do LibreDB Studio, um SQL IDE open source sob licença MIT que roda no navegador e conecta em 16 bancos diferentes (PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, Redis, ClickHouse, DuckDB e outros). O repositório está em
https://github.com/libredb/libredb-studio

O projeto já tem README em chinês, japonês, espanhol, urdu e hindi. Falta o português. A issue é esta:
https://github.com/libredb/libredb-studio/issues/594

Duas coisas que valem dizer antes de alguém gastar tempo:

O escopo é menor do que parece. O README em inglês tem mais de mil linhas, mas as traduções existentes têm cerca de trezentas.
Elas são resumos deliberados: carregam a proposta do projeto, a lista de bancos, a tabela de instalação e o quick start, e deixam de fora as seções profundas. A tradução em português deve seguir o mesmo recorte.

A revisão é objetiva, não é questão de gosto. Existe um script de verificação que roda no CI e checa duas coisas: que o conjunto de nomes de bancos seja idêntico ao do README em inglês, e que todo comando de instalação apareça igual, caractere por caractere. Um sudo faltando ou um comando parafraseado quebra o check. O resto é revisão de texto normal.

O que eu não quero é saída crua de tradutor automático. Se o texto ler como máquina, eu fecho o PR. Termos técnicos e nomes de produto ficam melhor em inglês do que traduzidos por aproximação.

Se alguém topar, comenta na issue para eu reservar. Respondo rápido nas revisões.

Eaii, rapazeada

Sou dev solo e nos últimos meses construí o ZapBroker: uma automação de WhatsApp feita especificamente pra corretor de imóveis.

Não é uma "ferramenta de disparo em massa" genérica: o produto inteiro é desenhado em cima da rotina de quem vende imóvel.

Stack, pra quem gosta de saber o que tem por trás:

• Node.js / Express — backend
• Next.js — frontend
• Supabase (Postgres) — banco de dados
• Evolution API — integração com WhatsApp
• OpenRouter — IA
• AbacatePay (Pix) — checkout

Ainda não lancei

E é exatamente por isso que tô aqui.

Eu sou a única pessoa que testa esse sistema de perto, e isso é ruim. Todo bug de segurança que eu não vejo pode simplesmente estar passando despercebido porque eu já sei como o sistema funciona por dentro.

Então quero gente de fora tentando quebrar isso.

O que eu tô liberando

Vou soltar aqui um link único de cadastro com 10 vagas.

Quem entrar vai receber:

• Plano completo (Pro)
• 3 dias de acesso
• Sem custo

Quem clicar primeiro e completar o cadastro pega uma vaga.

Quando chegar em 10 usuários, o link simplesmente para de aceitar gente nova.

O que eu queria que vocês avaliassem

Segurança — essa é a prioridade real do post.

Tentem de tudo:

• autenticação
• acesso indevido entre contas
• dados vazando de uma conta pra outra
• requests forjadas
• manipulação de parâmetros
• permissões
• endpoints
• qualquer coisa que consiga quebrar ou contornar alguma regra do sistema

Se acharem alguma vulnerabilidade, por favor, avisem.

Não precisa ter dó 😂

Fluxo do WhatsApp

Também quero saber se o disparo funciona ponta a ponta:

• conectar o número
• subir uma lista
• iniciar o disparo
• mensagens sendo enviadas
• receber respostas
• verificar se tudo continua funcionando corretamente

Experiência de uso

Aqui também não estou procurando elogio.

Prefiro um feedback grosseiro e certeiro do que um "ficou legal" educado.

Se alguma coisa estiver confusa, ruim, lenta, mal posicionada ou simplesmente não fizer sentido, fala.

A ideia é encontrar os problemas agora, antes de colocar isso na mão de clientes.

Link: https://zapbroker.dev/signup?invite=A77FB845
Para feedbacks: https://zapbroker.dev/feedback

Valeu por lerem até aqui 🤝

Disparar e-mails transacionais diretamente de dentro dos endpoints da sua aplicação cria acoplamento excessivo, eleva o tempo de resposta HTTP (handshakes SMTP levam facilmente entre 500ms e 2s) e espalha credenciais sensíveis por vários microsserviços.

O Hermes é um gateway open-source e multi-tenant desenvolvido para centralizar esse fluxo. Para evitar que a lentidão ou instabilidade de provedores SMTP trave as requisições upstream, o sistema separa rigidamente a recepção HTTP do envio real utilizando filas assíncronas com BullMQ e Redis. No campo da segurança, as credenciais SMTP em repouso são protegidas com AES-256-GCM, enquanto as chaves de API programáticas utilizam uma estratégia híbrida de prefixo indexado + Argon2id para garantir buscas em O(1) sem abrir mão de proteção contra ataques de força bruta por hardware.

Os repositórios e o pacote já estão disponíveis:

• API Gateway e Workers: github.com/RuanLopes1350/hermes-api
• Painel Administrativo: github.com/RuanLopes1350/hermes-front
• SDK TypeScript (Client): github.com/RuanLopes1350/hermes-client
• Pacote no NPM: @ruanlopes1350/hermes-client

1. O Problema que Resolvemos

Em arquiteturas tradicionais, é comum ver o transporte SMTP (usando bibliotecas como Nodemailer) instanciado diretamente no fluxo de criação de conta ou recuperação de senha:

[Requisição de Cadastro]     └──► Salva no Banco     └──► Conecta no SMTP (DNS + TLS Handshake + Envio) ──► Espera 1.5s ──► Responde 200 OK

Esse modelo gera três gargalos:

1. Latência no cliente: O usuário final fica com o botão travado esperando a confirmação da rede externa de e-mail.
2. Perda de mensagens: Se o servidor SMTP oscilar ou aplicar rate limit momentâneo, o e-mail se perde ou exige lógica de retry local complexa que pode sobrecarregar a própria API.
3. Gestão de credenciais: Conforme a quantidade de microsserviços cresce, senhas de app e tokens de envio ficam dispersos em múltiplos arquivos .env.

O Hermes atua como uma barreira isoladora com modelo multi-tenant: cada serviço cadastrado tem suas próprias chaves, templates e histórico de auditoria.

┌─────────────────────────────────────────────────────────────┐│          APLICAÇÕES CLIENTES (@ruanlopes1350/hermes-client) │└──────────────────────────────┬──────────────────────────────┘  (POST /api/emails + X-API-Key)│       ▲ (Webhook assinado                                │       │  para rotação de chave)                                ▼       │┌───────────────────────────────────────┴─────────────────────┐│                       HERMES API GATEWAY                    ││   (Recepção rápida, validação de schema e enfileiramento)   │└──────────────┬──────────────────────────────┬───────────────┘               │                              │(Grava como 'pending' no banco)               │ (Enfileira Job no BullMQ)               ▼                              ▼┌──────────────────────────────┐ ┌────────────────────────────┐│      POSTGRESQL (Drizzle)    │ │        REDIS STORE         ││ (Serviços, Chaves, Templates)│ │ (Fila de Jobs e Pub/Sub)   │└──────────────────────────────┘ └─────────────┬──────────────┘                                               │                                               ▼                                 ┌────────────────────────────┐                                 │       HERMES WORKER        │                                 │  (Consome fila, descriptografa,│                                 │   compila MJML e envia SMTP)│                                 └─────────────┬──────────────┘                                               │                                               ▼ (TLS / SMTP)                                 ┌────────────────────────────┐                                 │    PROVEDOR SMTP / GMAIL   │                                 └────────────────────────────┘

2. Por que Separamos a API do Worker?

A separação em processos Node.js independentes garante previsibilidade operacional:

API Gateway (server.ts)

A API tem uma única missão: receber o payload, validar o formato dos dados, autenticar a API Key, registrar o e-mail no PostgreSQL como pending e postar o job na fila do Redis.

• Tempo de resposta típico: < 25ms.
• A API retorna imediatamente 201 Created contendo o ID do e-mail para rastreamento. O endpoint que chamou o Hermes segue seu fluxo sem esperar a entrega de rede.

Email Worker (worker.ts)

O Worker opera em background consumindo a fila do BullMQ:

1. Resgata a credencial de envio do tenant (senha SMTP pura ou token dinâmico via Google OAuth2/Gmail API).
2. Descriptografa a credencial em memória.
3. Compila o template MJML injetando as variáveis dinâmicas com Handlebars.
4. Dispara a mensagem via Nodemailer.
5. Em caso de sucesso ou falha definitiva, atualiza o status no PostgreSQL (sent ou failed) com stack de erros e timestamp.
6. Emite um evento via Redis Pub/Sub, que alimenta as telas do painel administrativo em tempo real através de Server-Sent Events (SSE).

Se o provedor SMTP retornar erro temporário de rede, o BullMQ executa retentativas com backoff exponencial com jitter, sem impactar a capacidade da API de continuar recebendo novas requisições.

3. Decisões de Criptografia e Segurança

3.1 API Keys: O Dilema de Performance vs. Força Bruta (Argon2id)

Se salvarmos chaves de API com hash simples (como SHA-256), um vazamento de banco permite ataques de dicionário acelerados por GPU. Por outro lado, se usarmos um algoritmo moderno e pesado como Argon2id na chave inteira, como não há usuário informado na requisição, o servidor precisaria rodar o argon2.verify() contra todas as chaves do banco a cada requisição HTTP (O(N)), o que inviabilizaria o servidor.

A solução adotada divide a chave em duas partes no formato hm_prefix.secret:

hm_b5c92a10.e4d3c2b1a0f9e8d7c6b5a4938271605f...└─────┬───┘ └──────────────────────┬──────────────────────┘      │                            │ Segredo Aleatório (32 bytes em HEX - 64 caracteres)      └ Prefixo Público (8 caracteres HEX indexados no banco)

1. Busca Indexada (O(1)): O middleware extrai o prefixo público (hm_b5c92a10) e faz uma busca indexada no PostgreSQL (WHERE prefix = '...' AND is_active = true). Isso isola instantaneamente o registro exato.
2. Validação Forte: Com a linha recuperada, o sistema aplica o argon2.verify(key_hash, secret) exclusivamente no segredo recebido.
3. Resultado: Busca ultra rápida no banco associada a uma barreira resistente contra ataques paralelos em hardware dedicado.

3.2 Credenciais em Repouso: Cifragem de Envelope com AES-256-GCM

Senhas de envio SMTP e tokens de refresh do Google OAuth2 nunca ficam em texto limpo no banco de dados. Eles são gravados no formato:

<iv_hex>:<auth_tag_hex>:<ciphertext_hex>

• AES-256-GCM: Fornece tanto sigilo quanto integridade autenticada.
• IV Dinâmico: Um vetor de inicialização de 16 bytes aleatório é gerado a cada gravação, garantindo que a mesma senha resulte em dados cifrados completamente distintos a cada update.
• Auth Tag: Impede adulterações silenciosas no banco de dados; qualquer bit alterado faz a descriptografia falhar.
• Master Key: A chave mestra reside unicamente nas variáveis de ambiente do servidor e nunca transita pela rede.

4. Rotação Automática de Chaves ("Webhook-First")

Trocar chaves de API manualmente em ambientes de produção costuma gerar indisponibilidade se o cliente não for atualizado no mesmo instante. O Hermes possui um mecanismo de rotação automática com tolerância a falhas:

1. Um cronjob diário via BullMQ (system.ts) busca credenciais ativas com data de expiração próxima do limite configurado (padrão: 3 dias).
2. O sistema gera a nova chave candidata e envia uma requisição POST HTTPS para o endpoint de webhook configurado no serviço do cliente.
3. A requisição leva o cabeçalho X-Hermes-Signature, gerado via HMAC SHA-256 utilizando o segredo privado do serviço:

   const signature = crypto  .createHmac('sha256', webhookSecret)  .update(JSON.stringify(payload))  .digest('hex');

4. Garantia de Entrega (Webhook-First): Se o webhook do cliente falhar (timeout ou erro 5xx), o banco de dados do Hermes não é alterado. A chave antiga continua funcionando normalmente e o BullMQ agenda uma nova tentativa.
5. Atualização Efetiva: Apenas quando a aplicação cliente confirma com 200 OK o recebimento da nova chave, o Hermes comita o novo hash e expiração no PostgreSQL.

5. Integração com o SDK (hermes-client)

Para simplificar o consumo, publicamos o pacote @ruanlopes1350/hermes-client no NPM. Ele conta com interface fluente e middlewares para recepção do webhook de rotação:

import { HermesClient, MemoryAdapter } from '@ruanlopes1350/hermes-client';const hermes = new HermesClient({  baseUrl: 'https://api-hermes.suaempresa.com',  storageAdapter: new MemoryAdapter(process.env.HERMES_API_KEY!),});// Envio de e-mail usando templates MJML gerenciados no painelawait hermes.email()  .to('cliente@email.com')  .subject('Confirmação de Acesso')  .useTemplate('cltmpl_cadastro_usuario', {     nome: 'Maria',     codigo: '482910'   })  .send();

6. Tradeoffs e Limitações Conhecidas

Uma análise técnica sincera exige pontuar as desvantagens e os limites da arquitetura:

1. Custo de Manutenção de Infraestrutura:
   O Hermes exige manter Node.js, PostgreSQL, Redis e containers de workers. Para projetos pequenos que disparam menos de 100 e-mails por mês, serviços gerenciados (como Resend ou Postmark) trazem menos sobrecarga operacional. O Hermes faz sentido quando há necessidade de soberania de dados, multi-tenancy interno ou conexão com infraestruturas SMTP legadas/próprias.
2. Custo de CPU do Argon2id sob Carga Alta:
   Mesmo com o prefixo reduzindo a busca a O(1), o cálculo do Argon2id é intencionalmente intensivo em memória e processamento. Picos extremos de requisições (>500 req/s simultâneas diretamente na API) elevam consideravelmente o uso de CPU. Para cargas muito altas, é recomendável manter uma camada de rate limiting ou proxy reverso na frente.
3. Escalonador Atrelado ao Docker Socket:
   O módulo de auto-scaling de workers incluído (scaler.ts) inspeciona o volume de jobs no Redis e ajusta o número de réplicas via CLI do Docker Compose local. Esse formato atende bem VPSs únicas, mas não substitui orquestradores distribuídos (como HPA em Kubernetes).
4. Reputação de IP e Entregabilidade:
   O Hermes resolve fila, templates, segurança e auditoria, mas não gerencia reputação de IP nem configurações de DNS (SPF, DKIM, DMARC), que continuam sob responsabilidade da configuração do servidor SMTP apontado.

7. Código Aberto e Contribuições

O projeto foi estruturado com foco em boas práticas de TypeScript, Drizzle ORM e isolamento de processos:

• API & Workers: hermes-api no GitHub
• Frontend Next.js: hermes-front no GitHub
• SDK Node/TypeScript: hermes-client no GitHub e no NPM

Feedbacks sobre a arquitetura e sugestões de melhoria são sempre bem-vindos!

Sou desenvolvedor Java full stack júnior e quero contar um pouco das práticas que estou utilizando para revisar PRs automáticos em um projeto pessoal meu. Eu utilizo o Dependabot para checar semanalmente atualizações das bibliotecas e pacotes utilizados no meu projeto. A cada semana ele abre cerca de 4 a 7 PRs de forma automática, e decidi utilizar isso a meu favor para aprender um pouco mais sobre como revisar PRs. Vou usar como exemplo um PR de atualização do pacote @eslint/js da versão 9.39.5 para 10.0.1 que gerava um conflito não capturado pelas verificações do meu CI.

Checklist

O checklist que sigo é esse:

• Identificar primeiramente a finalidade. Se é correção, feature nova, documentação ou atualização de versão.
• Ver quais arquivos foram alterados.
• Confirmar se as mudanças afetam o projeto atual (de longe a parte mais chata).
• Conferir o que os testes cobrem e, se novos testes foram adicionados, confirmar se eles verificam o comportamento afetado na aplicação.

Identificando a finalidade do PR

Claro, o título chore(deps-dev): bump @eslint/js from 9.39.5 to 10.0.1 já era bastante intuitivo. A descrição do PR também confirmava essa atualização, todos os checks estavam verdes e apenas os arquivos package.json e package-lock.json tinham sido alterados. Era só fazer o merge já que tudo estava aparentemente OK, mas o questionamento que resolvi fazer foi:

• É uma atualização da versão 9 para a versão 10. Será que os testes cobrem o que pode dar errado nessa mudança?

Foi quando eu decidi olhar as notas de release. Na passagem para a versão 10.0.0, havia uma lista com 22 BREAKING CHANGES! Isso já era motivo para olhar com mais atenção.

Alterações do PR e início do problema

Aqui o primeiro passo é não julgar o impacto do commit pela quantidade de arquivos alterados. Mesmo alterando somente os arquivos de dependências, o importante é saber o que essa nova versão introduziu e como ela poderia afetar o seu projeto.

Antes mesmo de abrir os commits citados nas releases, acabei encontrando um possível problema nos arquivos alterados. Tanto o package.json quanto o package-lock.json trocavam a faixa de versões permitidas do @eslint/js de ^9.39.3 para ^10.0.1, porém o ESLint por si só não acompanhava a atualização. Ficou assim:

package.json

Antes:

{  "devDependencies": {    "@eslint/js": "^9.39.3",    "eslint": "^9.39.3",    "eslint-plugin-react": "^7.37.5"  }}

Depois:

{  "devDependencies": {    "@eslint/js": "^10.0.1",    "eslint": "^9.39.3",    "eslint-plugin-react": "^7.37.5"  }}

package-lock.json

Na entrada de @eslint/js, a versão exata mudou de 9.39.5 para 10.0.1. O ESLint continuou registrado como 9.39.5. Além disso, a entrada do pacote atualizado passou a incluir este requisito:

{  "peerDependencies": {    "eslint": "^10.0.0"  },  "peerDependenciesMeta": {    "eslint": {      "optional": true    }  }}

Compare o antes e depois. Os dois arquivos atualizavam o @eslint/js e nenhum dos dois atualizava o ESLint. Mas isso, sozinho, não prova um erro: pacotes com números de versão diferentes podem ser compatíveis.

O problema estava no peerDependencies: o próprio @eslint/js declarava que precisava do ESLint na faixa ^10.0.0. Ou seja, a partir de 10.0.0 e abaixo de 11.0.0, e não qualquer versão superior a 10.

Já o meu projeto pedia ^9.39.3, que não permite chegar à versão 10. O package.json dizia quais versões eram permitidas, e o lockfile registrava a versão exata escolhida: 9.39.5.

Para não confundir os dois pacotes: o eslint executa a análise do código, enquanto o @eslint/js fornece configurações de regras, como a configuração recomendada que eu utilizo.

Para ter certeza de que era um erro, fui reproduzi-lo localmente. Usei uma worktree com a branch desse PR para investigar sem mexer na minha pasta principal. Até então, as verificações do CI tinham passado. Mas, ao simular a resolução dos pacotes com este comando, o erro apareceu:

npm install --package-lock-only --ignore-scripts --dry-run --no-audit --no-fund

O comando não instala os pacotes nem grava as alterações propostas no lockfile. Pode consultar o registro do npm e gerar logs ou cache, mas permite testar a resolução sem aplicar a atualização.

Agora sim apareceu o ERESOLVE, apontando a incompatibilidade. Na comparação local, essa verificação passou antes da mudança e falhou com os arquivos do PR.

Provavelmente você iria se perguntar: “Por que um pacote tão utilizado pela comunidade JS iria cometer um erro desse? Ninguém revisou essa joça de comparar a versão dos dois pacotes antes de colocar dentro da release não?”

Foi aí que precisei separar as coisas. O pacote tinha declarado a compatibilidade dele. A proposta de atualização do meu projeto é que não atendia ao requisito.

E aquele optional: true? Ele declara o ESLint como opcional (só voltar lá no exemplo do código que você vai ver). Para ter o @eslint/js instalado, não é obrigatório ter o ESLint também. Mas, se ele estiver instalado, a versão precisa ser compatível.

Você não é obrigado a ter um controle para jogar um jogo que também aceita teclado, mas precisa ter um controle compatível caso opte por utilizar um.

Logo, o erro já estava claro.

O meu projeto utiliza tanto o @eslint/js quanto o eslint. A versão 10.0.1 do @eslint/js exige ESLint na faixa ^10.0.0 quando ele está instalado, mas o meu projeto continuava na série 9.

Mas por que os testes não capturaram esse erro?

O CI usava npm ci, que instala as versões registradas no lockfile. Naquela execução, a instalação, o lint, os testes e o build passaram. Já a verificação adicional de resolução encontrou o conflito.

Isso não quer dizer que o npm ci nunca encontre incompatibilidades, nem que o npm install saia atualizando tudo. Foi o comportamento observado nesse caso. Quando as versões do lockfile atendem ao package.json, o npm install normalmente as reutiliza; quando não atendem, ele precisa resolver novas versões dentro das faixas permitidas.

No meu projeto, ele não poderia simplesmente escolher ESLint 10 para resolver o problema, porque o ^9.39.3 ainda limitava a escolha à série 9. Foi justamente esse conflito que a simulação apontou.

Decidi então adicionar a verificação ao workflow:

- name: Validate dependency resolution  run: npm install --package-lock-only --ignore-scripts --dry-run --no-audit --no-fund

Rodei o CI novamente no PR e dessa vez a etapa falhou com o mesmo erro. O problema que antes passava despercebido agora era capturado. Isso não transforma o comando numa garantia contra toda incompatibilidade, mas ele passou a verificar um cenário que estava faltando no meu CI.

De quem foi a culpa?

Pode-se dizer que o erro estava na proposta do Dependabot: uma atualização incompleta. Ele manteve o ESLint na série 9 e criou uma combinação incompatível.

Por outro lado, isso pode ser uma limitação da atualização individual ou da configuração utilizada. Só esse resultado não prova um bug no Dependabot. O que ficou claro é que o PR automático também precisava de revisão.

A solução

Eu tinha duas opções para seguir: manter os dois pacotes na série 9 e fechar esse PR, ou tentar migrar também o ESLint e conferir a compatibilidade dos plugins.

Optei por tentar atualizar o ESLint para a versão 10, mas aí descobri que o eslint-plugin-react 7.37.5 só declarava suporte até a série 9 do ESLint 🤡. Essa já era a versão marcada como latest no npm. Não adiantava simplesmente mandar atualizar tudo.

Acabei mantendo os dois pacotes na série 9 mesmo. Para seguir com a migração, teria que esperar o suporte do plugin ou avaliar uma alternativa, o que já aumentaria o escopo dessa atualização.

Sei que para alguns isso vai ser algo básico, mas acredito que hoje em dia até o básico não é falado por ser superestimado. Infelizmente nunca fui uma pessoa que aprende bem com leitura de artigos e tutoriais dos outros, por isso decidi documentar alguns problemas que encaro no dia a dia para poder fixar melhor.

O Thariq, membro da equipe, postou no X:

We're adding support for AGENTS.md to Claude Code.

Starting today in version 2.1.277, if there is no CLAUDE.md in a folder, Claude will check for and use AGENTS.md.

You can toggle this behavior in /config.

— Thariq (@trq212) September 18, 2026

O suporte vai ser oferecido por meio da nova funcionalidade de mods, que vai permitir customizar o Claude Code. O suporte ao AGENTS.md será um mod nativo.

Talvez você já tenha ouvido falar em “scaling laws”: a ideia de que modelos maiores (com mais parâmetros) tendem a ser mais inteligentes. Ou seja, quanto maior o “cérebro” (rede neural) da IA, melhor.

Mas isso é mesmo verdade ou já estamos num platô? O custo computacional de modelos de IA maiores justifica o ganho de inteligência obtido, ou estamos num cenário de “diminishing returns”? Fable e Astra são modelos maiores (e mais caros) que seus antecessores… mas quão mais inteligentes eles são?

Para entender, vamos começar com um exemplo simples.

Por mais “overkill” que pareça, podemos treinar uma rede neural para aprender a somar dois números. Para isso, precisamos de um conjunto de dados com exemplos do que é uma soma correta:

2 + 2 = 4

14 + 10 = 24

234 + 11 = 245

47282 + 1233 = 48515

…e assim por diante. Idealmente, essa lista de exemplos deve ser bem grande.

Agora, uma rede neural que aprende a somar dois números olhando pra essa lista poderia aprender a fazer isso de duas formas:

• Aprender o real conceito de soma;

• Criar internamente uma “tabela” que mapeia todos os valores de entrada que ela viu na lista pro resultado que ela também viu na lista. Seria o equivalente a “decorar” a lista.

Se o modelo aprender a decorar a lista, quando pedirmos para ele somar dois números que não estavam na lista usada no treinamento, ele provavelmente vai somar errado. Aqui, diz-se que aconteceu um “overfitting”: o modelo ficou muito bom em aprender os dados que ele viu no treinamento, mas não consegue “generalizar” o conhecimento para fora daqueles dados.

Agora, qual o tamanho ideal de uma rede neural (quantos parâmetros) para ela realmente aprender a somar dois números, sem decorar? Quão grande precisa ser o “cérebro” dessa IA?

Aqui, observa-se um comportamento interessante: a resposta não é “quanto maior, melhor”. Existe um tamanho ideal para a rede. Depois desse tamanho ideal, se apenas adicionarmos mais parâmetros, o desempenho para generalização fica pior!

E o motivo intuitivo para isso é mais ou menos assim: quanto maior for a rede, mais “espaço dentro do cérebro dela” ela tem para aprender a abordagem que nós não queremos, que é decorar a lista do treinamento.

Em outras palavras, forçando a rede a ser menor, menos chance ela tem de aprender a abordagem “burra” (decorar) e mais ela é forçada a achar a solução inteligente e genérica para o problema.

A teoria é clara: o modelo mais simples é o melhor generalizador (grave essa frase).

É por esse motivo que, se antes de 2019 você perguntasse para um pesquisador de IA “Você acha que treinar uma rede neural gigante, com trilhões de parâmetros, usando todo o texto disponível na internet, é uma boa ideia para termos uma IA superinteligente?”, provavelmente a resposta seria: “Não! Esse modelo vai com certeza aprender os dados de treinamento, mas não será inteligente. Será apenas um papagaio estatístico, vítima de um inevitável overfitting”.

Porém, em 2019, um novo artigo https://arxiv.org/abs/1812.11118 demonstrou algo interessante: nos experimentos, os autores seguiram aumentando o tamanho da rede neural e, inicialmente, a rede ficou, sim, pior para generalizar com dados não vistos no treinamento. Contudo, ao seguir aumentando o número de parâmetros, eles observaram que a rede voltou a ter resultados melhores… até o ponto de superar as capacidades de generalização da rede mais simples!

Esse resultado foi surpreendente e abriu uma nova avenida para melhorar a IA: bastaria fazer modelos maiores!

Entretanto, esse resultado também contrariava tudo que se sabia de estatística e redes neurais. A verdade teórica era: “o modelo mais simples é o melhor generalizador”. Não se entendia o mecanismo que fazia com que isso não fosse verdade. O que estava acontecendo? Por que modelos maiores estão generalizando melhor?

Por volta da mesma época surgiu outro artigo https://arxiv.org/abs/1803.03635 que observou que, em grandes redes neurais, a vasta maioria dos parâmetros da rede são, na verdade, inúteis… simplesmente não são utilizados! O artigo mostrou que era possível encontrar, dentro das redes estudadas, sub-redes muito menores que, quando treinadas com os valores iniciais certos, atingiam um desempenho parecido com o da rede maior.

Para fazer a conexão entre esses dois artigos e entender o que está acontecendo, é preciso entender um pouco de como essas redes são treinadas.

Uma rede começa com valores aleatórios nos seus parâmetros e tenta-se gradualmente, ao longo do treinamento, ir mudando esses valores para fazer a rede gerar melhores resultados para o conjunto de dados de treinamento. É a técnica chamada de “gradiente descendente” (e é muito mais fácil entender isso com imagens).

Mas o importante é notar o seguinte: na técnica de gradiente descendente, os valores iniciais (aleatórios) dos parâmetros importam! Alguns conjuntos iniciais de valores podem fazer o treinamento conseguir chegar num bom resultado. Já outros podem fazer a rede ficar presa em um “ótimo local”, sem nunca poder testar possibilidades melhores.

Agora a sacada: o que se está fazendo ao treinar uma grande rede neural é, na verdade, treinar várias redes menores em paralelo. A hipótese é que redes maiores ofereçam mais chances de encontrar uma dessas sub-redes com uma inicialização muito boa (que generalizam melhor). Esse é o link entre os dois artigos anteriores.

Então, o que se acreditava antes do artigo de 2019 continua sendo verdade: “o modelo mais simples é o melhor generalizador”. Redes maiores parecem performar melhor, mas na verdade é uma otimização de treinamento… no final do treinamento, a maioria dos parâmetros será inútil, mas é mais provável que uma sub-rede eficiente tenha surgido dentro dessa rede maior.

Então, fica a pergunta: vamos conseguir atingir inteligência de nível humano (AGI) ou além (ASI) apenas aumentando o tamanho de LLMs e melhorando nossas técnicas de treinamento?

Não sou especialista da área, apenas curioso. E esse texto foi inteiramente baseado neste vídeo https://youtu.be/UKcWu1l_UNw?is=QDbh9SaRy-HA90bf que, se você leu até aqui, recomendo fortemente assistir.

O autor do vídeo acredita que, apenas aumentando o tamanho das LLMs, não parece ser possível chegar à AGI. E o motivo é porque o ganho em inteligência obtido apenas tornando os modelos atuais maiores é modesto, e o aumento de computação necessária é proibitivamente custoso. Contudo, o autor também fala que acredita que LLMs são, sim, capazes de produzir inteligência de nível humano. Mesmo que a capacidade de escalar o tamanho desses modelos atinja um platô, na opinião dele, não existem motivos para acreditar que melhores algoritmos de treinamento, ou novas arquiteturas de rede neural, não sejam capazes de atingir inteligência humana apenas prevendo a próxima palavra (token) quando treinados com uma quantidade infinita de texto. Em teoria e no limite, isso parece um caminho possível para a AGI.

Agora, se você quiser um papo bem mais inicial do que esse, para ser introduzido no mundo de redes neurais, sugiro assistir ao meu vídeo: https://youtu.be/Dlx_VuyXrBg?is=KwUCFy0NcnbTbfy1

Obrigado por ler até aqui! Deixe suas dúvidas e contribuições nos comentários.