Olá, pessoal do TabNews! Sophia aqui com mais um post!

Há pouco tempo compartilhei aqui a minha experiência desenvolvendo a libft, minha primeira biblioteca própria em C na 42 São Paulo. Hoje estou de volta para contar como foi encarar o segundo grande desafio dessa jornada de Cadete: recriar do zero uma das funções mais utilizadas, famosas e misteriosas do início do aprendizado de baixo nível: a printf().

O projeto se chama ft_printf e, seguindo a filosofia da escola, a regra de ouro se mantém: não podemos utilizar funções prontas da biblioteca padrão (além da permissão estrita da write e da própria libft que criamos anteriormente). Tudo precisa ser construído na unha!

O que é a ft_printf?

O objetivo principal parece simples: analisar uma string de formatação (o primeiro argumento) e imprimir os caracteres na saída padrão (stdout). O desafio real começa quando encontramos o caractere %, que funciona como uma flag avisando que precisamos capturar um argumento variável e formatá-lo corretamente para exibir na tela.

Pelas regras do projeto, precisei implementar obrigatoriamente o suporte para as seguintes conversões:

• %c para um único caractere
• %s para strings de caracteres
• %p para o endereço de memória de um ponteiro (em formato hexadecimal)
• %d e %i para inteiros com sinal em base decimal
• %u para inteiros sem sinal em base decimal
• %x para números hexadecimais em letras minúsculas (base 16)
• %X para números hexadecimais em letras maiúsculas (base 16)
• %% para imprimir o próprio caractere de porcentagem

Além disso, há um detalhe crucial: a função precisa retornar exatamente o mesmo valor inteiro que a original, que representa a contagem precisa de todos os caracteres impressos. Se houver um desvio de um único byte sequer nos testes, a Moulinette (o sistema automático de correção) zera o projeto sem dó 😬.

Variadic Functions: o grande...

Quando bati o olho no protótipo da função pela primeira vez, confesso que deu um nó na cabeça:

int ft_printf(const char *format, ...);

O que diabos significam aquelas reticências no final? 🤯 kkkk

Foi aí que descobri e precisei dominar o conceito de Funções Variádicas. Em C, para criar uma função capaz de receber uma quantidade n-ésima e dinâmica de argumentos passados pelo usuário, precisamos recorrer à biblioteca <stdarg.h> e suas macros:

1. va_list: um tipo de dado especial que serve para rastrear e armazenar os argumentos adicionais
2. va_start: inicializa a lista de argumentos, apontando para o primeiro elemento logo após o argumento fixo (format)
3. va_arg: resgata o próximo argumento da lista, exigindo que você informe especificamente o tipo esperado (ex.: int, char *)
4. va_end: limpa a memória e finaliza o acesso à lista de argumentos

Entender como o computador navega pela memória empilhando esses argumentos sem que eles tenham um nome fixo foi um baita aprendizado de como as coisas funcionam por baixo dos panos.

Os maiores desafios da implementação

Se na libft o maior vilão foi entender o gerenciamento de memória bruta com ponteiros e alocações, na ft_printf a dor de cabeça foi com a arquitetura do código e a precisão do fluxo.

• A saga dos Hexadecimais e Ponteiros (%p): Converter um número inteiro longo para hexadecimal exige uma lógica de divisões sucessivas pela base 16. No entanto, o tratamento do %p exige atenção redobrada: ele precisa injetar o prefixo 0x na frente e lidar corretamente com o caso de ponteiros nulos (NULL), exibindo a string (nil) de forma idêntica ao comportamento padrão do sistema operacional.

• A Meticulosa Contagem de Caracteres: Como o retorno da função principal depende da soma exata de tudo o que foi escrito, cada pequena função auxiliar (seja imprimindo um número negativo enorme ou uma string vazia) precisa retornar a quantidade exata de caracteres que enviou para o terminal. Uma falha de lógica em um único if e o retorno final quebrava.
  Desta vez, o papel e a caneta voltaram a ser meus melhores amigos: desenhar o fluxo do parser (mapeando a leitura caractere por caractere e os desvios de fluxo ao encontrar o %) me poupou horas valiosas de depuração.

Jump Tables: apenas deixe isso simples

Eu tentei bancar a esperta e economizar nos if-else, então fui em busca de alternativas. Acabei encontrando sobre "Jump Tables", que é basicamente chamar funções em uma tabela de array. O problema foi essas linhas de código aqui:

while (i < 256){    ctx->table[i] = NULL;    i++;}

Esse código serve para definir toda a minha tabela para NULL até 256, evitando lixos da memória. A questão é que, a cada chamada da minha ft_printf, esse while fará essa limpeza várias e várias vezes, sendo bem mal performatico. Eu fiz essa correção na minha "mega-libft", onde concentrei o ft_printf e a get_next_line, que irei falar sobre posteriormente. Lá apenas usei o básico e simples if-else.

O Projeto

Para quem tiver curiosidade em conferir como estruturei as funções, organizei os arquivos auxiliares e configurei o Makefile para gerar a biblioteca, o repositório completo está público no meu GitHub:
🔗 https://github.com/ciproterona/42_ft_printf

Vale destacar que eu não fiz o bônus, que incluí precisão de floats (%.2f). Pretendo fazê-la mais a frente apenas pelo aprendizado, pois não iremos usar essa funcionalidade do printf, então não vi necessidade imediata de implementá-la.

Nota sobre contribuições: Por se tratar de um projeto puramente acadêmico e individual da grade da 42, não aceito merges de Pull Requests para alterar o escopo principal. Porém, sinta-se totalmente livre para abrir uma Issue ou PR educacional para propor melhorias de performance, discutir conceitos ou apontar alguma otimização na lógica! 👐🏼

Superar o desafio da printf me trouxe uma confiança legal para continuar. Ver uma função tão clássica e robusta rodando perfeitamente a partir de linhas de código que eu mesma escrevi é uma sensação indescritível.

Adoraria saber de vocês: Como foi o primeiro contato de vocês lidando com funções variádicas ou manipulação de strings em baixo nível? Para quem já fez esse tipo de projeto, vocês costumam estruturar o parser com grandes blocos de if/else ou preferem seguir minha loucura e usar tabelas de ponteiros para funções (array of function pointers)?

Estarei trazendo atualizações aqui no TabNews para os próximos passos da jornada. Até mais! ＼(^-^)／

Eu estava cansado de colar o mesmo contexto em janelas de chat. Toda conversa nova com IA começava do zero: colava a política de troca, explicava o tom de resposta, e na semana seguinte tudo de novo. Quando vi uma plataforma que se descreve como "Drive-based", ou seja, agentes que trabalham a partir de arquivos de verdade em vez de memória de conversa, resolvi testar por uma semana e anotar o que aconteceu.

O modelo mental: uma empresa, não um chat

A primeira coisa que ajuda a entender a plataforma é a analogia que a própria documentação usa. Um Space é a empresa. Um Agent é um funcionário de IA. O Drive é o armário de arquivos. Uma Session é a sala de reunião de cada assunto. Uma Skill é um procedimento operacional que se repete. E um Channel (Slack, WhatsApp, Telegram, Discord, Teams e afins) é a linha telefônica por onde gente de fora fala com o funcionário.

Parece marketing, mas a analogia segura bem na prática. Você não fica "conversando com uma IA"; você contrata um funcionário, entrega documentos para ele e abre reuniões separadas por assunto. O detalhe importante: o canal de chat é só a porta de entrada. Nada do que passa por ali vira conhecimento permanente por conta própria. Conhecimento mora em arquivo.

Montando o primeiro agente

O cadastro não pede cartão de crédito e o plano Free custa $0, então dá para testar sem compromisso. Criei um agente com o papel de suporte interno: bastou dar um nome, descrever a função e escolher o modelo base.

A parte que interessa vem depois. Subi arquivos reais para o Drive do agente: um FAQ em Markdown e uma política de trocas em PDF, entre outros documentos de suporte. A partir daí, quando pergunto algo, o agente responde com base nesses arquivos, não com base no que "lembra" da conversa. Isso muda a natureza do erro também. Quando a resposta veio errada, o motivo era rastreável: um documento desatualizado que eu tinha subido. Corrigi o arquivo e a resposta corrigiu junto.

Esse ciclo, de tratar a base de arquivos como fonte de verdade e editar arquivos em vez de re-explicar no chat, foi para mim a maior diferença em relação a qualquer assistente de conversa.

O sandbox: Terminal e Git à vista

Cada agente roda em um sandbox na nuvem, e o Agent Workspace expõe abas para olhar lá dentro. A aba Terminal abre um shell real do ambiente do agente. A aba Git mostra commits, diffs e branches do que ele está mexendo. Tem ainda aba de Browser para acompanhar automação web e até acesso via VS Code Remote SSH, que eu não cheguei a explorar a fundo.

Para quem é dev, isso resolve uma desconfiança antiga: a de não saber o que o agente está executando. Dá para auditar o histórico de comandos e reverter pelo Git se algo sair torto. Um aviso prático: Browser, Terminal e Git não entram no plano Free. Para testar essa parte eu passei o agente para o Plus, que custa 20 por agente por mês (o Pro custa 100).

Conectando o WhatsApp

Aqui está o motivo de eu achar a plataforma particularmente relevante para o contexto brasileiro. A conexão com WhatsApp funciona por QR code, no mesmo esquema do WhatsApp Web. Não precisa de conta Meta Business nem de aprovação de template. Escaneei o código com um número de teste e em poucos minutos o agente estava respondendo mensagens.

Dois pontos merecem atenção. Primeiro, o Buda envia e recebe mensagens como aquela conta, então a recomendação da documentação é usar um número dedicado, não o seu pessoal (imagine o agente respondendo o grupo da família). Segundo, o isolamento de sessão: cada número de telefone tem a sua própria Session no DM, e cada grupo tem a sua. Isso significa que o histórico do cliente A não vaza na conversa do cliente B, o que para atendimento é requisito básico, não recurso.

Skills: transformando rotina em procedimento

Depois que o agente estava respondendo bem, percebi que algumas tarefas se repetiam do mesmo jeito toda semana. A plataforma trata isso com o conceito de Skill, que é basicamente um SOP reutilizável: um procedimento que o agente sabe executar sob demanda, em vez de você descrever os passos a cada pedido. Existe um Marketplace com Skills prontas, e as da comunidade são de código aberto, então dá para inspecionar o que uma Skill faz antes de instalar. Achei uma decisão de design acertada, porque instalar capacidade nova em um agente que mexe nos seus arquivos, sem poder auditar o que ela executa, seria pedir problema.

A regra que passei a usar para organizar tudo: se a informação vale só para a tarefa atual, fica na Session; se a próxima conversa vai precisar dela, vira arquivo no Drive; se o fluxo inteiro se repete, vira Skill. Demorei alguns dias para internalizar essa hierarquia. No começo joguei coisa demais no Drive e a qualidade da busca caiu junto. Menos arquivos, melhor escolhidos, funcionam melhor.

O que funcionou bem

Depois de uma semana, o maior ganho foi de auditabilidade. As respostas saíam ancoradas nos arquivos que eu controlava, então revisar a base era revisar o agente. A visibilidade do sandbox também pesou: eu conseguia abrir o Terminal e o Git, ver o estado real do trabalho e delegar tarefas mais longas sem aquela sensação de caixa-preta. Some a isso as sessões separadas por cliente, que evitaram contaminação de contexto no atendimento.

Outro detalhe que gostei: o agente continua rodando na nuvem. Não é um processo preso à minha máquina ou à aba do navegador. Fechei tudo, voltei horas depois e o trabalho tinha andado.

O que exige cuidado

Nem tudo é plug and play, e alguns cuidados são de responsabilidade sua, não da ferramenta.

Agente de atendimento deve ser configurado como somente leitura, tanto nas instruções quanto nas permissões de ferramentas. As ferramentas do workspace conseguem criar e editar arquivos, e você não quer isso acontecendo por engano em cima da sua base de conhecimento durante um atendimento.

Separe arquivos públicos de internos. Se o Drive do agente de suporte tem a planilha de custos junto com o FAQ, mais cedo ou mais tarde algum trecho aparece onde não devia.

Defina escalonamento humano desde o início. Reembolso e qualquer assunto jurídico devem ir para uma pessoa. A própria documentação recomenda começar com testes internos e conteúdo não sensível antes de expor o agente a cliente real, e concordo.

Por fim, sobre custos: o consumo é medido em créditos, uma unidade composta que cobre chamadas de modelo e APIs de terceiros e que não equivale a tokens. Há créditos diários que resetam, créditos mensais do plano e saldo comprado. Quando tudo acaba, as funções de IA pausam até renovar. Vale acompanhar o consumo na primeira semana para calibrar expectativa.

Vale o teste?

Para mim, valeu, com uma ressalva de escopo: o ganho aparece quando existe uma base de documentos que muda menos que as conversas. Se o seu caso é pergunta avulsa, um chat comum resolve. Se é atendimento, operação ou qualquer fluxo que se repete sobre os mesmos arquivos, a arquitetura de Drive faz sentido.

Minha sugestão concreta para quem for testar: comece no plano Free com um único agente, suba só os cinco ou dez documentos que respondem as perguntas mais frequentes do seu contexto, e conecte o WhatsApp com um número descartável antes de pensar em usar um número de produção. A parte difícil não é a ferramenta; é decidir quais arquivos merecem ser a fonte de verdade.

Tô estruturando meus projetos e travei no combo: PIX Automático (recorrência) + emissão de NFS-e automática + LGPD. Stripe resolve cartão, mas cliente BR quer PIX, e emitir nota fiscal todo mês na mão é inviável.

Vocês que vendem SaaS pra cliente brasileiro:

1. Integraram PSP na unha (Asaas / Efí / Mercado Pago)? Quanto tempo levou a integração do PIX Automático?
2. Emitem NFS-e como? Automatizaram ou é manual no Emissor Nacional?
3. Ou vendem só pra fora (Stripe e fim) justamente pra fugir dessa burocracia?

Quero entender como a comunidade tá resolvendo isso na prática hoje.

Olá, pessoal!

Quero compartilhar com vocês o Wave Server Builder, um projeto open-source que desenvolvi para automatizar completamente a criação e a estruturação de servidores no Discord usando Inteligência Artificial.

A ideia nasceu da dor de cabeça que é configurar categorias, canais de texto/voz, cargos, permissões granulares e regras toda vez que precisamos iniciar uma nova comunidade.

Em vez de usar templates fixos, o bot usa o Google Gemini para entender o tema do servidor e planejar uma estrutura 100% única e personalizada.

Como funciona por trás dos panos?
Você digita /criar-servidor e um modal interativo se abre no Discord.

Você descreve o objetivo do servidor (ex: "Um servidor para um grupo de estudos de Python" ou "Uma comunidade de Valorant").

A IA analisa a descrição e planeja o tema, os canais ideais, cargos específicos e regras.

O bot assume o controle: deleta a estrutura antiga e constrói tudo automaticamente.

Principais Recursos Técnicos
Planejamento por IA: Integração com o modelo Gemini para criar estruturas adaptativas e inteligentes.

Hierarquia de Segurança Rígida: Criação automática de 11 níveis de cargos (de Visitante a Owner) com permissões progressivas e canais de logs privados para a staff.

Geração Dinâmica de Ícones: Utiliza a biblioteca Pillow para gerar um ícone de servidor em alta resolução (512x512) com as iniciais da comunidade e gradientes customizados (Modern, Classic, Gamer ou Minimalist).

Multilinguismo: A IA consegue gerar o servidor em 7 idiomas diferentes (Português, Inglês, Espanhol, Japonês, etc.).

Stack Tecnológica
Linguagem: Python 3.10+

Framework principal: discord.py v2.4+

SDK de IA: google-genai v1.0+

Manipulação de Imagem: Pillow

Código Aberto (GitHub)
O projeto está totalmente documentado, com passo a passo de configuração do ambiente (.env) e instalação das dependências. Se você quiser rodar no seu servidor, inspecionar o código ou contribuir, o repositório está aqui:

https://github.com/gatosmias1/wave-server-builder

Está em fase beta, então a IA pode cometer erros — como esquecer de definir o administrador como privado, e assim por diante.

Se você quiser o README em português do Brasil, aqui está o link:
https://github.com/gatosmias1/wave-server-builder/blob/main/README.pt-BR.md

Converti todos os arquivos em um único arquivo. Ele está em release.

estou tentando buildar APENAS O CLIENTE do programa desse repositorio https://github.com/arnoson/monaco-lua-example (creditos ao criador arnoson).
Porem ao buildar com npm run build, que roda vite por traz, ele parece buildar sem erros mas ao abrir um servidor para acessar os arquivos criados a tela fica branca e no console mostra um erro: marked.js:2984 Uncaught TypeError: Cannot read properties of undefined (reading 'Parser')
at index.1ae95693.js:1:23
at main.ts:57:1
(anonymous) @ index.1ae95693.js:1
(anonymous) @ main.ts:57

tentei de tudo, pedi ajuda pra IA mas não consegui buildar o projeto, mesmo que ele funcione com npm run dev (mas preciso buildar pra usar os arquivos sem precisar de vite)

Fala, pessoal! Tudo bem?

Acompanhei de perto a evolução do nosso ecossistema de tecnologia e, conversando com alguns colegas da área, percebi que, além dos desafios técnicos universais (prazo limitado, refatoração de código legado, etc.), quem desenvolve no Brasil enfrenta algumas dores muito específicas do nosso cenário.

Quero mapear esses problemas reais para entender onde nós, como comunidade ou criadores de ferramentas, podemos atuar para criar soluções práticas (seja um código aberto, um clichê nichado ou uma automação).

Olhando para o cenário atual, vejo grandes áreas que costumam dar dor de cabeça:

Barreira do Mercado Internacional: Desenvolvedores com um nível técnico absurdo, mas que enfrentam dificuldades para destravar o inglês de negócios, a comunicação assíncrona ou a dinâmica cultural em entrevistas para a gringa.

Queria ouvir de vocês que estão no campo de batalha diariamente:

Queria ouvir de vocês que estão no campo de batalha diariamente:

Qual é o problema técnico ou operacional que mais toma o seu tempo hoje e que você gostaria que fosse resolvido com uma ferramenta ou automação?

Onde o calo aperta mais no seu fluxo de trabalho atual

Bora trocar essa ideia nos comentários! Se você tiver exemplos reais de "gargalos" que você enfrentou na empresa de vocês, vai ajudar muito a guiar os próximos passos de um projeto focado em resolver essas dores.

Sinta-se à vontade para me enviar um e-mail. Vou adorar receber seu feedback. https://cjdigital-portfolio.vercel.app/

Estou construindo a Stalo, um radar de tendências onde a pessoa escolhe setores de tecnologia, o produto cruza notícias e devolve oportunidades de negócio. O problema que percebi cedo é o uso naturalmente esporádico. A pessoa entra, faz uma análise, gosta... e não tem motivo nenhum pra voltar na semana seguinte. O produto some da cabeça dela.

O que estou testando agora é uma newsletter semanal por setor que a pessoa escolher. Toda segunda às 9h chega um boletim com o que aconteceu nos setores que a pessoa escolheu, no Brasil e lá fora, com insights conectando as notícias (o mesmo tipo de leitura que o produto faz).

A aposta é que o email vira o "lembrete semanal" do produto. A pessoa lê, um insight desperta interesse, ela clica e volta pra plataforma pra aprofundar.

Ainda não sei se funciona. Vou medir taxa de abertura e quantos cliques do email viram sessão.

O que vocês acham sobre isso? Como vocês seguram usuário em produto de uso esporádico?

Fala pessoal! Meu primeiro post aki no Tabnews.

Nos últimos meses venho construindo a NoctralSpy, um projeto pessoal que nasceu de uma dor e algo que ja fazia todos os dias para mim e queria transformar em um produto.

Sempre que eu queria criar um novo SaaS, passava horas tentando responder perguntas como:

Esse mercado realmente tem gente pagando?
Como esse produto consegue clientes?
Eles anunciam? Onde?
Quanto faturam aproximadamente?

No fim eu acabava com 15 abas abertas: Bibliotea de Anuncios Meta, Product Hunt, Google, Trust MRR, posts no X, e mesmo assim faltava algo porque depois da pesquisa tudo sumia e ficava apenas na minha cabeca os dados.

Então resolvi juntar tudo em um só lugar.

A Noctral reúne informações de centenas de SaaS, como:

→ estimativa de receita (MRR)

→ anúncios que estão rodando

→ nicho e categoria

A ideia não é gerar ideias por IA, e sim mostrar produtos que já existem e que têm indícios de validação, para facilitar a pesquisa de quem quer construir um SaaS.

Você entra encontra ideias de Saas faturando modela para seus negocios e analisa os anuncios, onboarding tudo.

O projeto ainda está no começo e estou buscando feedback de quem realmente cria produtos.

Queria saber principalmente:

Essas informações seriam úteis para vocês?
O que mais vocês gostariam de ver antes de decidir entrar em um mercado?

Toda crítica ou sugestão é muito bem-vinda. Ainda estou iterando bastante no produto e esse tipo de feedback faz bastante diferença.

Estou fazendo build in public no X @leonardoperin8

Você tem o poder de ajudar a descobrir a cura de doenças.
O Folding@home transforma o poder ocioso do seu computador em um supercomputador global focado em pesquisa biomédica.

Em 2026, meu pai foi diagnosticado com a Doença de Parkinson. Desde então, resolvi estudar a fundo sobre essa condição que afeta o sistema nervoso central e impacta a qualidade de vida de milhares de pessoas.

Realizando algumas pesquisas, descobri o projeto Folding@home, coordenado pelo Dr. Greg Bowman. Há mais de 25 anos eles fazem ciência de verdade através de computação distribuída (Distributed Computing). Na prática, cada CPU e GPU doada ao redor do mundo se junta para impulsionar simulações moleculares complexas. Isso permite que problemas científicos gigantescos sejam resolvidos por milhares de pessoas trabalhando em paralelo.

Como você pode ajudar? É simples: você não precisa ser um cientista da área da saúde. Você só precisa ser um cientista cidadão, compartilhando ou doando o poder de processamento do seu hardware ocioso em prol da ciência.

Atualmente, meu pai está em um projeto no Hospital das Clínicas que utiliza tecnologias que só existem hoje por conta desse tipo de trabalho silencioso, "sem holofotes", mas que é gigante nos bastidores.

Por isso, convido você a conhecer o projeto Folding@home. Seria muito grato se você pudesse colaborar doando o tempo ocioso do seu hardware para projetos que ajudam a SALVAR VIDAS.

Se quiser entrar direto no nosso time para pontuarmos juntos, configurei este link: ColabDeveloper - Team

Meu pai agradece de coração, e eu sou muito grato por fazer parte desse trabalho voluntário.

Transcrição virou commodity rápido demais para a maioria das pessoas perceber o que mudou. Em 2020 era um serviço caro e lento. Hoje você joga um arquivo numa ferramenta e recebe o texto em minutos. Vale entender o que acontece nesse meio, seja porque você quer construir algo em cima disso, seja por curiosidade de engenharia.

Não é um modelo só fazendo mágica. São várias etapas, cada uma resolvendo um problema que as outras não resolvem.

O áudio vira uma imagem
A primeira coisa que acontece é o áudio deixar de ser onda e virar espectrograma. Os modelos da família Whisper, que estão por trás de boa parte das ferramentas atuais, reamostram tudo para 16 kHz e calculam um espectrograma log-Mel de 80 canais, usando janelas de 25 ms com passo de 10 ms.

Traduzindo: o áudio é fatiado em quadros curtos e sobrepostos, e para cada quadro se mede quanta energia existe em cada uma das 80 faixas de frequência, numa escala que aproxima como o ouvido humano pesa os tons. O resultado é um tensor parecido com uma imagem. Tratar som como imagem é boa parte do motivo de as arquiteturas de visão e os transformers funcionarem tão bem aqui.

A janela de 30 segundos
O Whisper processa o áudio em blocos de 30 segundos. É uma decisão de arquitetura, não uma preferência. Clipes menores são preenchidos até 30 segundos; arquivos maiores são divididos e costurados depois.

Esse detalhe explica uma classe de bugs. Se um corte cair no meio de uma palavra, ou no meio de uma frase, o modelo pode perder o fio na emenda. Por isso sistemas de produção colocam antes uma etapa de detecção de atividade de voz, para que os cortes aconteçam nas pausas naturais. Se você já viu uma frase repetida ou uma palavra sumindo num timestamp redondo demais, a divisão ingênua de 30 segundos é a principal suspeita.

Reconhecer é diferente de saber quem falou
Aqui mora uma confusão comum. Transcrever as palavras certas e saber quem disse cada palavra são dois problemas separados. O reconhecimento cuida do primeiro. A diarização, que agrupa os trechos por características de voz, cuida do segundo, e roda em paralelo.

A diarização é a etapa menos resolvida do campo. Quando as pessoas falam em turnos limpos, os sistemas atuais rotulam bem. Quando três pessoas falam ao mesmo tempo, todo sistema no mercado degrada. Quem é honesto diz isso na cara. Uma transcrição pode estar 95% correta nas palavras e ainda assim atribuir metade das falas ao interlocutor errado.

A pontuação também é inventada
A saída bruta do reconhecimento é um fluxo em caixa baixa e sem pontuação, tecnicamente correto e praticamente ilegível. Uma etapa de restauração adiciona limites de frase, maiúsculas e pontuação. Você quase nunca repara nessa etapa, o que é exatamente o objetivo. Só nota quando ela falta. E faz sentido: você também não ouve vírgulas, você as infere.

Do modelo ao produto
O Whisper cru te entrega uma transcrição. Transformar isso em algo que um não programador quer envolve etapas que o modelo base não faz: limpeza de pontuação e capitalização, diarização e uma camada de modelo de linguagem que resume e estrutura.

Se você prefere consumir a cadeia pronta em vez de montar cada peça, a ferramenta de áudio para texto da Vomo embrulha tudo isso: você sobe um arquivo ou cola um link e recebe uma transcrição com falantes identificados e 95% de precisão, mais um resumo, capítulos e itens de ação gerados por cima, com a opção de perguntar à transcrição em linguagem natural. Serve como referência do que "pronto" significa, mesmo que você acabe construindo o seu.

A arquitetura base está estável e bem compreendida. Quase toda a engenharia interessante de 2026 migrou para as camadas ao redor: reduzir a latência rumo ao tempo real e injetar vocabulário de domínio para o modelo parar de estropiar nomes próprios. O reconhecimento está praticamente resolvido. Tudo que vem em cima dele ainda está em aberto.

Semana passada comentei que o @TabNewsDigest não rolou no sábado mas essa semana ele não desapontou. Confira o último post aqui ó: 🔥 O Melhor da Semana no TabNews #27.

E com isso fiz a atualização dos stories no Tabs. Segue alguns deles aqui:

1	2	3

Não sei se estou feliz com esse modelo de imagem. Tá vendo que eles acabam ficando com a mesma cara? Vou testar prompts diferentes depois. Mas tá bom.

Ah, dei um tapa na loja também mas ficou um negócio desalinhado lá. Vou arrumar.

Sou dev solo e leitor de notícia de games desde sempre. Nos últimos anos fui perdendo a paciência: manchete caça-clique, rumor vendido como fato, a mesma notícia requentada em 10 sites e um monte de opinião no meio do factual.

Então construí o Notering: um app de notícias de games minimalista com algumas regras fixas de redação. Toda matéria cruza mais de uma fonte e linka todas elas. O que é rumor recebe um selo laranja de RUMOR, separado do que é fato confirmado. O texto é sempre neutro: zero adjetivo de torcida, zero clickbait.

No caminho o app acabou virando mais que notícia: dá pra seguir jogos e franquias inteiras (Call of Duty, Zelda...) e receber aviso de lançamento, alerta de queda de preço e jogos que ficaram grátis (Epic, Steam etc.).

Stack: Flutter no app, Supabase (Postgres + Auth + Edge Functions) no backend, Netlify no site. Tudo no free tier ou perto disso.

Está na Play Store: https://play.google.com/store/apps/details?id=com.notering.notering

Versão web das notícias: https://notering.com.br

Feedback sincero é muito bem-vindo, principalmente do que está ruim.

A OpenAI lançou o GPT-5.6 em 09/07/2026 e mudou a forma de nomear os modelos. Em vez de um modelo único com sufixos tipo "mini" ou "turbo", agora são três tiers com nome de astro: Sol, Terra e Luna. O número (5.6) é a geração; o astro é o nível de potência. Isso deixa a OpenAI atualizar um tier sem renomear a linha toda.

Escrevi uma versão mais completa no blog, mas queria trazer a discussão técnica aqui e ouvir como vocês estão encarando a escolha de tier na prática.

A lógica dos tiers

• Sol — flagship. Novo max reasoning effort + um modo ultra que dispara subagentes em paralelo para tarefas complexas de agente.
• Terra — o meio-termo. Desempenho competitivo com o antigo GPT-5.5 por ~metade do preço. Na minha leitura, é o melhor custo-benefício pra maioria dos casos.
• Luna — rápido e barato. Ideal pra alto volume: moderação, classificação, respostas curtas.

A metáfora é direta: Sol = mais forte, Luna = leve/rápido, Terra = sólido no meio.

A novidade técnica: Programmatic Tool Calling

O ponto que mais me chamou atenção não foi um tier, foi o Programmatic Tool Calling na Responses API. Em vez de o modelo chamar cada ferramenta isoladamente, ele escreve e executa pequenos programas em memória pra coordenar várias ferramentas de uma vez. É isso que sustenta os ganhos em trabalho de agente (passos encadeados) e o motivo de a OpenAI ir bem em benchmarks agênticos apesar de não liderar coding puro.

Benchmarks (SWE-Bench Pro)

Tabela de lançamento compilada pela Vellum AI:

Repare que Sol e Luna estão a menos de 2 pontos de distância. Na prática, o Luna resolve quase tanto quanto o Sol em muita tarefa, por uma fração do custo.

O detalhe honesto: coding puro

Aqui é onde a maioria dos comparativos BR passou batido. Em código puro (escrever uma função correta do zero), o Fable 5 lidera com ~80% de acerto, contra 64,6% do Sol. Ou seja:

• Coding puro / trechos isolados → Fable 5 leva vantagem.
• Trabalho de agente (encadear passos, chamar ferramentas, se autocorrigir) → GPT-5.6 leva vantagem, graças ao Programmatic Tool Calling e ao modo ultra do Sol.

A escolha deixou de ser "qual é melhor" e virou "melhor pra quê".

Preços (por 1M tokens)

Sol é ~5x mais caro que Luna em ambos. Em aplicações de agente (que queimam token), a conta dispara rápido. Contrapeso: a OpenAI afirma que o Sol é ~54% mais eficiente em tokens em coding agêntico, o que amortiza parte disso quando a tarefa casa com o perfil.

Como eu tenho pensado a escolha

O padrão que faz mais sentido pra mim é misturar tiers na mesma aplicação:

• Luna pro volume (tarefas simples e repetitivas)
• Terra pro miolo (o grosso do trabalho do dia a dia)
• Sol só nos gargalos reais (refatoração grande, pipeline de agente longo)

Subir pro Sol "por padrão" raramente compensa: o ganho sobre o Terra no SWE-Bench Pro foi de ~1 ponto, mas o preço praticamente dobra.

Disponível em ChatGPT, Codex, API e GitHub Copilot.

Como vocês estão dividindo os tiers nos projetos de vocês? Alguém já bateu o Terra a ponto de precisar do modo ultra do Sol de verdade?

Aprofundei a comparação completa — qual tier usar em cada caso e o ponto honesto do vs Fable 5 — no techknow, onde escrevo sobre IA/dev: https://www.techknow.com.br/post/gpt-5-6-sol-terra-luna

O GitHub tem um terreno nobre que muita gente deixa vazio. Crie um repositório público com o mesmo nome do seu usuário, coloque um README.md na raiz, e ele aparece no topo do seu perfil — acima dos repositórios fixados, antes de qualquer outra coisa. É a primeira tela que um recrutador gringo, um mantenedor de projeto ou um colega de comunidade vê quando abre a sua página. Se você mira vaga internacional, essa é a sua vitrine, e ela abre antes do seu currículo.

O meu ficou vazio por anos. Caiu a ficha quando um engenheiro me seguiu e eu abri o perfil dele: a página inteira funcionava como portfólio. Bio, produtos, atividade recente — tudo num README, sem visitar site nenhum. Bonito demais pra ignorar. Antes de montar o meu, fui olhar como os grandes fazem: abri o perfil de 10 engenheiros conhecidos (criadores do npm, React, Datasette, textlint) e anotei a estrutura de cada um.

Resultado: tudo coube em 7 estilos. E a escolha entre eles depende menos de gosto e mais de qual é o seu ativo mais forte.

Os 7 estilos que existem

1. Dashboard auto-atualizável — simonw. Quase zero decoração. Uma tabela de 3 colunas com últimos releases, posts do blog e TILs, preenchida todo dia pelo GitHub Actions. O README vira um feed vivo: quem abre percebe na hora que a pessoa produz sem parar. O criador do Datasette inventou o formato e documentou o esquema em 2020.

2. Minimalista refinado com auto-update — tw93. O criador do Pake resume a bio em 2 linhas, injeta os números reais (12 mil seguidores, quando olhei) e deixa releases e artigos se atualizarem sozinhos. É o estilo 1 depois de passar num designer.

3. Texto de conquistas — azu. Markdown puro, sem um único badge. Mas os números fazem o trabalho: 500+ pacotes npm, 10 milhões de downloads por ano. Funciona quando a bagagem é densa. O caso extremo: gaearon e outros nomes gigantes simplesmente não têm README de perfil. Quando todo mundo já sabe quem você é, o terreno vazio também comunica. Nós, meros mortais, seguimos plantando.

4. Vitrine de widgets — anuraghazra / DenverCoder1. Cards de estatísticas, SVG animado digitando, pins de repositório. O anuraghazra é o próprio autor do github-readme-stats; o DenverCoder1 é um catálogo vivo de tudo que existe em widget.

5. Muro de badges — thmsgbrt. Dezenas de badges do shields.io mapeando a stack inteira, com estrelas e status de CI ao vivo. Rende densidade visual rápido, mas todo perfil desse estilo acaba parecido com o vizinho.

6. Interativo — timburgan. Tem uma partida de xadrez rolando no README. Você clica num lance, abre uma issue, o Actions redesenha o tabuleiro. Quebra a premissa de que README é estático. O card de "tocando agora no Spotify" do andyruwruw é da mesma família.

7. Piada assumida — sindresorhus. Um dos maiores nomes do npm encheu o perfil de GIF anos 90, unicórnio e placa de "em construção". Só funciona porque a reputação dele chegou antes. Como no estilo 3, errar a ordem dessa jogada sai caro.

Como escolher: parta do seu ativo mais forte

Olhando os 10 perfis, o padrão que se repete: os bons perfis colocam na frente o ativo mais forte da pessoa. Os que não funcionam empilham enfeite sem lastro — badge de 50 tecnologias com 3 repositórios vazios embaixo convence ninguém.

No meu caso o ativo é frequência: publico artigo todo dia e livro todo mês. README decorado à mão começa a apodrecer no dia seguinte ao commit; um feed que se alimenta sozinho continua fresco sem eu encostar. Fui de dashboard.

A implementação: 3 peças

Visto assim, parece perfil de gente grande. Olhe o canto esquerdo de novo: 9 seguidores. Construí a vitrine antes da loja — a loja agradece a paciência.

A estrutura é o esquema do simonw, sem firula. São 3 peças:

Peça 1: marcadores em comentário HTML. Comentários não renderizam, então dá pra demarcar a zona que o robô reescreve, convivendo com o texto fixo no mesmo arquivo:

### Últimos artigos<!-- feed starts -->(esta parte é reescrita todo dia)<!-- feed ends -->

Peça 2: um script Python de ~90 linhas, só stdlib. Busca os feeds e troca o miolo entre os marcadores:

import jsonimport reimport urllib.requestdef fetch(url):    req = urllib.request.Request(url, headers={"User-Agent": "profile-readme"})    with urllib.request.urlopen(req, timeout=30) as res:        return res.read().decode("utf-8")def replace_section(text, name, lines):    block = "\n\n".join(lines)    pattern = re.compile(        rf"(<!-- {name} starts -->).*?(<!-- {name} ends -->)", re.S    )    if not pattern.search(text):        raise RuntimeError(f"marcadores de '{name}' não encontrados")    return pattern.sub(lambda m: f"{m.group(1)}\n{block}\n{m.group(2)}", text)

Guarde o detalhe do lambda na última linha. Ele volta já já, na armadilha 3.

Peça 3: um workflow do Actions rodando 1x por dia. Se não houver diferença no README, ele nem commita:

on:  schedule:    - cron: "0 9 * * *"  workflow_dispatch:permissions:  contents: write

Um cuidado: se você também disparar no push, restrinja o paths ao script e ao workflow. Incluir o README.md no gatilho cria a receita clássica de loop infinito — o commit do bot dispara o próximo run, que commita de novo.

As 3 armadilhas que ninguém documenta

Armadilha 1: o GitHub apaga praticamente todo CSS. Tag <style>, atributo style, tudo sanitizado. Sobrevivem align, width/height de <img>, <table> e... imagens. Ou seja: se quiser cor, fonte e identidade visual, o único caminho é assar tudo num PNG e colar como header. É também por isso que os perfis do estilo 4 vivem de SVG externo — widget é o jeito de decorar num mundo sem CSS.

Armadilha 2: o botão "Share to profile". Criei o repositório privado, montei tudo com calma e virei público no final. O README não apareceu no perfil. Fucei as configurações por meia hora achando que era cache — era um botão no canto do repositório, "Share to profile", que só aparece nesse fluxo. Quem cria o repositório já público nunca vê essa armadilha; quem prepara em privado, cai.

Armadilha 3: o título alheio que quebra seu regex. A versão ingênua da substituição é assim:

# ❌ bomba-relógioreturn pattern.sub(rf"\1\n{block}\n\2", text)

No re.sub, a string de substituição interpreta \1 como backreference. E o block carrega títulos vindos de feed externo. No dia em que alguém publicar um artigo com \1 no título — e quem escreve sobre regex publica — seu workflow quebra às 6 da manhã. A correção é dupla: lambda na substituição (o retorno não é interpretado como pattern) e escape nos títulos:

def md_escape(title):    title = " ".join(title.split())    for ch in "\\[]<>":        title = title.replace(ch, "\\" + ch)    return title

Parece paranoia até você perceber o que esse pipeline é: texto de terceiros entrando direto na sua página de perfil. ] quebra link em Markdown, < vira HTML. Trate como entrada não confiável, porque é.

Decoração apodrece. Feed, não.

Entrei nessa querendo decorar um README e saí com um pipeline. O resumo dos 10 perfis dissecados: o que separa um perfil bom de um perfil enfeitado é o encaixe entre o seu ativo real e o estilo escolhido. Enfeite sem lastro envelhece mal; número honesto e atividade recente envelhecem bem.

Meu perfil (github.com/kenimo49) agora se reescreve toda manhã. No dia seguinte à configuração, os artigos novos já estavam lá sem eu tocar em nada — sensação de regador automático funcionando no quintal. Se o seu terreno nobre está vazio: abra os 10 perfis lá de cima, veja qual ativo você já tem, e escolha o estilo que o valoriza. A decoração vem depois. Se vier.

ken imoto · AI Agent engineer · kenimoto.dev · TabNews

Sempre tive interesse em algoritmos variacionais, mas QAOA sempre me pareceu como algo de outro mundo.

Mesmo utilizando vários artifícios matemáticos,acredito que encontrei uma maneira relativamente simples de explicar o algoritmo.

Tudo não passa de rotações nos eixos X e Z em busca de encontrar o estado de menor energia.

Quando definimos um Hamiltoniano com nosso problema, queremos encontrar o estado que de a menor energia para ele, o seu eigenvalue para algum eigenstate.

Quando aplicamos as rotações na esfera de Bloch, o que estamos fazendo é, através dos parâmetros que otimizamos, estamos testando estados e avaliando com base na expectativa em relação ao Hamiltoniano.

Para mim, as camadas sempre foram estranhas. Sempre pensei, por que raios um Unitário com o Hamiltonian e outro sendo o Mixer. Mas agora tudo faz sentido, o unitário que codifica o Hamiltonian é usado para aplicar rotações no eixo Z (saindo dos eigenvalues de X, já que rotações em X não teriam qualquer resultado aqui) e com base na estrutura codificada do problema, essas rotações são aplicadas, seguindo de fato a função de custo. Já o mixer age como uma maneira de buscar esses eigenstates em Z, tentando projetar esses valores de volta em Z e assim explorando se aquele estado era promissor com base no problema.

Eu expliquei um pouco mais disso no meu post https://dpbm.vercel.app/posts/qaoa-the-simple-way-kkx4dygabjwbm/, espero que gostem.

Vale notar que não sou especialista, então qualquer bobagem que eu tenha dito estou aberto a aprender mais!

Semana de 05/07 a 11/07

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

Selecionamos os 5 conteúdos que mais geraram valor e discussão na comunidade:

Carta aberta ao TabNews ✉️

Eu acompanho o TabNews desde o lançamento oficial. Ao longo desses anos vi a comunidade crescer, mudar e produzir alguns dos melhores conteú...

HarukaYamamoto0, quarta 08/07 - 38 TabCoins

Sonho de infância realizado: Meu primeiro “Hello World” rodando em um Super Nintendo real

Montei uma ROM pequena em assembly 65816, compilei localmente, copiei para um EverDrive e consegui ver o resultado no console (você pode ver...

juliomiguel, terça 07/07 - 19 TabCoins

O criador do CLAUDE.md escreve 2 linhas. A comunidade escreve 100. Quem está errado?

Boris Cherny, criador do Claude Code, mantém um CLAUDE.md pessoal de duas linhas. Você lê isso em uma entrevista e pensa: "ah, então o ...

kenimo49, segunda 06/07 - 17 TabCoins

O plano perfeito que foi rejeitado em 20 segundos

Como gastei dois dias projetando uma migração de identidade — e o CTO escolheu a opção que planejei em meia hora. Segunda-feira, reunião cur...

vmv, domingo 05/07 - 14 TabCoins

BOLA: a falha de segurança que a autenticação não resolve (e como eu blindei meu SaaS multi-tenant)

Meses atrás eu estava fazendo uma varredura de segurança no sistema multi-tenant da minha empresa, procurando vulnerabilidades. Afinal, já é...

LucasMaieski, segunda 06/07 - 10 TabCoins

😄 Pra descontrair

xkcd.com

Até o próximo sábado!

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

Eu imploro que você aprenda programação.

E sim, eu afirmo isso sem dúvidas. Se eu fosse você, começava hoje.

Programar ainda é a forma mais simples e poderosa de dominar a IA, criar clareza mental, organizar suas ideias e construir algo no futuro autêntico e lucrativo - ou conquistar o emprego dos seus sonhos.

Mas é óbvio que hoje você terá desgosto de aprender programação. Abre às redes sociais: "a inteligência artificial vai substituir programadores".

Essa frase é um equívoco. E eu sei porque eu também caí nele.

Com mais de 5 anos na área, eu fiquei assustado. Sim, eu.
Até programadores mais experientes passaram por isso.

A nossa área mudou muito nos últimos anos, mas ainda está muito longe de substituir os programadores.

Não acredita em mim? Acredita em quem está gastando bilhões nisso.

3 PROVAS DE QUE A IA AINDA NÃO SUBSTITUI NINGUÉM

"Não vejo ganho de produtividade proporcional ao custo." - Falou o CEO da Uber publicamente, depois de estourar o orçamento anual em IA em 4 meses.

A Microsoft cancelou parte das licenças do Claude Code - por causa do custo também.

A Starbucks encerrou um sistema de IA depois de 9 meses, por errar contagem de itens.

Só que isso não quer dizer que a IA é ruim. Ao contrário. Segue o raciocínio comigo.

O PROBLEMA NÃO É A IA. É QUEM ESTÁ POR TRÁS DELA.

As IAs hoje são muito boas em entregar código com certeza.
Mas muita gente usa isso como atalho pra um trabalho que precisa ser feito, que é entender o domínio, treinar um time, manter o padrão, entender o processo.

IA não substitui processo. Ela acelera o processo.

E para isso acontecer, você precisa ter conhecimento, experiência, regras de negócio.
O problema não é mandar a IA fazer algo. O problema é quem vai mandar o quê fazer.

Deixa eu te mostrar como isso quebra na prática.

A pessoa abre o Claude, escreve um texto, e pensa: "agora eu vou lançar meu SaaS".

Sem plano de implementação. Sem stack definida. Sem canal de venda. Sem canal de distribuição, sem nada.

Na cabeça dela, esse vai ser o melhor produto do ano. Às vezes é. Na maioria das vezes, não.

PONTO IMPORTANTE

A IA funciona quando você usa pra criar algo que você já sabe fazer - entender estruturas, fluxos, processos.

Ela não funciona quando você usa pra substituir algo que você nem entende.

Usa a IA pra ir mais longe dentro do que você já sabe fazer. Não o contrário.

Qualquer um escreve código com IA hoje. Mas manter esse código alinhado com o negócio do projeto, isso quase ninguém sabe fazer.

Escrever código ficou simples. Mas escrever código simples continua difícil, e isso exige conhecimento e experiência de verdade.

As vagas existem. As contratações estão acontecendo.

O mercado está longe, muito longe de substituir programadores.

Mas você precisa ser bom nisso. Ter experiência de verdade.

Tenha paciência. Tenha humildade de sentar e estudar a base. Quem não fizer o trabalho difícil vai ficar pra trás.

Se você quer aprender programação na era da IA, sem atalho e sem enrolação, startroadmap.dev é o lugar mais simples pra começar.

Te vejo lá.

Fala pessoal! Compartilhando um projeto que venho construindo.

Sempre tive dificuldade de manter controle financeiro porque odiava abrir app ou planilha toda vez que gastava alguma coisa. Geralmente só lembrava no fim do mês, quando já não fazia mais diferença.

Resolvi criar um bot de Telegram pra resolver isso: você manda um áudio tipo "gastei 50 no mercado" e ele registra a despesa, categoriza automaticamente (alimentação, transporte, etc.) e atualiza um dashboard com saldo real, já descontando fatura de cartão.

Como funciona:

1. Cria a conta no site
2. Conecta o Telegram no perfil
3. Manda áudio ou texto com o gasto — o bot entende, categoriza e salva na hora

Ainda tá bem no início — tem plano gratuito e recursos pagos pra quem quiser mais. Queria muito feedback de vocês: sobre a proposta, UX, modelo de negócio, o que acharem relevante.

Links:

• Site: https://financa.informaticarm.com.br
• Bot: https://t.me/FinancaAssistenteBot

Sempre que eu voltava pro ubuntu tinha uma coisa que me incomodava: o Win+V do Windows.

Depois que você acostuma com o histórico da área de transferência fica difícil viver sem. Até existem alguns gerenciadores de clipboard no Linux, mas nenhum me passava a sensação de ser uma função nativa do sistema. Então pensei: beleza, vou fazer eu mesmo.

Nasceu o WinV.

A ideia foi copiar a experiência do Windows 11 o mais fiel possível, mas integrada ao GNOME.

O que ele faz:

• Win + V abre o histórico da área de transferência;
• suporta texto e imagens;
• busca instantânea;
• permite fixar itens;
• limpar o histórico;
• Win + E abre o painel de emojis (No Windows é win+. porém pode causar bugs 😅);
• acompanha automaticamente o tema claro ou escuro do GNOME;
• o popup aparece perto do cursor, igualzinho ao Windows.

O mais engraçado é que guardar o histórico foi a parte fácil. O difícil foi fazer tudo parecer que sempre esteve ali. Passei mais tempo brigando com posicionamento, animações, atalhos e detalhes visuais do que com a lógica em si.

No fim fiquei bem feliz com o resultado. É aquele tipo de projeto que comecei porque senti falta de uma funcionalidade e acabei usando todos os dias.

O código é open source:

GitHub: https://github.com/Peterson047/winv

Se alguém quiser testar, dar sugestões ou mandar um PR, fica à vontade. E se conhecer algum detalhe do Win+V do Windows que eu ainda não reproduzi, pode falar também. Minha intenção é deixar a experiência o mais próxima possível.

E, ao me mostrar os números, provou que eu jogaria dinheiro fora se insistisse

Eu abri o Claude Code pronto para desenhar o roadmap de produto do próximo ano. Em vez de me ajudar, ele me deu um esporro: “você não deveria estar pensando em novas funcionalidades”. Eu quase discordei. Até ele me mostrar os números.

Na edição de hoje da Newsletter do Moa, eu mostro como achar o ajuste que faz seu faturamento dobrar gastando pouco (e por que criar mais features quase nunca é esse ajuste).

Roadmap

Eu estava com uma missão aqui no Tintim: colocar no papel o que eu acredito como roadmap para os próximos seis meses a um ano de produto. Essa não é uma tarefa fácil. Envolve considerar problemas atuais, pedidos dos clientes, relacionamento com parceiros e também o que eu acredito que, estrategicamente, o mercado vai precisar.

Para enfrentar o problema, eu abri meu fiel escudeiro, Claude Code (munido de uma ferramenta muito poderosa, o Mirror Mind), coloquei o Fluid Voice para trabalhar e comecei a conversar com a inteligência artificial.

De cara, o Opus me questionou: “por que você quer fazer um roadmap?”. Justifiquei, ele me pediu dados, e eu apontei para o repositório onde concentro todas as nossas análises. Ele analisou, perguntou um pouco mais, e então deu seu veredito: você não deveria estar pensando em novas funcionalidades!

O raciocínio dele fazia muito sentido. Se o nosso objetivo é aumentar LTV e ticket médio, existiam pontos mais prioritários a serem endereçados, como, por exemplo, um problema conhecido de ativação de novos clientes. Segundo o Opus, atacar esse problema traria mais retorno do que sair enchendo o produto de feature. E ele estava certo.

Dois cenários distintos

Imagine um SaaS com o seguinte funil: todo mês, 10 mil visitantes chegam ao site. Desses, 1 mil, ou 10%, se cadastram para fazer um trial. Desses, 200, ou 20%, acabam se tornando clientes pagantes. Desses, 100, ou 50%, conseguem fazer o setup e extrair valor do produto, a ponto de incorporarem a solução em seus processos de trabalho. Se estamos falando de um LTV médio de R 1 mil, podemos concluir que, para cada 10 mil visitantes no site, temos um potencial faturamento de R 200 mil.

Se eu te pedisse para dobrar esse montante, de R 200 mil para R 400 mil de faturamento, o que você faria?

A primeira opção que vem na cabeça é trazer mais gente para o site, certo? Se a gente dobrar, de 10 mil pessoas, para 20 mil pessoas, e todas as outras variáveis se mantiverem, teremos um acréscimo de R$ 200 mil na receita esperada, ao fim do fluxo.

Agora, quanto custa dobrar a quantidade de acessos do site (e manter todas as outras variáveis)? No mínimo, o dobro, né? Mas, se lembrarmos que, quanto mais alto o valor gasto em mídia paga, menor é a qualidade do público-alvo impactado, provavelmente esse custo será mais que o dobro. Caro, né? Será que existe alguma outra solução?

A pergunta que devemos fazer aqui é: qual é o número que dá pra dobrar mais fácil (a.k.a. mais barato)? Podemos, por exemplo, atacar a etapa de ativação do cliente e buscar uma taxa de 90%, em vez dos 50% atuais. Imagine que isso melhore a quantidade de clientes satisfeitos, a ponto do LTV dobrar, para R 2 mil. O resultado seria os mesmos R 200 mil de acréscimo.

Restrições e alavancas

O desempenho de qualquer sistema é limitado por sua restrição (tipo um gargalo). Portanto, o maior retorno sobre esforço vem de melhorar essa restrição, não de otimizar qualquer outra parte do sistema. Quem defende essa tese é Eliyahu Goldratt, autor do livro A Meta.

Existem muitos pontos onde você pode investir tempo e dinheiro. Alguns têm efeito marginal; outros multiplicam o resultado. A prioridade é encontrar a alavanca de maior impacto. Quem disse isso foi Sean Ellis, autor do livro Hacking Growth, e quem cunhou o termo “growth hacking”.

O tamanho de uma empresa é medido pelo tamanho do seu faturamento. Rentabilidade, eficiência, etc., são métricas importantes, mas medem outra coisa. Tamanho se mede por receita. Quando falamos de growth, ou seja, de crescimento, estamos falando de aumentar a receita de uma empresa (sim, houve um tempo em que o tamanho de uma empresa era medido pela quantidade de usuários, por exemplo, mas esse tempo passou).

No exemplo do bloco anterior, dobrar a quantidade de acessos é um caminho, sem dúvida. Mas, provavelmente, um caminho caro. Qual o tamanho do bolso da empresa? Ela aguenta seguir por esse caminho caro? Se sim, ótimo! Senão, temos que pensar em alternativas mais baratas.

Quanto custa investir num onboarding melhor? Contratar mais programadores? Mais designers? Melhores profissionais? Contratar um time de operações, para fazer um acompanhamento mais consultivo? Talvez esse caminho seja mais em conta. Principalmente, talvez, nesse caminho, a conta feche.

Voltando à história do começo do texto. Mais features podem significar, sim, um ticket médio maior e um LTV maior. Mas, será que essa é a solução mais barata para alterar esses indicadores? Segundo o Claude, existia um ganho muito maior em atacar o problema que temos de ativação, em vez de desenvolver novas features.

Obviamente, numa empresa do tamanho do Tintim, já temos um poder de fogo mais robusto, a ponto de poder atacar mais de uma frente ao mesmo tempo. Mas, ainda assim, os recursos são limitados e, no fim do dia, temos que ser efetivos o suficiente para manter a empresa crescendo, porém saudável financeiramente. Por isso, saber priorizar e atacar o problema correto talvez seja uma das habilidades mais importantes de um empreendedor.

E aí, onde está seu gargalo?

✉️ Se você quer acompanhar semanalmente os meus artigos, acompanhe a Newsletter do Moa

💪🏻 O meu objetivo é ajudar profissionais de tecnologia que desejam desenvolver uma visão mais estratégica.

Além disso, pretendo também compartilhar outras coisas, como um pouco dos bastidores da construção de um negócio SaaS, as minhas opiniões e meus aprendizados. A ideia geral é ser uma documentação pública e estruturada dos meus pensamentos e aprendizados ao longo dos anos.

Portanto, se você se interessa por soft-skill, desenvolvimento pessoal, empreendedorismo e opiniões relativamente polêmicas, sugiro que você se inscreva para receber as próximas edições.

Eu estava feliz. Meu modelo de IA para previsão de criptomoedas estava com 96% de acurácia no horizonte de 30 minutos. 96%! Eu já estava pensando em como gastar o dinheiro que ia ganhar.

Era mentira. O modelo não tinha aprendido nada. Eu tinha um bug.

O sintoma

Olhando o histórico de trades verificados, vi algo muito estranho:

[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... 300 zeros seguidos ...][1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ... 200 uns seguidos ...][0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... 400 zeros seguidos ...]

Nenhum modelo real acerta 200 vezes seguidas e depois erra 400 vezes seguidas em um mercado volátil. Isso não é aprendizado — é um artefato.

O diagnóstico

Meu sistema registrava um "trade" (snapshot) a cada 2 segundos. Para o horizonte de 30 minutos, isso significava ~900 snapshots acumulados. Mas o detalhe crucial: eles não eram 900 trades independentes — era exatamente o mesmo evento de mercado registrado 900 vezes de forma sobreposta.
Se o mercado subiu durante aqueles 30 minutos, todos os 900 snapshots eram contados individualmente como "acertos". Se caiu, como "erros". O modelo podia estar prevendo "COMPRA" 100% das vezes — a acurácia alta só refletia se o mercado tinha subido ou descido de forma direcional naquele período.
Isso se chama autocorrelação temporal (e uma forma clássica de data leakage). As amostras não eram estatisticamente independentes. Minha acurácia de 96% era, na verdade, apenas a porcentagem do tempo que o mercado passou em tendência de alta naquele mês de teste.

A solução: subsampling estatístico

A correção foi simples na teoria, mas exigiu reestruturar o pipeline de verificação e armazenamento dos dados:

_FATOR_SUBSAMPLE = {
5: 1, # 5s: registra a cada 1 tick
60: 5, # 1min: registra a cada 5 ticks (10s)
300: 25, # 5min: registra a cada 25 ticks (50s)
1800: 150, # 30min: registra a cada 150 ticks (5min)
3600: 300, # 1h: registra a cada 300 ticks (10min)
}

Agora, cada horizonte de tempo só registra 1 trade a cada N ticks. Para o horizonte de 30 minutos, o fator passou a ser 150. Ou seja, em vez de gerar 900 snapshots idênticos e viciados, passei a coletar apenas 6 amostras verdadeiramente independentes por período.

O resultado

A acurácia desabou de 96% para ~52%.
Doeu no ego, mas agora cada trade no histórico representa uma decisão real e independente do modelo, não um viés mascarado do mercado.
Troquei volume falso por qualidade real. E isso mudou tudo na hora de treinar a IA: sem o ruído e a falsa sensação de acerto da autocorrelação, o aprendizado tornou-se muito mais estável e as métricas finalmente passaram a refletir a realidade.

O que aprendi

Quando a acurácia parece boa demais para ser verdade, ela é. Sempre.
Desconfie imediatamente de blocos massivos de acertos ou erros consecutivos.
Verifique sempre a independência estatística das suas amostras (I.I.D.).
Nunca, jamais confie em métricas de validação sem auditar visualmente como os dados estão a ser fatiados.
Isto aplica-se a qualquer projeto de Machine Learning ou Data Science que lide com dados temporais (Time Series), não apenas ao mercado financeiro.

Referências:

Repositório no GitHub: https://github.com/EventHorizon-ia/EventHorizon
Painel de Auditoria Pública do Projeto:
https://eventhorizon-ia.github.io/trader-ai/dashboard.html

Um desabafo e o resumo dos meus estudos sobre treinamento de IA no Brasil

"Eu só queria construir com as minhas próprias mãos — nem que fosse só brincando."

Antes de tudo: quem escreve isso

Eu sou só um pesquisador/programador que gosta de estudar o que me cativa. Quem já acompanha meus artigos aqui no TabNews sabe que eu tento sempre trazer algo minimamente apresentável — e essa palavra, apresentável, é meio que a minha cruz. Sempre tive o péssimo hábito de travar meus projetos por achar que não estão bons o suficiente nem para mostrar. Muita coisa boa morreu na minha cabeça por causa disso.

Tenho 24 anos. Comecei na programação web há uns 6 anos, mas antes disso já mexia com servidores de Minecraft e jogos na Unity. Se você quiser me conhecer melhor, escrevi um relato mais pessoal aqui: apenas-um-relato-mrj.

Resumindo o essencial: há alguns meses eu consegui treinar um LLM de verdade — com sucesso superficial, é verdade, e usando uma base estrangeira como ponto de partida. Mas meu objetivo nunca foi só "ter um modelo". Foi aprender e desenvolver com as minhas mãos, mesmo que seja só brincando com IA e vibecode.

Eu tenho um caderno mental (e alguns arquivos soltos) de ideias aleatórias que anoto e deixo lá. Quando travo, eu puxo uma delas. Este artigo é o resumo dessas ideias — algumas viraram código que rodou, outras são conceitos que poderiam existir se eu tivesse tempo e dinheiro. Vou explicar cada uma, com fluxograma e uma tabela comparativa no final.

O fio condutor: e se cada IA tivesse uma arquitetura própria?

A moda hoje é escalar o mesmo transformer até o infinito. Eu fico fascinado com a pergunta oposta: e se a arquitetura em si fosse diferente? E se, em vez de mais do mesmo, a gente misturasse tipos diferentes de cérebro? É esse fio que costura todos os projetos abaixo.

1. 🧠 Think-Vetor — a micro-LLM que "pensa" no espaço latente e não erra conta

O que é: um micro-LLM de 0.5B de parâmetros que faz o raciocínio dentro do espaço latente (nos embeddings ocultos), em vez de "pensar em voz alta" cuspindo tokens de Chain-of-Thought. O loop recorrente tem parada dinâmica (PonderNet — para quando já "pensou o suficiente") e é estabilizado por um bloco de energia de Hopfield acoplado à dinâmica de Langevin (relaxa as ativações em atratores estáveis).

A sacada (TV-DSL): para matemática ser 100% infalível, o modelo não tenta adivinhar os dígitos. Ele escreve uma instrução simbólica dentro do pensamento — tipo [TV-DSL: multiply(432, 78)] — um coprocessador determinístico (AST do Python) intercepta, executa o cálculo exato, e reinjeta o resultado (-> [RESULT: 33696]) de volta no espaço cognitivo. A LLM vira a "CPU orquestradora", não a calculadora.

  Prompt: "Quanto é 432 × 78?"        │        ▼  ┌─────────────────────────────────────┐  │  LLM 0.5B (Qwen2.5 + LoRA)          │  │  raciocínio LATENTE (loop recorrente)│  │  PonderNet: para quando convergiu    │  │  Hopfield + Langevin: estabiliza     │  └───────────────┬─────────────────────┘                  │ detecta intenção matemática                  ▼        escreve  [TV-DSL: multiply(432, 78)]                  │                  ▼  ┌─────────────────────────────────────┐  │  Coprocessador AST (Python) EXATO   │ → [RESULT: 33696]  └───────────────┬─────────────────────┘                  │ reinjeta no espaço latente                  ▼        Resposta final: "33.696" (sem alucinação)

Por que isso importa: um modelo de 0.5B bateu 83–100% no GSM8K (o benchmark-padrão de matemática) — superando modelos comerciais de até 4× o tamanho (Qwen 1.5B, Gemma-2 2B ficam em ~68%). Não é mágica: é desacoplamento — delegar o cálculo pesado a um executor exato em vez de estimá-lo probabilisticamente. Tem Space público no Hugging Face (CromIA/think-vetor-chat).

2. 🧬 CROM-IA-V1-DNA — a semente

O que é: o meu primeiro modelo público de verdade (CromIA/CROM-IA-V1-DNA) — o "DNA", a gênese de onde tudo cresceu. A linha de pesquisa por trás dele (crom-pesquisa-ia00) mira modelos cognitivos híbridos e leves: neuro-simbólicos, micro-escala (0.5B–1.5B), pensados para rodar rápido em computador comum, combinando flexibilidade neural com exatidão determinística (herdando o TV-DSL, memória vetorial e experimentos com atenção linear tipo Mamba).

  ┌──────────────────────────────────────────────┐  │            CROM-IA-V1-DNA (a semente)         │  │  Híbrido neuro-simbólico, micro-escala, local │  │                                                │  │   Neural (flexível)  +  Determinístico (exato) │  │   Memória vetorial   +  Atenção linear (Mamba) │  └──────────────────────────────────────────────┘        │        └──► deu origem ao Think-Vetor e à família Quimera

Por que existe: era eu testando se dava para ter "raciocínio de gente grande" numa máquina pequena. O nome DNA é isso — vem da ideia de em vez de gerar tokens de palavras, e gerasse token de um dna que seria uma frase maior, algo como: output -> #@1dbrsail -> descriptografa o token -> O brasil é um País Soberano.

3. 🐉 CROM-Quimera (MoA) — Mistura de Arquiteturas, não de experts iguais

O que é: um LLM de 1.1B com a ideia que mais me anima: MoA (Mixture of Architectures). No MoE clássico (Mixtral, etc.), todos os "experts" são MLPs idênticas. No MoA, cada expert é uma arquitetura diferente, especializada num tipo de processamento:

• Backbone compartilhado (390M) — entende a linguagem geral.
• Expert 0 🏃 Rápido — MLP de 2 camadas, para tokens triviais.
• Expert 1 🧠 Profundo — Transformer de 8 camadas, para raciocínio.
• Expert 2 💻 Código — Transformer de 4 camadas, para sintaxe.
• Expert 3 ⚡ Difusão — um denoiser que gera blocos de tokens (inspirado em difusão), não autorregressivo.
• Router — escolhe os 2 melhores experts por token (top-2), antes de eles rodarem.

  Token → ┌──────────────────────────┐          │  Backbone (390M, comum)  │          └───────────┬──────────────┘                      ▼               ┌────────────┐               │   ROUTER   │  decide ANTES: top-2 de 4               └─────┬──────┘        ┌───────┬────┴────┬────────┐        ▼       ▼         ▼        ▼     🏃 Fast  🧠 Deep   💻 Code  ⚡ Difusão     (MLP 2L) (Trf 8L) (Trf 4L) (denoiser)   ← arquiteturas DIFERENTES        └───────┴────┬────┴────────┘                     ▼        combinação ponderada (softmax) → LM Head → próximo token

A saga real (o porquê deste artigo ter começado): esse foi o projeto onde eu mais apanhei. Várias versões (v2.4.0 a v2.4.4) colapsavam — o router degenerava e o modelo cuspia lixo numérico tipo 381,6* 8: 31441012)^3. Depois de muita auditoria, achamos 3 bugs-raiz:

1. O Expert 3 carregava o arquivo errado → ficava com pesos aleatórios em toda rodada.
2. Uma "gambiarra" processava cada token isolado (seq_len=1), matando a atenção dos experts.
3. A classificação de domínio colapsava (a palavra "você" rotulava 100% dos dados no mesmo balde).

Corrigidos os três, rodei o SFT completo (8000 passos, ~$1) e a bateria de testes saiu de 0% (sempre colapsava) para 78%: o router finalmente distribui entre os 4 experts sem colapsar, e a memória multi-turno funciona (ele lembra o nome do usuário depois de uma distração). O que ainda falha (prosa embolada, identidade) não é a arquitetura — é a base subtreinada (foi pré-treinada com só ~94M tokens únicos, ~85× menos do que o ideal). Ou seja: a arquitetura está provada; falta dado.

4. 🐲 Quimera-Hydra — todas as cabeças geram, o árbitro decide depois

O que é: a evolução natural da crítica ao MoA. No Quimera, o Router "adivinha" quais experts são bons antes de vê-los trabalhar — e se ele erra, o modelo gera lixo mesmo tendo a resposta certa em outro expert. A Hydra (a serpente de várias cabeças) inverte isso: todos os 4 experts processam cada token, e um árbitro escolhe/combina os melhores DEPOIS de ver o que cada um produziu.

  Token → ┌──────────────────────────┐          │        Backbone          │          └───────────┬──────────────┘        ┌───────┬─────┴─────┬────────┐   TODOS geram (sem router filtrar)        ▼       ▼           ▼        ▼     🏃 Fast  🧠 Deep     💻 Code  ⚡ Difusão        └───────┴─────┬─────┴────────┘                      ▼             ┌──────────────────┐             │  ÁRBITRO HYDRA   │  decide DEPOIS de ver as saídas reais             │ (ensemble/voto/  │             │  confiança)      │             └────────┬─────────┘                      ▼                 token final

Estratégias de arbitragem que projetei: Weighted Ensemble (combina os logits com pesos aprendidos), Confidence-Gated (o expert mais confiante ganha o token) e Contrastive (experts que concordam ganham peso; outliers são penalizados). Custa mais compute (+19% na inferência, todos os experts rodam), mas é muito mais robusto — nunca colapsa, porque sempre vê todas as opções. O melhor: a primeira fase dá para prototipar sem re-treino, reusando os pesos que já tenho.

5. ⚡ Quimera-Synapse — plasticidade: um modelo que aprende enquanto conversa

O que é: talvez a ideia mais ambiciosa. LLMs em produção têm pesos estáticos — se você corrige o modelo ("não use essa biblioteca, use aquela"), ele esquece assim que a conversa reseta. A Synapse propõe aprendizado em tempo de execução:

• Backbone congelado (read-only na VRAM).
• Micro-LoRAs dinâmicos por sessão — adaptadores minúsculos (rank 4–8, poucos MB) que rodam em paralelo.
• Juiz Oculto (gating) — uma camada linear que ativa os adaptadores certos direto nos embeddings, sem decodificar texto.
• Sandbox RL de loop fechado — para tarefas verificáveis (código, formatação), a saída é executada e validada por um juiz determinístico (um compilador, um teste unitário). Se falha, um sinal de erro faz um backprop curtíssimo só no LoRA (99% mais barato que fine-tuning).

  Backbone CONGELADO (read-only)        │        ├──► Juiz Oculto (gating) ──► ativa micro-LoRAs da sessão (ΔW = B·A)        │        ▼     Saída gerada        │        ▼  ┌──────────────────────────────┐  │  SANDBOX: executa + valida   │  (compilador / testes / regex)  └───────────┬──────────────────┘     OK ✅    │    ERRO ❌      │       │       │      ▼       │       ▼  consolida   │   backprop CURTO só no LoRA  ──► (volta e melhora)  (merge ou   │   patch      │   S-LoRA)    ▼

Por que me empolga: é a diferença entre um modelo que é ensinado uma vez e um que aprende com o uso, sem esquecimento catastrófico e sem re-treinar tudo. Ainda é conceito — mas o mini-circuito em PyTorch já converge no sandbox.

📊 Tabela final — as arquiteturas lado a lado

O padrão que me move: MoA orquestrando múltiplas arquiteturas diferentes, em vez do MoE tradicional de especialistas iguais. Cada projeto é uma variação disso — ou um filho da ideia original.

O desabafo (a parte difícil de escrever)

Agora a verdade sem maquiagem.

Neste último mês, eu gastei uns $50–60(sim dolares) do meu próprio bolso nessas pesquisas. Para muita gente é pouco. Para mim já é mais do que muito. Eu me animei, passei do meu limite, e preciso ser honesto comigo mesmo sobre isso.

Eu uso a Vast.ai (e às vezes GPUs gratuitas, que me limitam por tempo). E o processo é exaustivo: você espera 8, 10 horas por um resultado, e ele falha no meio e você refaz do zero. Ou termina, e você descobre um erro de funcionamento interno bobo lá no fim. Erros que a IA até me ajuda a explicar na hora — mas na hora de aplicar a correção, ela se embola, e eu tenho que ficar lendo e editando manualmente, tentando (às vezes em vão) consertar. Foi exatamente isso que aconteceu no Quimera esta semana: instância com upload lento travando o treino, dois processos causando OOM, checkpoint perdido, refazer... e no fim deu certo, mas cada tropeço desses custa dinheiro real e horas da minha vida.

Estou pensando em dar um tempo disso. Não porque parei de gostar — eu amo isso, às vezes passo 100% do meu tempo, 24/7, mergulhado. Mas eu preciso de uma base financeira antes de me afundar de vez nesse oceano. Enquanto isso, faz mais sentido eu ficar no que é sustentável: agentes e especialização de LLMs que já existem (fine-tuning), em vez de treinar arquiteturas novas do zero — que é onde mora meu coração, mas também onde mora o custo.

Pensei em procurar faculdade ou grupos de pesquisa. Mas sinto que, se eu não puder dar 100% 24/7, não vou conseguir acompanhar — e, ironicamente, é porque eu gosto que eu às vezes dou 100%. Só que esse não é o único caminho que eu gostaria de seguir. Se for só isso, eu vou ter que ir trabalhar "lá fora" — o que é bom por um lado, mas por enquanto foge do que eu queria. E, sinceramente, acho que não tenho tanto tempo assim.

A maioria dos meus projetos está privado. E olha, eu não sei criar patente. Só deixaria privado mesmo para não perder a chance de um dia tornar tudo público e open-source — porque tenho medo de alguém patentear e privar algo que eu criei primeiro para todos e me tirar essa possibilidade de trabalhar nisso. Não é ganância; é medo de perder o direito de compartilhar.

Isto aqui é só um desabafo. Eu até pediria ajuda — mas acho que não teria a atenção necessária, nem o dinheiro necessário para trazer algo realmente útil. Porque a real é essa: para pesquisa de arquitetura séria, é extremamente necessário comprar placas de vídeo — e hoje uma placa decente custa mais de R$ 10.000(Só Pc novo que comprei po 3.000 tem video integrado - sem placa de video). Pensando de forma útil, só valeria a pena se eu já tivesse algo rentável de base — não só doações. Não para pesquisas que precisam de tempo e atenção como estas.

É isso.

Se você leu até aqui: obrigado. Se você é alguém que também constrói coisas estranhas e bonitas sozinho, no seu canto, com medo de que não sejam "boas o suficiente" — este texto é para você também. Às vezes o valor não está no projeto que funciona 100%, mas na Quimera que a gente teve coragem de montar.

— MrJ / CromIA

A gente convive com isso há 30 anos porque quem lia o log era um humano que
aprendeu a ignorar o resto. Só que hoje, cada vez mais, quem lê o log é uma IA —
e ela paga por todas as 60 linhas em tokens e contexto.

Construí o Stacktale pra resolver isso: um appender de log (Logback, Log4j2,
Spring Boot) que, quando dá erro, escreve um relatório feito pra esse leitor —
causa raiz primeiro, o SEU frame marcado, o ruído de framework colapsado, a
história dos eventos que levaram ao erro, os campos da exceção, segredos
redigidos, repetições deduplicadas.

Medindo no meu próprio uso: ~98% menos tokens numa sessão, ~80% num erro único.

Open source (Apache-2.0), no Maven Central. O formato do relatório é versionado
e quero fechar com a comunidade antes do 1.0.

https://gabrielbbaldez.github.io/stacktale/

#java #springboot #observability #opensource

OBS: Originalmente postei esse conteúdo no meu HashNode, porém estava lembrando que faz um tempo que não posto nada aqui, por isso resolvi postar aqui também.

Nos dias de hoje, a rotina de quem trabalha com Desenvolvimento de Software conta com diversas tomadas de decisão, sejam elas para escolher qual arquitetura, ferramenta, pattern usar em suas implementações.

Mas tem algo que tem fugido de nossas escolhas: utilização de IA.

Repare que não falo em usar padrões de Prompt como Chain-Of-Though ou Role-Based, usar os modelos da DeepSeek ou da Anthropic, contar com vários agentes ou fazer um pair-programming com a IA, falo que a maioria das empresas tem imposto o uso de IA no dia-a-dia como um acelerador de entregas. Usar não é uma opção.

Fazer um juízo de valores a respeito dessas decisões não cabe a mim, pelo menos não a este texto, e observando esse cenário, tenho buscado achar maneira de usar a IA para me ajudar na aceleração das minhas entregas.

Nisso, um pensamento correu em minha mente:

"e se eu usasse a IA para programar e... SER O CÓDIGO???**"

E se fosse a IA ser quem aplica a regra de negócio de um serviço, não usando código, mas sim a resposta que ela me devolve?

A resposta para essa pergunta é o que você vai encontrar com mais detalhes abaixo. Boa leitura!

O começo: procurando ideias

Para conseguir ter um resultado interessante, eu precisaria aplicar esse conceito em um projeto que tivesse uma regra de negócio que envolvesse uma complexidade um pouco maior, mas que também não fosse um bicho de 7 em sua implementação.

Após algumas sugestões da IA (sim, ela está presente em cada passo), achei que seria interessante desenvolver uma API REST para controle de estoque, onde eu conseguiria cadastrar produtos, locais de estoque e guardar uma quantidade X do produto Y no local Z.

Um projeto assim está dentro do nível de complexidade que estava buscando.

Colocando o Vibe Coding em prática

Para me auxiliar, utilizei o Antigravity da Google, utilizando o plano PRO que eles oferecem para IA. Ao invés de usar a IDE dele, usei o CLI mesmo, pois não abro mão de usar o meu IntelliJ, pois me sinto mais em casa com ele. Falando em IDE, vou passar um resumo do que solicitei ao Claude Sonnet para gerar de código:

• Aplicação em Java 26 e Spring Boot 4;

• Banco de Dados H2 e Postgres em PRD;

• JUnit e Mockito para testes unitários (compatível com as versões que passei acima);

• Como sou um pobre programador, pedi para ele configurar o Mistral como nossa "IA Backend";

• Implementar essa relação de endpoints:

  • Um endpoint GET que retorna uma lista de todos os Produtos guardados;

  • Um endpoint GET que retorna um Produto pesquisado e os Locais onde ele está guardado;

  • Um endpoint GET que retorna todos os Locais cadastrados;

  • Um endpoint POST para criar um Estoque;

  • Um endpoint POST para guardar um Produto;

  • Um endpoint PUT para editar um Estoque;

  • Um endpoint PUT para mudar um Produto de um Estoque para outro;

  • Um endpoint DELETE para remover um Produto do Estoque;

  • Um endpoint DELETE para remover um Estoque, caso vazio;

• Uma ênfase em que a regra de negócio por trás do guardar o produto no estoque não deveria ser escrita em código, mas questionado a uma IA se o sistema poderia guardar ou não;

• Utilizei o modo de /plannig do Antigravity, que fez com que eu respondesse algumas perguntas referente a alguns pontos que não tinham ficado claros;

Escrita do projeto

Com tudo isso entendido e esclarecido, ela me apresentou um plano com 12 passos de implementação, para que eu revisasse e desse meu aval para dar início a marretagem de código.

Fui aprovando e revisando o que era implementado até o passo 10, que foi onde minha cota com o Claude Sonnet acabou 🥲.

Mudando para o Gemini 3.1 Pro, seguimos com o passo 10, que acabou se revelando o último (sim, eram 12 passos, mas do 1 ao 3 ela considerou como um passo só 🤷‍♂️) , que era a implementação de testes unitários.

HORA DE RODAR!

A IA foi lá e escreveu código, mapeou as entidades, preparou os endpoints, pensou na autenticação, e quando chegou na hora de executar... não funcionou mas foi lindo de ver.

Havia um erro de compilação no código gerado, na classe responsável por chamar o Mistral para tomar a decisão em cima do prompt descrito, que se tratava de um bean que o Spring Boot não estava conseguindo injetar na classe (o ObjectMapper da lib Jackson). Decidi testar as capacidades dela para resolver esse problema e ela apanhou um pouco para conseguir corrigir, e a solução que ela achou melhor foi simplesmente instanciar um novo ObjectMapper para o serviço usar:

OBS: acho que aqui ela desistiu de ajustar a injeção do bean e foi pelo caminho mais fácil 🤣.

Ajustando esse problema, consegui colocar de pé a aplicação e testar os endpoints que não dependiam da IA, como criar Locais e listá-los, e tudo estava bem funcional.

Autenticação

Foi implementada uma autenticação bem simples (a Basic Auth, como você deveria imaginar) onde eu configurava usuário e senha via application.yaml mesmo, e a cada requisição eu preciso do Header com a devida autenticação.

Briga com o H2

Como eu estava usando o H2, queria verificar se a estrutura de tabelas foi criada corretamente, tentei acessar o /h2-console e bati com a cabeça na parede: o navegador ficava infinitamente me pedindo usuário e senha por conta do Basic Auth.

Logo pensei que tivesse algum problema no Filter que confere as autenticações, mas tudo que parecia em ordem. Revisei as configurações no application.yaml, fiz alguns ajustes e também não consegui acessar. Logo, pedi para quem fez descobrir o problema e me explicar.

Meus amigos, aqui a LLM ficou muito perdida! Tentamos umas 5 correções diferentes e ela errou com sucesso! Até que ela conseguiu identificar corretamente o ponto de erro: A versão 4 do Spring Boot colocou em um módulo separado a autoconfiguração do /h2-console, sendo necessário importar a lib que contém esse módulo para funcionar.

Como se trata de uma versão mais nova do Spring Boot, ela errou muito até chegar num diagnóstico coerente e assertivo, me lembrando que IA's sempre terão muita dificuldade com o que é novo. Fiquei tão decepcionado que dei uma bronca nela.

OBS: acho importante ressaltar que usei o Gemini para essa correção, o que pode trazer mais motivos para a dificuldade na resolução.

Configurando nossa IA Backend

Agora era chegada a hora de aplicar nossa regra de negócio de milhões: deixar que a IA tome a decisão de guardar ou não o produto.

Configurei o Mistral para ser acionado, e aproveitei e dei uma revisada no código implementado (principalmente na parte do Spring AI, que não conhecia até então), e a implementação contava até com proteção contra Prompt Injection!

Essa limpeza é feita em todos os lugares que o usuário consegue mandar uma informação de texto livre (nome do Produto, nome do Local...), colocando uma camada extra de segurança no projeto. Claro que não está completo, mas já é um bom começo.

Hora da verdade: acionando os endpoints com decisão da IA

Comecei testando o endpoint responsável por guardar um Produto em um Local, e funcionou de primeira! Achei tão impressionante que revi o código, para ver se estava sendo a IA responsável por liberar ou não, e era ela mesma!

Do ponto de vista de funcionalidade...

O que mais achei interessante aqui, é que toda resposta de erro retornada por querer guardar uma quantidade maior de produtos que o local comporta era diferente, porque além de aprovar ou não, ela também devolve uma justificativa.

Já o restante não era tão bom... O tempo de resposta fica consideravelmente maior por termos de interagir com a IA, e isso fica muito nítido quando tentamos guardar um produto que não existe, que é barrado antes de ser enviado para ela, e nos da uma resposta quase que instantânea. De qualquer forma, essa demora acaba não atrapalhando tanto.

Do ponto de vista de implementação...

A LLM foi literal demais neste endpoint de guardar produtos, pois o produto é salvo no banco a parti deste endpoint. E olha só que zona ficou essa implementação:

• São consultados todos os produtos cadastrados no banco;

• É verificado se existe algum produto com o mesmo nome enviado para o endpoint;

• Não havendo, ele salva esse Produto;

• Somente ai que ele vai pegar a soma da quantidade de Produtos guardados no Local (caso ele exista) e repassar esses dados para ela decidir se pode guardar ou não, de acordo com a capacidade máxima do estoque;

Eu fiquei boquiaberto com o quanto isso ficou esquisito. Isso significa que a cada vez que eu quisesse guardar um produto, eu consultoria TODOS os Produtos, e passaria UM POR UM para poder achar um que tivesse o mesmo nome, tendo uma grande chance de fazer tudo isso atoa por não ter o produto cadastrado ainda.

Não podia deixar isso assim, e parti para a refatoração desse fluxo, buscando separar o cadastro do produto em um enpoint separado, só para isso.

Nessa missão, envolvi o Gemini, onde passei o seguinte prompt para ele:

Quero que você implemente um POST para tornar possível cadastrar um produto na base de dados. Remova a lógica de cadastro que tem no endpoint POST /api/products que faz o cadastro do produto ao colocar o produto no local.

O que ele me entregou foi o POST que pedi, conforme o esperado, mas ele ainda não havia removido aquele trecho que percorria todos os Produtos, mesmo tendo feito algumas alterações pouco relevantes na implementação desse serviço. Foi aqui que tive uma ideia: trocar de modelo para ver se o Claude se saia melhor que o Gemini.

Troquei de modelo e colei o mesmo prompt, e olha só que interessante:

O modelo conseguiu identificar sozinho que ele poderia usar o ID do produto, e não seu nome, para verificar se ele existe.

O Gemini não conseguiu ter essa sagacidade, sendo que passei o mesmo prompt para ambos.

Isso me traz a impressão direta de que o Claude oferece uma visão mais crítica de programação do que o Gemini. Claro que só isso é pouco para levar isso como certeza absoluta, mas já é algo que faz a gente pensar a respeito.

Considerações finais

Com os poucos testes que fiz, já da para tirar alguns insights interessantes sobre como é desenvolver com IA e usá-la em nossas regras de negócio, porém ainda não fiz tudo que planejei para esse projeto.

Pretendo colocar mais decisões e partes do serviço a cargo da LLM, e na medida que eu for melhorando esse projeto, vou atualizando você por aqui.

Até aqui, fica a reflexão de como essa ""arquitetura"" mexe com a experiência do usuário final, assim como os meios de programar essa solução podem trazer reflexões interessantes sobre como comportamento dos modelos e funções podem agregar na nossa rotina de desenvolvimento.

Muito obrigado por me acompanhar nessa jornada, e prometo que trarei novas funcionalidades para o projeto, com a IA sendo usada de maneiras inimagináveis, onde vamos testar seus limites.

Alguém já se desafiou para conseguir rodar uma LM local com o mínimo de GB disponível?

Eu desenvolvi uma aplicação (ainda embrionária) de linha de comando (CLI) open-source voltada para o mercado jurídico, projetada especificamente para oferecer 100% de privacidade, total isolamento de rede (100% offline e air-gapped) usando LLM local (ollama) focado em baixo consumo de RAM.

O objetivo é partir para uma interface de chat, mas o MVP roda perfeitamente em CLI. Mas a quantidade de desfaios que encontrei foi MUUUUUITO maior que qualquer accesso a API da OpenRouter, OpenCode ou qualquer serviço API de LLM.

Os tradeoffs e as renúncias me esmagaram!

Motivo? Fazer rag em 1 PDF com assunto corrido diverso é fácil.

Fui fazer RAG com 1000 processos que são praticamente um template um do outro, onde tentei alcançar a qualidade entre chunking e embbeding até o banco de dados vetorial usando uma LLM ultra leve (que roda com menos de 4GB de RAM) foi o que pude chamar de problema.

Uma coisa é ter uma GeForce RTX 5090 ou Arc Pro B70 com 32GB de RAM ali, disponível. Outra coisa é o PC médio de usuários comuns.

Meu objetivo aqui é um experimento, não para salvar o mundo. Apenas tentar esbarrar no mínimo, no escasso para entender como poder criar aplicações usando inteligência artificial usando o mínimo da média.

Pensei em criar uma interface gráfica, com UI minimalista pensando no advogado solo, no advogado 60+ e para isso, oferecer privacidade 100% dos dados e exigir o mínimo de memmória (a média tem um notebook com 8GB) que rode com os menores modelos disponíveis.

E está funcionando. Rodando liso.
Quem precisar pode baixar no repositório.

Se alguém souber como melhorar isso, ficarei feliz!

Opa galera, enquanto eu estava programando aqui, me deparei com um problema que a gente sempre passa: precisar de um comando bem especifico que demos no terminal um, dois, três ou mais dias atrás, mas ser incapaz de o encontar na suprema setinha para cima do terminal (aquela que vai passando o histórico de comandos efetuados).

Nisso, pensei quase que instantâneamente numa solução que seria muito bacana de criar: o terminal inteligente. Basicamente um terminal com IA e RAG leve, onde você pudesse, diretamente no terminal, escrever algo como "comando que eu dei para executar X tarefa", e a IA iria procurar em todo o seus milhões de comandos via RAG e te retornar uma lista dos comandos mais prováveis. Ai você só escolheria rapidamente qual executar, tipo "1" e pimba, deu o comando. E sim, me refiro ao terminal puro, sem ser terminal de IDE que já tem um alto complete. Mas acho que em muitos casos seria útil em qualquer terminal, mesmo os com auto complete.

Não sei se algo do tipo existe e no momento não tenho tempo hábil para criar, mas talvez fosse muito prático e uma solução interessante.

Daria para rodar tranquilamente até em PC's fracos, só precisa de um modelo de embbeding levinho, um de 600M já dá conta, e um modelo de 1B talvez já seria o suficiente, mas com garantia um de 2B teria um ótimo resultado. Tudo na memória RAM.

Embbeding para registrar os comandos com significados semânticos, e IA para pesquisar e processar os embbedings e decidir qual os comandos mais prováveis. Ou, se bobear, só um modelo de embbeding maior, de 1B, já seria o suficiente mesmo, sem o modelo de IA, já que ele por si só entende pesquisa e significado.

Apenas uma ideia para aventureiros de soluções que ninguém pediu mas que talvez sejam maneiras na prática

Semana passada abri o repositório de um produto que passou por vários freelancers ao longo de uns três anos. Fui atrás de um bug num e-mail de redefinição de senha e, no caminho, dei de cara com três funções diferentes mandando e-mail: cada uma escrita por uma pessoa que nunca leu as outras duas.

Não é preguiça de ninguém. Quando você entra num projeto por duas semanas, ler trinta arquivos pra descobrir que já existe um mailer pela metade não cabe no prazo. Escrever um novo é mais rápido e mais seguro pra quem vai embora. O problema é que isso vai empilhando, e um dia você conserta um bug num lugar e ele reaparece em dois outros que eram cópias.

Se você desconfia que tem disso na sua base, dá pra checar em uns 20 minutos, sem ferramenta paga:

• grep pelos verbos do domínio: sendMail|sendEmail|mailer|notify. Se voltam nomes diferentes fazendo a mesma coisa, achou.
• Cace os utilitários repetidos: formatação de data, conversão de moeda, validação de CPF ou e-mail. Quase sempre têm 2 ou 3 versões.
• Rode um detector de clones: npx jscpd ./src (Node) ou PMD CPD (Java e outras linguagens). Em minutos ele cospe a % de duplicação e aponta os blocos.
• Olhe quem passou por ali: git log --format='%an' | sort | uniq -c. Muitos autores com pouca sobreposição no tempo é sinal de memória do sistema perdida a cada troca de pessoa.

O custo da duplicação não é disco nem código feio. É a correção que vale pra um pedaço só e deixa os outros quebrados sem avisar ninguém. Você acha que resolveu; o suporte descobre que não.

Escrevi a história completa, com o número do estrago, no blog. Versão completa: https://revin.com.br/pt/blog/paguei-pela-mesma-funcao-tres-vezes

🥇 Lancei mais um side project: SequênciaMaluca

Depois do DigitaRoyale (corrida de digitação multiplayer), resolvi atacar outro clássico dos jogos de festa: o Genius/Simon Says, só que online, multiplayer e direto no navegador.

Como funciona:
🎨 A sequência de cores cresce a cada rodada e fica mais rápida
💀 Errou ou demorou? Eliminado na hora — mas pode continuar assistindo e reagindo com emojis
🔥 Morte súbita quando sobram 2 jogadores
🏆 Rankings mundiais (solo e multiplayer) + recorde da sala
👥 Até 12 jogadores por sala, sem cadastro, sem instalar nada

Por trás do capô: WebSockets para sincronizar o estado em tempo real entre todos os jogadores, com o mesmo stack que venho usando nos meus outros projetos (Node.js/TypeScript).

O objetivo aqui é o mesmo de sempre: criar experiências simples, rápidas de entender e com potencial de viralizar em grupo de amigos — sem fricção de cadastro ou instalação.

Testem e desafiem a galera: https://sequenciamaluca.dantas-dev.com/

Estamos analisando como o AI code review se comporta em fluxos reais de desenvolvimento, usando dados de 140.662 pull requests em 530 organizações.

Alguns resultados nos surpreenderam:

→ 33,2% das sugestões de review feitas por IA resultaram em uma alteração no código.

→ Essa taxa aumentou de aproximadamente 25% para quase 48% ao longo do período analisado.

→ PRs com autoria de IA receberam 1,6x mais apontamentos do que PRs escritos por pessoas.

→ Eles também geraram 2,1x mais violações de regras específicas do time.

→ PRs com autoria de IA foram 2,6x maiores na mediana.

→ 71,8% dos PRs mergeados que receberam algum apontamento foram integrados com pelo menos um problema ainda não resolvido.

Minha principal conclusão é que código gerado por IA não elimina a necessidade de review. Ele aumenta a quantidade de código que os times conseguem produzir, mas também pode amplificar problemas existentes quando o processo de revisão não entende o repositório, a arquitetura e as convenções do time.

Outro ponto interessante é que contexto e regras personalizadas pareceram importar mais do que simplesmente trocar entre diferentes famílias de modelos.

Publicamos a metodologia completa e todos os resultados aqui: https://kodus.io/data/

Durante muito tempo, quando alguém falava em “projeto de portfólio” na área de tecnologia, o caminho mais comum era quase sempre o mesmo: criar um sistema com cadastro, login, listagem, edição e exclusão de registros.

Em outras palavras: um CRUD.

E não há nada de errado com isso.

CRUDs são importantes. Eles ajudam a demonstrar fundamentos, organização de código, integração com banco de dados, validações, autenticação, interface e fluxo básico de uma aplicação.

Mas, depois de alguns anos trabalhando com desenvolvimento, integrações, regras de negócio, infraestrutura, automação e sistemas em produção, comecei a perceber uma limitação nesse tipo de projeto: ele nem sempre mostra como a pessoa pensa arquiteturalmente.

Ele mostra que você sabe implementar telas e endpoints.

Mas nem sempre mostra que você sabe lidar com decisões técnicas mais próximas da vida real.

Por isso, decidi reorganizar meu portfólio público com uma proposta diferente: construir projetos pessoais que sejam pequenos o suficiente para manter, mas ricos o bastante para demonstrar arquitetura, cloud, automação, testes, modelagem de domínio e uso aplicado de IA.

A ideia não é criar “sistemas gigantes”.
A ideia é criar laboratórios técnicos com problemas reais.

O problema dos projetos genéricos

Muitos projetos de portfólio acabam ficando presos a uma estrutura muito parecida:

• cadastro de usuários;
• login;
• tela de listagem;
• formulário de criação;
• botão de editar;
• botão de excluir;
• algum dashboard simples;
• deploy básico.

Isso pode ser suficiente para mostrar conhecimento inicial, mas para quem quer demonstrar senioridade, talvez falte uma camada importante: decisão técnica.

Na prática, sistemas reais costumam exigir perguntas mais complexas:

• Como o domínio está modelado?
• Como os dados evoluem ao longo do tempo?
• Como o sistema reage a eventos?
• Como lidar com falhas?
• Como registrar auditoria?
• Como provisionar infraestrutura?
• Como automatizar validações?
• Como separar regra de negócio de detalhes de framework?
• Como integrar serviços externos sem acoplamento excessivo?
• Como testar comportamentos críticos?
• Como documentar decisões arquiteturais?

Essas perguntas são mais difíceis de demonstrar em um CRUD genérico.

Por isso, comecei a pensar em projetos de portfólio menos como “aplicações para mostrar tela” e mais como laboratórios de engenharia de software.

O que quero demonstrar

Meu objetivo com esses projetos é validar algumas competências que considero importantes para desenvolvimento backend, fullstack, cloud e automação:

• modelagem de domínio;
• arquitetura orientada a eventos;
• TypeScript aplicado a regras de negócio;
• infraestrutura como código;
• uso de serviços cloud;
• CI/CD;
• testes automatizados;
• observabilidade e auditoria;
• integração com IA de forma desacoplada;
• documentação de decisões técnicas;
• construção de produto com escopo controlado.

A ideia é que cada projeto público consiga responder a uma pergunta técnica clara.

Por exemplo:

Como modelar um fluxo financeiro assíncrono usando eventos?

Ou:

Como integrar IA a um produto sem deixar a regra de negócio presa em prompts soltos?

Ou ainda:

Como organizar campanhas, conteúdo, métricas e aprendizado em um sistema de crescimento?

Essas perguntas tornam o projeto mais interessante do que simplesmente mostrar uma lista de registros no banco.

Projeto pessoal não precisa ser pequeno demais

Existe uma armadilha comum em portfólio: achar que projeto pessoal precisa ser extremamente simples para ser finalizado rápido.

Eu concordo que o escopo precisa ser controlado. Mas controlado não significa superficial.

Um projeto pequeno pode ter boas decisões arquiteturais.

Ele pode ter:

• domínio bem definido;
• eventos tipados;
• testes de regras de negócio;
• documentação clara;
• diagrama de arquitetura;
• pipeline de CI;
• Terraform;
• separação entre aplicação e infraestrutura;
• logs estruturados;
• decisões registradas em ADRs.

Nada disso exige um sistema enorme.

O segredo é escolher um recorte pequeno, mas tratá-lo com seriedade.

Laboratório 1: arquitetura orientada a eventos com AWS

Um dos projetos que pretendo construir é um laboratório técnico de portabilidade de crédito usando arquitetura orientada a eventos.

A proposta é criar uma simulação educacional de um fluxo financeiro com múltiplas etapas, mudança de estados, eventos assíncronos e trilha de auditoria.

A stack planejada inclui:

TypeScriptAWS EventBridgeAWS LambdaAmazon SQSDynamoDBTerraformGitHub ActionsVitest

O objetivo não é implementar uma especificação oficial ou reproduzir um sistema regulatório real. A ideia é usar um domínio financeiro como base para explorar conceitos técnicos importantes.

Um fluxo simplificado poderia ser:

Cliente solicita portabilidade        ↓API registra solicitação        ↓Evento: portability.request.created        ↓EventBridge roteia o evento        ↓Workers processam etapas assíncronas        ↓Status da solicitação é atualizado        ↓Eventos de auditoria são registrados

Alguns eventos possíveis:

portability.request.createdconsent.authorizedsource.institution.notifiedcredit.contract.loadedproposal.createdproposal.acceptedportability.completedportability.rejectedportability.failed

Esse tipo de projeto permite demonstrar vários pontos relevantes:

• desenho de eventos;
• separação entre comandos e eventos;
• processamento assíncrono;
• roteamento com EventBridge;
• filas com SQS;
• funções Lambda;
• persistência em DynamoDB;
• provisionamento com Terraform;
• auditoria;
• idempotência;
• tratamento de falhas;
• automação de infraestrutura.

É muito mais interessante tecnicamente do que apenas cadastrar propostas em uma tabela.

Terraform como parte do projeto, não como detalhe

Outro ponto importante é tratar infraestrutura como parte do código.

Em vez de apenas criar recursos manualmente no console da AWS, a ideia é provisionar tudo com Terraform.

Isso torna a arquitetura mais explícita e reprodutível.

Um projeto assim poderia ter uma estrutura como:

credit-portability-event-lab/  apps/    api/    workers/  packages/    domain/    events/  infra/    terraform/      main.tf      variables.tf      outputs.tf      modules/        eventbridge/        lambda/        sqs/        dynamodb/        iam/  docs/    architecture.md    event-catalog.md    decisions/  .github/    workflows/      ci.yml      terraform-plan.yml

A infraestrutura deixa de ser algo “fora do projeto” e passa a fazer parte da entrega técnica.

Isso também ajuda quem está avaliando o repositório a entender não apenas o código da aplicação, mas o ambiente onde ela roda.

Laboratório 2: IA aplicada sem acoplamento a prompts

Outro tema que quero explorar é IA aplicada em produtos.

Hoje é relativamente simples adicionar uma chamada para um modelo de IA dentro de uma aplicação. Mas integrar IA de forma responsável exige mais do que montar um prompt e esperar uma resposta.

Algumas perguntas importantes aparecem rapidamente:

Como trocar de provedor de IA sem reescrever o produto?
Como validar entradas e saídas?
Como auditar o contexto usado?
Como evitar que regra de negócio fique escondida dentro de prompts?
Como lidar com fallback?
Como testar fluxos sem depender de chamadas reais?
Como separar intenção do usuário da execução técnica?

Uma abordagem possível é tratar IA como uma capacidade arquitetural.

Em vez de o produto pensar diretamente em um prompt como:

"Gere um roteiro para um vídeo de campanha" 

ele poderia trabalhar com uma intenção estruturada:

intent: generate_content_briefcontext:  campaign: ...  audience: ...  objective: ...constraints:  platform: instagram_reels  format: short_video  tone: ...output:  type: structured_brief 

Com isso, a aplicação não fica presa a um texto solto ou a um fornecedor específico. Ela passa a operar sobre contratos.

Esse tipo de abordagem permite criar:

• adapters para diferentes provedores;
• provedores mock para testes;
• fallback entre modelos;
• normalização de resposta;
• logs estruturados;
• métricas de custo e latência;
• validação com schemas.

Esse é um dos pontos que mais quero destacar nos meus projetos: IA não como mágica, mas como engenharia de software.

Laboratório 3: produto e crescimento

Além da parte de cloud e IA, também quero construir um projeto voltado a produto: um sistema para organizar campanhas, conteúdo, briefs, métricas e aprendizados.

A ideia é partir de uma dor comum: muita gente produz conteúdo, testa campanhas e usa ferramentas diferentes, mas o histórico fica fragmentado.

O sistema teria conceitos como:

CampaignContentPlanContentObjectiveContentAiBriefKnowledgeItemStorySequenceMetricLearning

O objetivo seria responder perguntas como:

• quais campanhas estão em andamento?
• quais conteúdos precisam ser produzidos?
• quais conteúdos estão atrasados?
• qual objetivo cada conteúdo atende?
• quais ideias ainda precisam virar roteiro?
• quais conteúdos foram publicados?
• o que aprendemos com os resultados?
• que tipo de conteúdo vale repetir?

Esse projeto seria menos sobre cloud pesada e mais sobre modelagem de domínio, produto, UX, TypeScript, Next.js, Prisma e IA aplicada.

A stack poderia ser:

Next.jsReactTypeScriptPrismaPostgreSQLTailwindshadcn/uiVitest

Ele serviria como laboratório para demonstrar construção de produto completo, sem depender de infraestrutura complexa.

O que diferencia esses projetos

A principal diferença entre esses projetos e um CRUD tradicional não está apenas nas tecnologias usadas.

Está na intenção.

Um CRUD normalmente demonstra implementação.

Esses projetos tentam demonstrar decisões.

Decisões como:

• por que usar eventos?
• onde persistir estado?
• como versionar contratos?
• o que deve ser síncrono ou assíncrono?
• quais falhas precisam ser previstas?
• como auditar uma decisão?
• como separar domínio de infraestrutura?
• como testar regra de negócio?
• como evitar acoplamento com fornecedor?
• como manter o escopo pequeno sem perder valor técnico?

Essas decisões são mais próximas do trabalho real de engenharia.

Documentação também faz parte do portfólio

Um ponto que quero levar mais a sério é a documentação.

Não adianta publicar um repositório com código interessante se ninguém entende rapidamente:

• qual problema ele resolve;
• como rodar localmente;
• qual arquitetura foi escolhida;
• quais decisões foram tomadas;
• quais trade-offs existem;
• quais são os próximos passos.

Por isso, cada projeto deve ter, no mínimo:

README.mddocs/architecture.mddocs/event-catalog.mddocs/decisions/docs/roadmap.md

Também pretendo usar ADRs para registrar decisões arquiteturais importantes.

Um ADR simples pode responder:

1. qual era o contexto;
2. qual decisão foi tomada;
3. quais alternativas foram consideradas;
4. quais consequências essa decisão traz.

Isso ajuda a mostrar raciocínio técnico, não apenas código final.

CI/CD e qualidade

Outro ponto importante é automação.

Mesmo em projeto pessoal, quero incluir pipelines básicos de validação:

linttypechecktestbuildterraform fmtterraform validateterraform plan

Isso mostra cuidado com qualidade e reprodutibilidade.

Um fluxo simples de CI com GitHub Actions já é suficiente para demonstrar maturidade técnica.

A ideia não é criar burocracia, mas deixar claro que o projeto foi pensado como software que pode evoluir.

O que eu espero aprender

Esses projetos também são uma forma de estudo.

Quero aprofundar alguns temas específicos:

• EventBridge em cenários de integração;
• desenho de catálogos de eventos;
• Terraform modular;
• arquitetura serverless;
• testes de domínio em TypeScript;
• integração segura com IA;
• modelagem de produto;
• separação entre aplicação, domínio e infraestrutura;
• observabilidade mínima;
• documentação técnica para projetos públicos.

O objetivo não é fingir que um projeto pessoal substitui um ambiente real de produção.

Não substitui.

Mas um bom projeto pessoal pode mostrar como uma pessoa pensa, organiza problemas e toma decisões.

E isso tem muito valor.

Como pretendo publicar

A ideia é manter os projetos públicos no GitHub, com documentação e evolução incremental.

Também pretendo compartilhar alguns aprendizados em artigos e posts técnicos, mostrando o processo de construção:

• escolha do domínio;
• desenho da arquitetura;
• definição dos eventos;
• criação da infraestrutura;
• testes;
• erros encontrados;
• ajustes de escopo;
• decisões que mudaram no caminho.

Mais do que postar apenas o resultado final, quero mostrar a construção.

Porque, na prática, engenharia de software é muito mais sobre processo e tomada de decisão do que sobre uma tela pronta.

Conclusão

Projetos pessoais podem ser mais do que exercícios de CRUD.

Eles podem ser laboratórios para validar arquitetura, cloud, automação, produto e IA aplicada.

Não precisam ser enormes.
Não precisam tentar resolver o mundo.
Mas precisam ter intenção técnica clara.

No meu caso, quero usar esses projetos para demonstrar como penso sistemas: partindo de domínio, passando por arquitetura, infraestrutura, testes, automação e documentação.

No fim, o que quero mostrar não é apenas que sei escrever código.

Quero mostrar que sei construir software com contexto, decisão e propósito.