Jobmaker-LdPost/seed/_sugestoes.md

# Seed de Sugestões — ldpost-squad
# 30 posts baseados em experiências reais de Ricardo
# Formato: ## slug → campos **Chave:** Valor
# Copie para: C:\Textos-Linkedin\_inbox\_sugestoes.md

---

## templates-propostas-comerciais

**Categoria:** Entregavel
**Tema:** Como criei templates com indicadores substituíveis que mantêm a aparência das minhas propostas comerciais
**Formato:** como
**Funil:** meio
**Resumo:** Toda vez que eu precisava montar uma proposta comercial eu perdia tempo reformatando. Criei um sistema de templates Word/Google Docs com marcadores no estilo {{CLIENTE}}, {{VALOR}}, {{PRAZO}}, {{ESCOPO}} que são substituídos automaticamente. O resultado mantém sempre a mesma identidade visual profissional. Tenho prints mostrando a proposta antes (bagunçada, cada uma diferente) e depois (todas com a mesma cara). Economizo em média 45min por proposta. A substituição pode ser feita manualmente ou via script simples.
**Imagem 1:** Antes e depois: duas propostas comerciais lado a lado — esquerda com formatação inconsistente, direita com template padronizado e profissional, fundo branco com elementos em azul corporativo
**Imagem 2:** Template com marcadores coloridos em destaque {{CLIENTE}}, {{VALOR}}, {{PRAZO}} visíveis no documento, estilo minimalista, clean, profissional

---

## templates-docs-arquitetura

**Categoria:** Codigo
**Tema:** Template de documento de arquitetura com indicadores substituíveis — o que aprendi depois de 50+ ADRs
**Formato:** como
**Funil:** meio
**Resumo:** Depois de escrever mais de 50 Architecture Decision Records e documentos de design técnico, identifiquei os campos que são sempre os mesmos: contexto, decisão, alternativas consideradas, consequências. Criei um template Markdown com marcadores {{SISTEMA}}, {{DATA}}, {{DECISÃO}}, {{CONTEXTO}}, {{ALTERNATIVAS}} e {{TRADE_OFFS}}. O que mudou: novos devs conseguem escrever o primeiro ADR sem me perguntar como fazer. Tenho prints comparando um ADR escrito do zero vs um usando o template — qualidade e completude notavelmente diferentes.
**Imagem 1:** Documento de arquitetura técnica aberto no editor com seções bem delimitadas: Contexto, Decisão, Alternativas, Trade-offs — paleta azul/cinza tech, estilo clean
**Imagem 2:** Diagrama de fluxo: engenheiro recebe template → preenche campos → ADR pronto e revisável — ícones geométricos, sem rostos, estilo flat design

---

## templates-planilhas

**Categoria:** Entregavel
**Tema:** Templates de planilha com indicadores substituíveis: como padronizei relatórios que antes levavam 3h
**Formato:** como
**Funil:** meio
**Resumo:** Eu mantinha planilhas de acompanhamento de projetos, orçamentos e métricas de time. Cada uma era criada do zero e ficava diferente das outras. Criei templates com células nomeadas e fórmulas que referenciam essas células pelo nome (ex: =PROJETO_BUDGET * 1.1). Quando mudo o nome do projeto em uma célula, tudo atualiza. Tenho prints das planilhas antes e depois. O processo de criação de relatório mensal caiu de ~3h para ~40min. A chave foi usar Named Ranges em vez de referências diretas (A1, B2) — isso é o que permite a substituição sem quebrar fórmulas.
**Imagem 1:** Planilha de acompanhamento de projeto com células nomeadas destacadas em amarelo e fórmulas visíveis referenciando nomes, não coordenadas — estilo profissional, cores neutras
**Imagem 2:** Comparação lado a lado: planilha antiga com fórmulas hardcoded vs nova com Named Ranges — seta no centro indicando evolução, fundo branco

---

## criar-textos-voz-propria

**Categoria:** Bastidor
**Tema:** Como treinei a IA para escrever no meu tom — sem fine-tuning, só com prompts certos
**Formato:** como
**Funil:** topo
**Resumo:** Precisava que a IA gerasse textos que soassem como eu escrevo: direto, sem enrolação, técnico mas acessível, sem frases corporativas. Em vez de fine-tuning (caro e lento), usei uma abordagem de few-shot com exemplos meus reais no system prompt. O truque foi: 5 exemplos curtos de parágrafos que eu escrevi + lista explícita de frases que EU NUNCA USARIA (como "no cenário atual", "é importante destacar", "mergulho profundo"). Resultado: 80% dos rascunhos gerados precisam de menos de 3 ajustes antes de publicar.
**Imagem 1:** System prompt aberto em editor de código com seção "ESTILO DO AUTOR" contendo exemplos reais e lista de proibições — fundo escuro, código limpo
**Imagem 2:** Comparação: texto genérico da IA vs texto no estilo do autor — mesma informação, ton completamente diferente, dois blocos de texto lado a lado com contraste visual

---

## fluxo-trabalho-ia-conteudo

**Categoria:** Geral
**Tema:** O fluxo de trabalho que uso com IA para criar conteúdo técnico — explica, analisa, complementa, repete
**Formato:** checklist
**Funil:** topo
**Resumo:** Desenvolvi um fluxo iterativo para criar conteúdo com IA que evita o problema comum de "a IA inventou". O ciclo: (1) eu explico o que fiz com minhas palavras, (2) peço para a IA analisar e identificar gaps no meu raciocínio, (3) ela complementa com contexto técnico que eu não havia mencionado, (4) eu reviso e corrijo o que ela errou, (5) repito até estar satisfeito. A diferença crucial: eu nunca peço pra ela "criar" — peço pra ela "ampliar" o que eu já escrevi. Isso evita alucinações e mantém minha voz.
**Imagem 1:** Diagrama circular mostrando o ciclo: Escrever → Analisar → Complementar → Revisar → Publicar — cada etapa com ícone simples, setas conectando, paleta tech azul/branco
**Imagem 2:** Tela de chat com IA mostrando o prompt "Analise meu texto e indique o que está impreciso ou incompleto" seguido de resposta estruturada — estilo screenshot limpo, sem conteúdo sensível

---

## rag-conceito-quando-usar

**Categoria:** Codigo
**Tema:** RAG: o que é, quando usar e quando NÃO usar — sem hype
**Formato:** porque
**Funil:** topo
**Resumo:** RAG (Retrieval-Augmented Generation) virou buzzword mas poucos explicam quando ele realmente faz sentido. Usei RAG em 4 projetos diferentes: um funcionou muito bem (consulta de documentação interna), dois funcionaram razoavelmente (FAQ de produtos), um foi um fracasso total (código-fonte indexado sem chunking adequado). O padrão que aprendi: RAG funciona quando o usuário faz perguntas sobre documentos que EXISTEM e foram indexados. Não funciona como substituto de fine-tuning, não funciona com chunks grandes demais, não funciona quando a qualidade dos documentos originais é baixa. O erro mais comum: achar que indexar tudo resolve — na verdade piora.
**Imagem 1:** Diagrama de arquitetura RAG: Documento → Chunker → Embedder → Vector DB → Query → Retriever → LLM → Resposta — setas claras, ícones geométricos, fundo branco
**Imagem 2:** Tabela de decisão: "Use RAG quando..." vs "NÃO use RAG quando..." — duas colunas com checkmarks verdes e X vermelhos, design limpo

---

## rag-csharp-semantic-kernel

**Categoria:** Codigo
**Tema:** Construí RAG local em C# com Semantic Kernel — e a IA quase quebrou tudo usando APIs em PREVIEW
**Formato:** erro
**Funil:** fundo
**Resumo:** Pedi para a IA me ajudar a construir um RAG local com C# .NET 8 + Semantic Kernel 1.x. Ela gerou código que compilava perfeitamente. O problema: o Semantic Kernel tinha dezenas de recursos marcados como [Experimental] e [Preview] nas versões 1.x, e a IA usou todos eles sem avisar. Entre uma versão minor e outra, as assinaturas mudavam, interfaces sumiam, namespaces se reorganizavam. Tive que estudar o changelog manualmente, identificar o que era estável vs preview, e reescrever partes inteiras do código. O resultado final funcionou: pipeline RAG local sem custo, 380ms de latência, zero dependência de API externa. Mas o trabalho humano de navegar as versões instáveis não foi opcional — foi o que separou um projeto funcionando de um projeto que compilava mas quebrava em runtime.
**Imagem 1:** Comparação de duas versões de código C#: gerado pela IA (usando APIs [Experimental]) vs versão final corrigida (usando apenas APIs estáveis) — diff visual, vermelho/verde, fundo escuro
**Imagem 2:** Diagrama do pipeline RAG local que ficou no final: PDF → PdfPig → Chunker → nomic-embed-text (Ollama) → Qdrant → Query → Semantic Kernel (estável) → Llama 3.1 → Resposta

---

## fine-tuning-tom-modelo

**Categoria:** Codigo
**Tema:** Fine-tuning parece fácil até você descobrir que a parte difícil é 100% trabalho humano
**Formato:** porque
**Funil:** meio
**Resumo:** Queria um modelo que respondesse em português brasileiro, direto, sem floreios corporativos. A IA faz o fine-tuning em horas — esse não era o problema. O problema era o dataset: 400 pares de pergunta/resposta no meu estilo, que eu tive que escrever. Levou 3x mais tempo que o fine-tuning em si. Nenhuma IA pode fazer isso por mim — ela não sabe como eu escrevo, quais expressões eu uso, o que eu jamais diria. O que aprendi: fine-tuning de tom funciona bem com ~200-500 exemplos de qualidade. Abaixo de 100, o modelo "esquece" o estilo em prompts mais longos. Acima de 2000, começa catastrophic forgetting no conhecimento base. O trabalho técnico (treinamento, merge, quantização GGUF) levou 2h. O trabalho humano (escrever os exemplos) levou 3 dias. Quem acha que IA automatiza tudo ainda não fez fine-tuning sério.
**Imagem 1:** Gráfico de tempo: proporção do projeto — Dataset (humano, 72h) vs Fine-tuning (máquina, 2h) — barras contrastantes mostrando onde o tempo real foi
**Imagem 2:** Pipeline de fine-tuning: Dataset (JSONL) → Validação → Training (Unsloth) → Merge → Quantização (GGUF) → Teste — destacando em vermelho a etapa Dataset como gargalo humano

---

## fine-tuning-guardrail

**Categoria:** Codigo
**Tema:** Criei um guardrail de IA com fine-tuning — e o modelo só funciona porque eu classifiquei 800 exemplos à mão
**Formato:** porque
**Funil:** fundo
**Resumo:** Precisava filtrar respostas inaceitáveis do meu LLM no contexto específico do meu produto. Guardrails genéricos da OpenAI têm 87% de acurácia no meu domínio — bom, mas não suficiente. A solução: fine-tuning de um modelo pequeno (Phi-3 Mini) especificamente para o meu contexto. O que a IA fez: treinamento, validação, deploy — automático. O que eu fiz: classifiquei 800 exemplos reais (resposta + label: ok/bloqueado) em 2 tardes de trabalho manual. Sem esse trabalho humano de rotulagem, o modelo não existe. O resultado valeu: 94% de acurácia no meu domínio, 50ms de latência, custo zero por chamada. A lição: modelos de IA especializados são melhores que genéricos — mas alguém precisa ensinar o que é "certo" no seu contexto. Essa pessoa é você, não outra IA.
**Imagem 1:** Diagrama de arquitetura: Usuário → LLM Principal → Saída → Guardrail (Phi-3 Mini fine-tuned) → OK/Bloqueado → Resposta — fluxo com bifurcação, destaque no "fine-tuned por humano"
**Imagem 2:** Tabela comparativa: Guardrail próprio vs API externa OpenAI — linhas: custo, latência, acurácia no domínio, trabalho de setup — design minimalista

---

## mlnet-quando-usar

**Categoria:** Codigo
**Tema:** ML.NET em 2026: quando faz sentido e quando é overkill — minha experiência em 3 projetos
**Formato:** porque
**Funil:** meio
**Resumo:** Usei ML.NET em 3 projetos reais de .NET: (1) classificação de tickets de suporte por categoria — funcionou ótimo, modelo treinado em 2h, 89% de acurácia com 1500 exemplos; (2) previsão de churn de clientes — razoável, AUC 0.81; (3) geração de texto personalizado — fracasso total, ML.NET não é LLM, eu estava tentando usar ferramenta errada. O resumo: ML.NET faz sentido quando o problema é classificação, regressão ou forecasting, você tem dados tabulares ou texto simples, e não quer depender de APIs externas. Não faz sentido para geração de linguagem — aí é Ollama/Groq/OpenAI.
**Imagem 1:** Diagrama de decisão em árvore: "Qual ferramenta de ML para .NET?" com branches para ML.NET (tarefas clássicas) vs ONNX Runtime (modelos pré-treinados) vs API LLM (geração/raciocínio) — design clean
**Imagem 2:** Screenshot de código C# com ML.NET: pipeline de treino com IDataView, transformações e treinamento de classificação — fundo escuro, código limpo e legível

---

## squad-ia-postagens-linkedin

**Categoria:** Bastidor
**Tema:** Construindo uma squad de agentes de IA pra automatizar minhas postagens no LinkedIn — o que funciona
**Formato:** bastidor
**Funil:** topo
**Resumo:** Estou construindo um sistema de 6 agentes Go que automatizam o pipeline de criação de posts LinkedIn: evaluator (busca trends + sorteia formato), redator (gera rascunho), editor (formata para LinkedIn com loop interativo), art (gera imagens via Gemini), director (aprovação via Telegram) e publisher (posta via API). Cada agente é um CLI independente que se comunica via arquivos JSON no workspace. O estado atual: 6 agentes funcionando, testados individualmente. O maior desafio foi o loop de revisão do editor — como manter controle humano sem tornar o processo tedioso. Solução: terminal interativo com opções [A]provar/[R]eprovar/[A1-A4] ajustes específicos.
**Imagem 1:** Diagrama da arquitetura da squad: 6 boxes conectados por setas (evaluator → redator → editor → art → director → publisher) com ícones de arquivo JSON entre eles — fundo escuro tech, paleta azul/verde
**Imagem 2:** Terminal mostrando o loop interativo do editor com o post formatado, checklist automático e menu de opções — estilo screenshot real de CLI

---

## squad-ia-blog

**Categoria:** Entregavel
**Tema:** Blog parte humano, parte IA — como mantenho consistência sem perder minha voz
**Formato:** como
**Funil:** meio
**Resumo:** Para o blog, dividi o processo: eu escrevo o núcleo técnico (o que fiz, os números, os trade-offs — coisas que só eu sei), a IA expande com contexto e estrutura, eu reviso e corrijo o que ela inventou. A regra de ouro que adotei: qualquer afirmação técnica específica (versão de biblioteca, número, nome de API) precisa ter sido dita por mim antes de aparecer no texto final. A IA pode inferir analogias e contexto — não pode inventar fatos. O resultado prático: artigos técnicos de 1500-2000 palavras que antes me levavam 4-6h agora ficam prontos em 1.5-2h, e os leitores frequentemente me dizem "parece muito você".
**Imagem 1:** Fluxo de trabalho: Núcleo técnico (humano) → Expansão e estrutura (IA) → Revisão de fatos (humano) → Publicação — ícones de pessoa e robô alternando, design clean
**Imagem 2:** Diagrama de responsabilidades: o que o humano escreve (números, trade-offs, opiniões) vs o que a IA escreve (contexto, analogias, estrutura) — dois círculos com overlap no centro

---

## apps-ia-fluxo-prompts

**Categoria:** Codigo
**Tema:** Errei feio nas primeiras apps com IA — até entender que o humano precisa especificar antes de codar
**Formato:** erro
**Funil:** meio
**Resumo:** Nas primeiras apps com IA eu começava codando direto: pedia para a IA gerar o código, ela gerava, funcionava. Duas semanas depois precisava ajustar o comportamento — e descobria que o prompt estava hardcoded no meio de 3 arquivos diferentes, sem testes, sem histórico. A IA tinha feito exatamente o que eu pedi: código que funciona. Não fez o que eu precisava: código que eu consigo manter. O erro era meu: eu não havia especificado como queria que o sistema fosse construído, só o que ele devia fazer. O fluxo que adotei depois: (1) escrever o que o agente precisa FAZER em linguagem natural antes de abrir o editor, (2) criar e testar o prompt isoladamente antes de qualquer código, (3) definir casos de teste (entrada → saída esperada), (4) implementar com o prompt como configuração separada, não hardcoded. Parece burocrático. Salvou semanas de retrabalho.
**Imagem 1:** Diagrama do fluxo correto em 4 etapas: Especificação humana → Teste de prompt isolado → Implementação → Ajuste iterativo — destaque na etapa 1 como etapa que a IA não faz por você
**Imagem 2:** Comparação: código com prompt hardcoded (caos de manutenção) vs prompt em arquivo de configuração separado e versionado — diff visual, fundo escuro

---

## qdrant-vs-mongodb-rag

**Categoria:** Codigo
**Tema:** Migrei meu RAG de MongoDB Atlas Vector Search para Qdrant — o que mudou de verdade
**Formato:** comparacao
**Funil:** fundo
**Resumo:** Comecei com MongoDB Atlas Vector Search porque já tinha MongoDB no projeto e queria evitar mais um serviço. Funcionou, mas: latência P95 de 820ms nas buscas, configuração de índice vetorial confusa, sem suporte a filtros complexos sem degradação de performance. Migrei para Qdrant rodando via Docker. Resultado: latência P95 caiu para 180ms (4.5x mais rápido), payload filters funcionam sem degradar a busca vetorial, e a API é mais intuitiva para o caso de uso de RAG. O custo: mais um serviço para gerenciar. Para projetos onde MongoDB já existe e o volume é baixo, Atlas Vector Search serve. Para RAG como core feature, Qdrant é superior.
**Imagem 1:** Gráfico de barras comparando latência P95: MongoDB Atlas 820ms vs Qdrant 180ms — cores contrastantes azul/laranja, valores bem visíveis, fundo branco
**Imagem 2:** Tabela comparativa completa: Qdrant vs MongoDB Atlas — linhas: latência, filtros, facilidade de configuração, custo, casos ideais — design limpo, checkmarks e valores

---

## streaming-rag-csharp

**Categoria:** Codigo
**Tema:** Streaming de respostas RAG em C# com SSE — por que abandonei WebSocket e o que aprendi
**Formato:** erro
**Funil:** fundo
**Resumo:** Implementei streaming de respostas do RAG primeiro com WebSocket — parecia a escolha óbvia para comunicação bidirecional em tempo real. O problema: gerenciar conexões WebSocket é complexo (reconexão, heartbeat, estado), e para RAG você só precisa do fluxo de servidor para cliente. Resultado: 340 linhas de código de gerenciamento de conexão para algo que SSE resolve em 40 linhas. Migrei para Server-Sent Events com endpoint HTTP simples que retorna `text/event-stream`. O cliente consome com `EventSource`. Funcionou perfeitamente para o caso de uso — e o código ficou muito mais simples de manter.
**Imagem 1:** Comparação de código C#: endpoint WebSocket complexo (muitas linhas, gerenciamento de estado) vs endpoint SSE simples (poucas linhas, response.WriteAsync) — dois blocos lado a lado
**Imagem 2:** Diagrama de sequência: Cliente → GET /rag/stream → Server inicia streaming → chunks chegando em tempo real → conexão encerra naturalmente — estilo swimlane simplificado

---

## por-que-go-para-cli

**Categoria:** Codigo
**Tema:** Por que escolhi Go (e não Rust, Python ou Node) para construir meus agentes de IA em CLI
**Formato:** porque
**Funil:** topo
**Resumo:** Quando decidi construir a squad de agentes de IA como CLIs independentes, avaliei as opções: Python (óbvio para IA, mas startup lento, dependências pesadas), Node (rápido de escrever, mas carrego npm_modules pra todo lado), Rust (performance máxima, mas velocidade de desenvolvimento baixa para um projeto experimental), Go (binário único sem dependências, startup ~5ms, concorrência nativa com goroutines para chamar múltiplas APIs em paralelo, fácil de compilar para Windows/Linux). O argumento decisivo: Go produz executáveis que funcionam sem runtime instalado — posso distribuir como um .exe que qualquer pessoa roda. Para CLIs que precisam chamar APIs HTTP e processar JSON, Go é imbatível em simplicidade + performance.
**Imagem 1:** Tabela comparativa das 4 linguagens: Python vs Node vs Rust vs Go — critérios: tamanho do binário, startup time, distribuição, concorrência, curva de aprendizado — design limpo
**Imagem 2:** Terminal mostrando os 6 executáveis da squad (ldpost-*.exe) em ~8MB cada, comparado com uma aplicação Node equivalente com node_modules — tamanhos contrastantes, fundo escuro

---

## bot-whatsapp-go

**Categoria:** Codigo
**Tema:** Bot de WhatsApp em Go com whatsmeow — sem Selenium, sem Baileys, sem dor de cabeça
**Formato:** como
**Funil:** meio
**Resumo:** Precisava de um bot WhatsApp para automatizar notificações internas. As alternativas que descartei: Selenium (frágil, quebra com updates do WhatsApp Web), Baileys (Node, manutenção complicada, não é oficial), API oficial do WhatsApp Business (caro para volume baixo, processo de aprovação demorado). Escolhi whatsmeow — biblioteca Go que implementa o protocolo do WhatsApp diretamente. Setup: autenticação via QR code, sessão persistida em SQLite, handlers para mensagens recebidas. Em ~200 linhas de Go tinha um bot funcional enviando e recebendo mensagens. O ponto de atenção: violação de ToS potencial — uso apenas para casos internos, nunca spam.
**Imagem 1:** Diagrama de arquitetura do bot: whatsmeow → handlers Go → SQLite (sessão) → integração com sistema interno — conexão com ícone do WhatsApp (sem logo real), estilo clean
**Imagem 2:** Trecho de código Go com whatsmeow: registro do handler de mensagens e envio de resposta — código legível, ~20 linhas, fundo escuro

---

## qwen-gpu-intel-arc

**Categoria:** Codigo
**Tema:** Rodei Qwen2.5-Coder em GPU Intel Arc com SYCL — o que ninguém te conta antes de tentar
**Formato:** erro
**Funil:** fundo
**Resumo:** Queria usar a GPU Intel Arc A770 que tenho no home lab para inferência local ao invés de só usar CPU. A documentação do llama.cpp com suporte SYCL/Intel existe, mas é esparsa. O que aconteceu: 4h para configurar o ambiente SYCL (Intel oneAPI, drivers específicos, versão correta do llama.cpp), erros crípticos de compilação, e no final a inferência funcionou mas a 60% da velocidade da CPU para o modelo quantizado Q4. O VRAM da Arc A770 (16GB) deveria ser vantagem, mas o overhead de SYCL cancelou os ganhos para modelos pequenos. Conclusão: para modelos acima de 13B parâmetros a GPU começa a compensar. Abaixo disso, CPU com AVX512 ganha.
**Imagem 1:** Gráfico de tokens por segundo: CPU (AVX512) vs GPU Intel Arc SYCL — para modelos 7B, 13B, 34B — mostrando o ponto de crossover onde GPU passa a valer
**Imagem 2:** Terminal com output do processo de build do llama.cpp com suporte SYCL — mensagens de configuração, caminho de compilação, tempo total — estilo real de dev

---

## cli-maluco-bastidor

**Categoria:** Bastidor
**Tema:** O Ollama gera código C# perfeito — e coloca tudo no lugar errado. Por isso usei Roslyn para dar contexto a ele
**Formato:** bastidor
**Funil:** topo
**Resumo:** O CLI-Maluco é um gerador de código C# que usa Ollama (Qwen2.5-Coder) para gerar implementações seguindo os padrões do projeto. O problema que apareceu cedo: a IA gerava código correto mas sem saber onde ele se encaixava — criava Services sem implementar as interfaces certas, ignorava o padrão CQRS que o projeto usava, ou gerava na sequência errada (Controller antes de ter o Service). Solução: usar Roslyn (compilador C# em modo análise) para extrair o AST do projeto e alimentar a IA com contexto real — quais interfaces existem, quais estão sem implementação, quais dependências são necessárias. Agora a IA não "imagina" a arquitetura: ela lê o que existe. Desafio atual: a sequência de geração ainda é hardcoded, estou migrando para Memgraph (banco de grafo*) para deixar o grafo de dependências guiar a ordem. *Banco de grafo: armazena relações entre itens. Ex: [ServiceA] -[:DEPENDE_DE]-> [RepositoryB].
**Imagem 1:** Diagrama do CLI-Maluco: Codebase → Roslyn (lê AST real) → Context Extractor → Ollama/Qwen → Código Gerado → Review humano — destaque em "lê AST real" como diferencial
**Imagem 2:** Exemplo: interface C# sem implementação detectada pelo Roslyn → prompt gerado automaticamente → implementação correta gerada pelo Ollama — três blocos lado a lado

---

## knowledge-graph-step-provider

**Categoria:** Codigo
**Tema:** Por que substituí step provider hardcoded por knowledge graph no meu gerador de código
**Formato:** porque
**Funil:** fundo
**Resumo:** O CLI-Maluco tinha um "step provider" que definia a sequência de geração de artefatos: "primeiro a interface, depois o service, depois o controller". Hardcoded. Funcionava para projetos Clean Architecture padrão, mas quebrava quando a estrutura do projeto era diferente. A solução: usar Memgraph (grafo em memória compatível com Neo4j) para modelar as dependências reais do projeto como um grafo, e deixar o gerador navegar o grafo para descobrir a sequência correta. Se ServiceA depende de RepositoryB que depende de EntityC, o grafo já sabe a ordem. Não precisei mais hardcodar nada. Trade-off: mais complexo de configurar, mas muito mais flexível.
**Imagem 1:** Comparação visual: step provider hardcoded (lista sequencial fixa) vs knowledge graph (rede de nós conectados com dependências reais) — estilo diagrama tech, paleta azul/roxo
**Imagem 2:** Trecho de código C# ou Cypher query no Memgraph mostrando as relações entre artefatos de código — clean, legível, fundo escuro

---

## dataset-finetuning-gerado

**Categoria:** Codigo
**Tema:** Como gerei 1.000 exemplos de dataset para fine-tuning sem escrever 1.000 exemplos
**Formato:** como
**Funil:** meio
**Resumo:** Para fazer fine-tuning de tom do modelo, precisava de pares (pergunta / resposta no meu estilo). Escrever 1000 à mão levaria semanas. A abordagem que funcionou: (1) escrevi 50 exemplos reais de alta qualidade, (2) pedi para um LLM grande (GPT-4) gerar variações — para cada exemplo meu, ele gerava 10 variações da pergunta mantendo o estilo da minha resposta, (3) filtrei manualmente as variações que soavam artificiais (~30% descartado). Resultado: 350 exemplos próprios → 3.500 variações → depois de filtragem: 1.100 exemplos de qualidade aceitável. Tempo total: 2 tardes vs semanas escrevendo tudo. O filtro manual ainda é insubstituível — sem ele a qualidade cai muito.
**Imagem 1:** Diagrama do processo de amplificação de dataset: 50 exemplos reais → GPT-4 gera variações → filtro manual → 1100 exemplos finais — funil visual, com número em cada etapa
**Imagem 2:** Arquivo JSONL de fine-tuning aberto: estrutura com campos "prompt" e "completion" visíveis, formatação correta para API — código limpo, fundo escuro, sem conteúdo sensível

---

## parei-pagar-openai

**Categoria:** Geral
**Tema:** Gastei $80/mês com OpenAI por meses — até entender que eu estava pagando por capacidade que não precisava
**Formato:** porque
**Funil:** topo
**Resumo:** Comecei usando GPT-4 para tudo: geração de texto, código, análise, resumo. $80/mês. Parecia necessário — era o melhor modelo, meus projetos dependiam dele. O que aprendi depois de alguns meses: 90% do que eu usava o GPT-4 para fazer, modelos menores e gratuitos fazem igual. O problema não era o modelo — era eu não saber especificar o problema direito. GPT-4 "consertava" minhas especificações vagas com raciocínio sofisticado. Quando aprendi a especificar melhor, Llama 3.3 70B (Groq, gratuito) passou a resolver. Migrei: Groq para texto, Ollama local (Qwen2.5-Coder) para código, Qdrant local para vector search. O que ainda pago: Gemini API para imagens ($5/mês). Total: de $80 para $5. Qualidade nos meus casos de uso: 85-90% do GPT-4. O que perdi: modelos de reasoning complexo (o1) — mas isso representa menos de 5% do que eu realmente uso.
**Imagem 1:** Gráfico de barras: custo mensal antes ($80 OpenAI) vs depois (Groq $0 + Ollama $0 + Gemini $5) — com nota sobre o que mudou além do custo
**Imagem 2:** Diagrama do stack atual: texto → Groq/Llama, código → Ollama/Qwen, imagens → Gemini, vector → Qdrant — ícones genéricos, layout limpo

---

## orange-pi-cluster-homelab

**Categoria:** Bastidor
**Tema:** Cluster de mini-SaaS no Orange Pi 5: como meu home lab virou laboratório de produtos
**Formato:** bastidor
**Funil:** topo
**Resumo:** Tenho um Orange Pi 5 (8GB RAM, SSD NVMe 256GB) rodando 3 projetos reais: n8ngo (automação de fluxos), qrrapido (gerador de QR codes com analytics), bcards (cartões digitais). Todos containerizados, Traefik como reverse proxy, certificados Let's Encrypt automáticos. O custo de infra: ~R$30/mês de internet + energia elétrica. O que aprendi: Orange Pi com Ubuntu Server + Docker é surpreendentemente estável para workloads leves. O maior problema não foi técnico: foi criar o hábito de monitorar. Uso Uptime Kuma para alertas. Motivação para manter: serve como ambiente de teste real para tecnologias que depois aplico no trabalho.
**Imagem 1:** Diagrama da infraestrutura: Orange Pi 5 → Docker → containers (n8ngo, qrrapido, bcards, Traefik, Qdrant, Ollama) → internet via Traefik com SSL — estilo arquitetura de cloud mas em versão home lab
**Imagem 2:** Dashboard do Uptime Kuma mostrando os serviços e seus status (verde = online) — screenshot limpo, sem dados pessoais visíveis

---

## erro-chunking-qdrant

**Categoria:** Codigo
**Tema:** Indexei todo meu codebase no Qdrant e o RAG ficou inútil — o que aprendi sobre chunking
**Formato:** erro
**Funil:** meio
**Resumo:** Primeiro RAG que construí: peguei todos os arquivos .cs do projeto, dividi por arquivo (um arquivo = um chunk), vetorizei e indexei no Qdrant. Parecia razoável. Na prática: queries sobre "como implementar X" retornavam arquivos inteiros de 800 linhas como contexto, o LLM ficava confuso com muito contexto irrelevante, e a precisão foi horrível. O erro: chunk por arquivo é grande demais. Depois de pesquisar: chunks de 256-512 tokens com overlap de 50-100 tokens funcionam para documentação/texto. Para código: chunk por função/método é muito mais eficaz do que por arquivo ou por linhas fixas. Depois dessa mudança, a precisão do RAG melhorou de ~40% para ~78% nas minhas queries de teste.
**Imagem 1:** Comparação visual de estratégias de chunking: arquivo inteiro (vermelho, ineficiente) vs chunks de 512 tokens (amarelo, razoável) vs chunk por função (verde, melhor) — código representado como blocos coloridos
**Imagem 2:** Gráfico de barras mostrando precisão do RAG com diferentes estratégias de chunking: por arquivo, por linhas fixas, por tokens, por função — valores percentuais claros

---

## legado-aspnet-dotnet8

**Categoria:** Entregavel
**Tema:** De ASP.NET WebForms para .NET 8 sem reescrever tudo — o playbook que funciona
**Formato:** como
**Funil:** meio
**Resumo:** Herdei um sistema ASP.NET WebForms de 2008 em produção. Reescrever do zero: 2 anos de trabalho, risco enorme. A abordagem que adotei: migração incremental por módulos. (1) Identificar os módulos mais usados e menos acoplados, (2) criar um novo projeto .NET 8 rodando em paralelo, (3) usar proxy reverso para direcionar rotas específicas para o novo app, (4) migrar módulo por módulo. Em 14 meses, 70% das funcionalidades estavam no .NET 8. O segredo: nunca deixar o sistema "quebrado" — sempre manter o legado funcionando enquanto migra. O anti-padrão que vi em outros projetos: tentar migrar tudo de uma vez e travar o time por meses.
**Imagem 1:** Diagrama da estratégia de migração incremental: sistema legado + novo sistema rodando em paralelo + proxy reverso roteando por módulo — setas mostrando tráfego dividido, cores diferenciando legado/novo
**Imagem 2:** Timeline de 14 meses com % migrado por mês — gráfico de progresso mostrando avanço gradual sem grandes saltos ou regressões — design limpo

---

## entrevistas-tecnicas-framework

**Categoria:** Entregavel
**Tema:** Como conduzo entrevistas técnicas: o framework que me fez parar de perder horas com candidatos errados
**Formato:** como
**Funil:** topo
**Resumo:** Já conduzi mais de 80 entrevistas técnicas. Os erros que cometi por anos: perguntas de trivia (sabe decoreba de sintaxe?), live coding com problema de LeetCode difícil sob pressão (avalia ansiedade, não competência), entrevista sem estrutura (cada vez diferente). O framework que desenvolvi: 15 min de contexto do projeto real, 20 min de caso prático (resolva um problema parecido com o que você vai resolver no time), 15 min de discussão de decisões técnicas passadas ("me conte uma decisão técnica que tomou e que mudaria hoje"). Sinal verde: candidato explica trade-offs. Sinal vermelho: candidato apresenta solução como "a única certa".
**Imagem 1:** Template da entrevista em três fases: Contexto (15 min) → Caso Prático (20 min) → Decisões Passadas (15 min) — cada fase com bullets do que avaliar, design clean de documento
**Imagem 2:** Tabela de sinais: verde (menciona trade-offs, admite incerteza, faz perguntas) vs vermelho (decoreba, solução única, sem curiosidade) — duas colunas contrastantes

---

## prompts-testaveis-producao

**Categoria:** Codigo
**Tema:** Meu sistema de IA em produção parou de funcionar — e nenhum teste capturou porque eu não tratava prompts como código
**Formato:** erro
**Funil:** meio
**Resumo:** Tinha um sistema em produção usando LLM para classificar tickets de suporte. Funcionava. Um dia parou de funcionar direito — classificações erradas, comportamento inconsistente. O problema: o modelo foi atualizado pelo provedor, e o prompt que funcionava perfeitamente com a versão anterior passou a produzir resultados diferentes. Não havia nenhum teste. Não havia versionamento do prompt. Não havia histórico de quando e como o prompt tinha mudado. Descobri o problema 3 dias depois, por relato de usuário. A correção foi simples — ajustar o prompt. Mas o tempo para diagnóstico foi alto demais. O que mudei: prompts em arquivos .md versionados no Git, testes com fixtures de input/output esperado (igual a unit tests), script que roda todos os testes antes de merge. Implementado em Go. Não é 100% determinístico, mas captura regressões óbvias — e me avisa antes do usuário.
**Imagem 1:** Estrutura de diretórios: prompts/ com arquivos .md e .test.json correspondentes — estilo tree view, fundo escuro
**Imagem 2:** Pipeline de CI/CD com etapa "Prompt Tests" entre build e deploy — destaque na etapa que não existia antes do incidente

---

## por-que-ddd-ainda-vale

**Categoria:** Codigo
**Tema:** Por que ainda uso DDD em 2026 — mesmo quando os outros dizem que é overengineering
**Formato:** porque
**Funil:** topo
**Resumo:** DDD foi declarado "morto" ou "complexo demais" várias vezes. Minha posição: DDD é uma ferramenta de design, não uma arquitetura. O que sempre usei do DDD: Ubiquitous Language (falar a mesma língua que o negócio), Bounded Contexts (separar domínios com fronteiras explícitas), Value Objects (encapsular validações de domínio). O que raramente uso: Event Sourcing completo, CQRS em todo lugar, Aggregates complexos para domínios simples. O erro que vejo: times aplicam DDD completo em CRUDs simples e reclamam da complexidade. A pergunta certa não é "uso DDD ou não?" — é "qual parte do DDD resolve meu problema específico?".
**Imagem 1:** Diagrama de Bounded Contexts de um sistema real: dois ou três contextos separados com suas entidades internas e pontos de integração — cores diferentes por contexto, design limpo
**Imagem 2:** Tabela "Use isso do DDD vs Não precisa disso" — duas colunas com elementos do DDD categorizados por quando valem — checkmarks e X, design minimalista

---

## erro-overengineering-crud

**Categoria:** Codigo
**Tema:** Passei 3 semanas arquitetando um CRUD — e joguei tudo no lixo
**Formato:** erro
**Funil:** topo
**Resumo:** Recebi uma tarefa simples: criar um CRUD de cadastro de fornecedores. Minha resposta: Clean Architecture completo, CQRS com MediatR, Event Sourcing, repositórios genéricos, DTOs mapeados com AutoMapper, validações com FluentValidation. Três semanas depois: tinha uma arquitetura impressionante para gerenciar 50 linhas de dado que nunca mudariam a regra de negócio. O PM pediu uma mudança simples — levou 4 horas porque tinha 12 camadas para mexer. Joguei fora e refiz em 2 dias com Entity Framework direto, sem repositório, sem CQRS. Funciona igual, é mais simples de manter, e não impressiona ninguém — que é o objetivo.
**Imagem 1:** Diagrama satirizando a over-engenharia: CRUD simples no centro cercado por 8 camadas de abstração com setas para todos os lados — visual exagerado de propósito, estilo irônico mas clean
**Imagem 2:** Comparação de complexidade: versão over-engineered (muitos arquivos, muitas pastas) vs versão simples (poucos arquivos, estrutura flat) — file tree dos dois projetos lado a lado

---

## checklist-code-review

**Categoria:** Entregavel
**Tema:** Meu checklist de code review — o que eu olho nos primeiros 2 minutos de qualquer PR
**Formato:** checklist
**Funil:** meio
**Resumo:** Faço code review há 15 anos. Aprendi que os primeiros 2 minutos determinam 80% da qualidade da revisão — ou você foca no que importa ou perde tempo em detalhes cosméticos que o linter deveria pegar. Minha sequência: (1) O que esse PR faz? — se não dá pra responder em 1 frase pela descrição, devolvo antes de ler uma linha, (2) O tamanho está razoável? — PR acima de 400 linhas peço para dividir, (3) Tem teste? — não tem, devolvo, (4) A mudança faz o que a descrição diz? — leio o diff com a tarefa em mente, (5) Tem efeito colateral não óbvio? — lugares onde a mudança pode quebrar algo que não tem teste. Detalhes de estilo: deixo para o linter.
**Imagem 1:** Checklist visual em 5 etapas com ícones: Descrição clara → Tamanho adequado → Testes presentes → Faz o que diz → Efeitos colaterais — design de checklist profissional
**Imagem 2:** Gráfico de pizza ou barras: distribuição de onde o tempo de code review deve ir — lógica de negócio (40%), testes (30%), arquitetura (20%), estilo/formatação (10%) — cores distintas

---

## checklist-api-pre-lancamento

**Categoria:** Entregavel
**Tema:** 8 coisas que verifico antes de subir qualquer API em produção — aprendi na maioria das vezes da forma difícil
**Formato:** checklist
**Funil:** fundo
**Resumo:** Aprendi cada item dessa lista quebrando alguma coisa em produção. Os 8 itens que nunca pulo: (1) Rate limiting configurado — um bot indexou minha API de teste e gerou 50k chamadas em 10 min, (2) Autenticação testada com token expirado — JWT silenciosamente inválido ficou 6 meses em prod, (3) Payload máximo definido — recebi um JSON de 48MB de um cliente "testando", (4) Timeout de dependências externas — uma API terceira travou e segurou threads por 30s, (5) Logs estruturados funcionando — já debuguei produção sem log, é pesadelo, (6) Health check endpoint, (7) Variáveis de ambiente validadas no startup, (8) Documentação mínima de erros.
**Imagem 1:** Checklist visual com 8 itens, cada um com ícone representativo (cadeado, cronômetro, arquivo, etc.) — design profissional de documento técnico, paleta azul/branco
**Imagem 2:** Exemplo de health check endpoint em C# retornando status de dependências — código limpo, ~30 linhas, fundo escuro

---

## erro-jwt-silencioso

**Categoria:** Entregavel
**Tema:** O bug de JWT que ficou 6 meses em produção — e como nunca mais vou deixar isso acontecer
**Formato:** erro
**Funil:** meio
**Resumo:** Implementei autenticação JWT numa API. O bug: a validação do tempo de expiração estava com timezone errado — tokens "expirados" eram aceitos por mais 3 horas que o esperado. Ninguém reportou porque funcionava (usuários ficavam logados por mais tempo, o que eles consideravam "bom"). Descobri ao comparar o comportamento esperado com o real num code review de outro projeto. A causa: `DateTime.UtcNow` vs `DateTime.Now` — uma linha de diferença, consequência silenciosa. Solução implementada: testes de autenticação com tokens expirados como parte do suite de integração. Agora é impossível fazer deploy com essa categoria de bug.
**Imagem 1:** Diagrama de linha do tempo mostrando: token criado → expiração esperada → expiração real (3h depois) — diferença destacada em vermelho, linha horizontal clara
**Imagem 2:** Teste de integração C# que verifica comportamento com token expirado — código limpo com Assert.Returns401, ~15 linhas, fundo escuro

---

## checklist-onboarding-dev

**Categoria:** Entregavel
**Tema:** Meu checklist de onboarding para novos devs — o que mudou depois que parei de improvisar
**Formato:** checklist
**Funil:** topo
**Resumo:** Antes do checklist: cada onboarding era diferente, o dev passava os primeiros dias perdido procurando como configurar o ambiente, e eu perdia tempo respondendo as mesmas perguntas. Criei um documento de onboarding com: (1) Setup do ambiente (passo a passo testado, com print de como deve ficar), (2) Mapa do codebase — o que cada projeto faz e como se conecta, (3) Primeira tarefa definida antes do primeiro dia — sempre uma task pequena de impacto real (não "refatore esses testes"), (4) Buddy designado para primeiras 2 semanas, (5) Check-in na primeira semana: "o que não estava no documento mas você precisou descobrir?". Esse último é o que mantém o documento atualizado.
**Imagem 1:** Documento de onboarding estruturado com seções: Ambiente, Codebase, Primeira Tarefa, Buddy, Check-in — estilo de documento profissional, icons por seção
**Imagem 2:** Timeline da primeira semana do novo dev: Dia 1 (setup) → Dia 2 (mapa do codebase) → Dia 3 (primeira task) → Dia 5 (check-in) — design horizontal, cada dia com cor e atividade principal

---

## sk-versoes-preview-trap

**Categoria:** Codigo
**Tema:** Semantic Kernel tem ótimas ideias e APIs instáveis — aprendi isso da forma difícil
**Formato:** erro
**Funil:** meio
**Resumo:** Comecei a usar Semantic Kernel 1.x com entusiasmo: orquestração de agentes, plugins, memory, planner — tudo parecia resolvido. A IA que usava para me ajudar a codar gerava exemplos que funcionavam. Até que não funcionavam mais. O padrão que identifiquei: a IA treinada nos docs antigos do SK gerava código com interfaces que já tinham sido removidas ou renomeadas entre minor versions. IKernel virou Kernel, ISemanticTextMemory mudou de namespace, o Planner teve três redesigns em 6 meses. Cada update quebrava algo. A lição que aprendi: antes de usar qualquer feature do SK, abro o código-fonte no GitHub e verifico se tem [Experimental] ou [Preview] no atributo. Se tiver, ou espero estabilizar ou implemento manualmente. A IA não faz esse filtro — ela só sabe que o código compilava quando foi treinada.
**Imagem 1:** Screenshot do código-fonte do Semantic Kernel no GitHub mostrando atributos [Experimental] em cima de uma interface — real ou representativo, fundo branco estilo GitHub
**Imagem 2:** Timeline de breaking changes do Semantic Kernel 0.x → 1.0 → 1.x: principais renomeações e remoções de API — linha horizontal com marcos, vermelho nos pontos de quebra

---

## stripe-versoes-api-armadilha

**Categoria:** Codigo
**Tema:** A IA usou a versão errada da API do Stripe — e eu só descobri em produção
**Formato:** erro
**Funil:** fundo
**Resumo:** Estava integrando Stripe para cobranças recorrentes. Pedi ajuda à IA, ela gerou código correto, testei, funcionou em sandbox. Em produção, parte da integração de webhooks não processava eventos direito. O diagnóstico: a IA havia gerado código baseado em uma versão anterior da API do Stripe (que versiona por data: ex. 2023-10-16). Minha conta tinha uma versão diferente configurada no dashboard, e o shape dos eventos era diferente — campos renomeados, estrutura aninhada alterada. O Stripe não errou: ele documentou. Eu não li a documentação de migração entre versões. A IA também não leu — ela não sabe qual versão está na sua conta. Resolução: agora sempre fixo a versão da API explicitamente no código e leio o changelog antes de qualquer integração de pagamento.
**Imagem 1:** Código C# com a versão da API do Stripe fixada explicitamente no cliente (StripeClient + ApiVersion) — antes (sem versão) vs depois (com versão pinada) — diff verde/vermelho
**Imagem 2:** Diagrama mostrando o problema: IA treinada em docs de versão X → gera código → conta com versão Y → webhook event com shape diferente → bug silencioso em produção

---

## vector-db-problema-errado

**Categoria:** Codigo
**Tema:** Testei Chroma, Qdrant e Weaviate por semanas — até entender que o problema não era o banco
**Formato:** erro
**Funil:** meio
**Resumo:** Comecei a usar Qdrant para um projeto com IA. A IA me ajudou a modelar tudo: cadastros de usuário, histórico, preferências — tudo foi parar no Qdrant. As buscas ficaram lentas e inconsistentes. Troquei para Chroma. Mesmo problema. Testei Weaviate. Mesmo problema. Levei semanas até entender: o problema não era o banco vetorial — era eu usando banco vetorial para resolver problema de banco relacional. Para quem não conhece: banco de dados vetorial* não é um banco de dados no sentido tradicional — ele armazena representações matemáticas de texto (embeddings) e serve para uma coisa só: "ache os textos mais parecidos com este". Para filtrar por campo fixo (userId = X, status = ativo), SQL ou MongoDB são 100x mais rápidos e corretos. A arquitetura certa é duas camadas: banco tradicional para dados estruturados + vector DB só para a busca semântica. A IA nunca me avisou sobre isso — ela implementou o que eu pedi, não o que eu precisava. *Vector DB (banco vetorial): armazena embeddings — números que representam o "significado" de um texto. Permite buscar por similaridade: "mostre textos parecidos com este", não "mostre registros onde campo = valor".
**Imagem 1:** Diagrama de arquitetura correta: dados do usuário → PostgreSQL/MongoDB (campos fixos, filtros) + embeddings → Qdrant (busca semântica) — duas camadas separadas com setas mostrando quando usar cada uma
**Imagem 2:** Tabela comparativa: "Use vector DB quando..." vs "Use banco tradicional quando..." — exemplos concretos de queries em cada coluna, design limpo com checkmarks

---

## chatbot-grafo-intencoes

**Categoria:** Codigo
**Tema:** RAG não era suficiente para meu chatbot — construí um grafo de intenções e o comportamento mudou completamente
**Formato:** bastidor
**Funil:** topo
**Resumo:** Estava construindo um chatbot e RAG sozinho não resolvia: o bot dava respostas corretas isoladas mas não mantinha contexto de conversa nem navegava fluxos complexos. A solução que estou testando em POC: um banco de dados de grafo* (Memgraph) modelando intenções como nós e transições como arestas. Quando o usuário digita algo, o fluxo é: (1) identificar intenção via LLM, (2) buscar nó correspondente no grafo, (3) verificar se precisa de mais informação (arestas condicionais), (4) executar ação ou seguir para próximo nó. Se a intenção não está no grafo: verifica se deve retroceder para um ponto anterior da conversa → se não, busca no RAG → último recurso: "não entendi". A diferença em relação a RAG puro: o grafo dá estrutura às conversas, o RAG dá profundidade às respostas. Juntos, o bot sabe onde está na conversa e o que sabe sobre o assunto. *Banco de dados de grafo: armazena apenas relações entre itens, não registros. Ex: [Desconto] -[:REQUER]-> [Nome e CPF]. Não existe tabela — existem nós e conexões. Ideal para modelar fluxos, dependências e caminhos de navegação.
**Imagem 1:** Diagrama do grafo de intenções: nós (intenções como "consultar saldo", "cancelar pedido", "reclamação") conectados por arestas com condições — estilo grafo com nós circulares, setas direcionadas, paleta azul/roxo
**Imagem 2:** Fluxograma de decisão quando usuário digita algo: Identificar intenção → Nó no grafo? → Sim: seguir fluxo / Não: Retroceder? → RAG? → "Não entendi" — boxes com decisões em losango, design clean

---