Codificação agêntica: quando 'build vs buy' muda com vibe code

{ "resumo": "## O problema: excesso de fornecedores e ferramentas internas paralelas\n\nMatt Henderson (Sentry) e Sarah Krasnik Bedell (Railway) partem de uma constatação: o mapa anual de marketing technology segue crescendo exponencialmente em número de fornecedores e, ao mesmo tempo, as equipes estão criando ferramentas internas em paralelo, muitas delas feitas por meio de vibe code. Com a adoção de IA frequentemente puxada de cima para baixo pelo CEO, fundador ou CMO, o risco é acumular dívida técnica, gastar tokens e tempo em ferramentas que só um integrante usa e ainda perder a barra de produtividade.\n\nPara Matt, na Sentry cada pessoa de marketing opera com suas próprias habilidades, ferramentas e projetos hospedados, e várias são duplicadas entre colegas ou cobertas por software já contratado - a empresa está agora convergindo sobre o que deve ser compartilhado e o que permanece nos contratos de SaaS existentes.\n\n## Estrutura para decidir quem constrói\n\nA tese central é que criar um sistema interno para construção aumenta a chance de a ferramenta ser mantida e usada amplamente. Na Railway, existe um MCP interno que funciona como base compartilhada: habilidades, ferramentas e guardrails para que qualquer pessoa crie ferramentas internas com segurança, além de diretrizes de design de marca e especificações de arquitetura. Sarah destaca que isso é viável por três condições: time altamente técnico, esforço dedicado a aperfeiçoar as ferramentas e menos de 50 funcionários.\n\nO par também ressalva que uma ferramenta voltada ao cliente, feita por vibe code, pode ser aceitável - como uma pesquisa ou criador de templates no site - mas sempre exige mais escrutínio.\n\n## Build vs. buy, categoria por categoria\n\nOs dois autores avaliaram 8 categorias separadamente e discordaram de muito pouco:\n\n- CRM: ambos dizem comprar. Sarah sugere um CRM voltado a automação, como Attio, usado como datastore, e admite que Salesforce pode ser um mal necessário em escala. Matt cita Salesforce e HubSpot pelo conjunto de integrações (Gong, Google Ads, relatórios prontos).\n- CMS: ambos dizem construir. Matt aposta que essa categoria vai morrer nos próximos dois anos, já que LLMs como Claude facilitam editar páginas e usar skills como templates - um bom engenheiro criando guardrails permitiria o time avançar. Sarah condiciona a três requisitos: guardrails de design com IA, disposição para vibe code no site e time de GTM voltado a engenharia; sem isso, o site pode virar AI slop.\n- Plataforma de dados de audiência: Sarah diz construir sem exceção, porque o ICP é o diferencial competitivo e as ferramentas de mercado batem num muro após certa customização. Matt diz que depende: construiu em uma tarde uma ferramenta que gera milhares de URLs de vídeos do YouTube para segmentação em anúncios, mas reconhece que ferramentas como Clay existem para criar e enriquecer contas de ICP - o caminho é construir o que der e usar ferramentas baratas e comprovadas no resto.\n- BI: ambos dizem comprar. Sarah argumenta que é muito trabalhoso construir e não há vantagem competitiva, citando o esforço das equipes do Omni e do Hex. Matt acrescenta que precisa de time de engenharia de dados, mas recomenda construir dashboards próprios para pontos cegos, como social listening e visibilidade em IA.\n- Sistema de e-mail: discordam. Sarah diz comprar - Customer.io para empresas antes da série C, porque domínio, envios em lote e políticas DMARC são trabalhosos. Matt diz construir, com base no Resend e em pedidos a agentes de código como criar uma sequência de retenção; mas nota que a Sentry já tem um sistema integrado pela Inflection e não o desfaria só para vibe code.\n- Rastreamento de AEO/SEO: ambos dizem comprar, citando Ahrefs, Gauge e Profound, e construir por cima dashboards, skills e contexto para agentes.\n- Plataforma de testes A/B: Sarah diz não fazer, exceto em escala grande, preferindo testes isolados em plataformas como Google Ads. Matt sugere construir uma ferramenta direcional simples se o site estiver em código, e só comprar quando a escala justificar, usando calculadoras de significância estatística.\n- Sistema de atribuição: ambos dizem construir. Sarah defende um algoritmo de waterfall attribution, já que MMM só vale em escala enorme. Matt escreveu a lógica SQL com o time de BI e menciona que 70% do orçamento vai para esforços de awareness.\n\n## O padrão e as perguntas práticas\n\nA conclusão dos dois: em todas as categorias com "construir", o fornecedor vende um esquema, uma interface e integrações sobre dados que a empresa já possui - hoje é possível montar esse sistema sozinho. Nas categorias com "comprar", o fornecedor assume algo difícil e entediante: entregabilidade, conformidade, uptime, frota de crawlers, integrações que quebram.\n\nPara avaliações e renovações, eles sugerem três perguntas: se você cancelasse amanhã, o que quebraria, quem notaria e quanto tempo levaria para substituir internamente; se o que você gosta no produto é o produto ou os dados que você colocou nele; e se há versão via API/MCP que permita fluxos de LLM em vez de uma interface fechada.\n\nO fechamento é uma tese: você não ganha ou perde pelas ferramentas escolhidas, mas pela velocidade de implementar as estratégias que anota - ferramentas ajudam a decidir, e as ferramentas internas ajudam a executar.", "hook": "Dois profissionais de marketing - um da Sentry, outra da Railway - passaram por oito categorias de ferramentas e decidiram, uma a uma, o que vale construir com vibe code e o que continuar comprando. Eles discordaram de muito pouco, e o padrão que encontrou distingue onde o fornecedor vende apenas uma opinião sobre seus dados de onde ele assume trabalho difícil.", "entities": ["Sentry", "Railway", "Salesforce", "HubSpot", "Ahrefs", "Customer.io", "Clay", "Attio"], "themes": ["engenharia-com-ia", "marketing-e-growth"], "story_key": "build-vs-buy-vibe-code", "reasoning": { "story_key": "A tese canônica é que o build vs. buy de ferramentas de marketing muda na era do vibe code, com framework de decisão por categoria.", "themes": { "engenharia-com-ia": "O assunto central é o fluxo agêntico/vibe code de construir ferramentas internas: MCP da Railway, skills, guardrails e agentes de código.", "marketing-e-growth": "Todas as decisões versam sobre stack de marketing: CRM, CMS, BI, e-mail, AEO/SEO, testes A/B, atribuição e avaliação de fornecedores." }, "entities": { "Sentry": "Empresa de Matt, com contexto sobre ferramentas internas de marketing e sistema via Inflection.", "Railway": "Empresa de Sarah, origem do MCP interno que estrutura o framework.", "Salesforce": "Citação direta como escolha de compra em CRM.", "HubSpot": "Citação direta como escolha de compra em CRM.", "Ahrefs": "Ferramenta citada nas duas respostas de AEO/SEO.", "Customer.io": "Recomendação específica de Sarah para e-mail.", "Clay": "Ferramenta citada por Matt para enriquecimento de contas de ICP.", "Attio": "Recomendação específica de Sarah para CRM de automação." }, "excluded": { "Resend": "Menção secundária no caso de e-mail de Matt.", "Omni/Hex/Profound/Gauge": "Exemplos e menções secundárias, não sujeitos do fato.", "Inflection": "Menção secundária sobre o sistema de e-mail da Sentry.", "Matt Henderson e Sarah Krasnik Bedell": "Autoras, excluídas por regra." } } }